From CAP Cookbook

[An essay by Jay Ashworth]

That's been the standard of the Internet since the beginning, and in light of the almost complete lack of discernable motion in the ocean of practical implementation of CAP/WARN/iPAWS over the last 2 (3, 6) years, I'm going to slap some spaghetti up against the wall here, and see if it sticks.

My experience of the Internet since 1983 is "if you build it, they will come".

Getting things perfect is, as is so often the case, probably impossible, since it will require buy-in from so many disparate bureaucracies that it will never happen by mandate.

Happily, it does not appear that this sort of buy in is actually necessary in order to grow a usable system organically. So... what is necessary? Let us ponder...

Contents 1 What do we need? 1.1 Alert Data 1.2 Standard Wrapper Format 1.3 Standard Signature Format 1.4 Routers, Clients, and Transport 2 How Does It Work? 2.1 Scenario 1 - Medium Business 2.2 Scenario 2 - Weather Alerts 2.3 Scenario 3 - External Partner 2.4 Scenario 4 - External Supplier (Translated) 2.5 Scenario 4a - External Provider (Native) 2.6 Scenario 5 - Cell Broadcast 2.7 Scenario 6 - FEDWARN 3 So that's how it could work

[edit] What do we need?

In order to grow iPAWS/WARN out of thin air, we need 7 things:

• Sources of alert data
• Routers to aggregate and transport that data
• A standardized format to wrap it in
• One or more standardized transport protocols to move it
• A standard for signing it to make it verifiable
• A client for people to make use of it
• And a fanatical devotion to the Pope.

[edit] Alert Data

There are lots of sources of alert data of the type that CAP/WARN/iPAWS was meant to move around. NOAA/NWS and USGS are probably the two most prominent, but the linked page is intended to be the semi-canonical list; if you find one, please put it there in the template format. Note that alert data does not have to, for our purposes, originate in CAP format; as long as we correctly provenance the data we pass along, we can translate it into CAP format initially, until a data provider sees enough demand to originate in that format.

A non-obvious source -- but the one that dragged me into this in the first place -- is corporate desktop alerting. "Lockdown: Man out in the parking lot with a gun" is a perfectly valid alert message, with a very small audience: everyone in that building. Desktop alerting software presently available in the market is either

• Expensive
• Branded and non-extensible, or
• Free and crappy

So if you're going to design and build alerting software, why not get wider usability out of the design?

[edit] Standard Wrapper Format

This is CAP, the Common Alerting Protocol, currently in v1.1. There's lots on this everywhere on this site. I personally think that an RFC-2822 alike format would have been better than XML -- XML parser libraries are generally humongous -- but we have what we have, and trying to fix it would break digital signature.

Since broadcast clients on a LAN (for example) will not see the individual feeds as individual feeds, there needs to be some way to wrap and tag these, and a way for clients to opt into a newly seen feed (which may be forced automatic in a business environment, but should be newly-seen opt-in in a general environment).

[edit] Standard Signature Format

I gather there's a standard that's already been promulgated for applying digital signatures to CAP packets. I'll be looking at its details shortly, but I hope they were smart enough to put the signing hash type into the data, so you can change which ones can be used.

How to use it is much easier: each data originator puts its signature and its fingerprint on a publically accessible webpage, and publishes the finger print periodically in actual ink somewhere that's easily accessible to the public: the various agencies of the federal government could supply their keys all to DHS, DISA, or someone similar, who could take out a full-page in USA Today with the print versions of all the relevant signature fingerprints as well as a link to generic client software for Windows, Linux, and the Mac, and a web page explaining the system and containing links to router software; the hashes of which could also be printed in the ad.

Ink on paper is an amazingly useful, and insufficiently used, adjunct to PKI systems.

More on signatures below.

[edit] Routers, Clients, and Transport

One of the rocks on which C/W/I has foundered, in my perception, is that the actual mechanics don't seem to exist: there's no reference implementation of publically accessible code to generate, route, sign, and receive the alert messages.

Good cases can be made for providing separate software for the routing and client functions, and for using the same program to do both.

The client software is, at the very least, a special case of the router software, with a delivery option of "Local UI".

Router software, in my view, requires two things that user software does not: auditing of configuration changes (necessary to make it reasonably deployable in more formal environments), and the ability to sign new streams of not already authenticated alert data which it introduces to the network.

My view of authentication, as noted above, is that it needs to be done end to end -- there are just too many points to secure otherwise. Messages need to be PKI signed with a securely protected key at their point of origin, and passed unmolested from the inputs of routers to their outputs. Routers may add a signature of their own, if the signature protocol and wrapper permit (and I dearly hope that they do), so that end consumer software can make, or permit its user to make, more educated decisions about their confidence factor in the alert, but should otherwise log it, and pass it on.

If the protocol permits, adding provenance information as messages are propagated will be a Good Thing as well -- similar to the "Received:" stanza of an RFC 2822 email message.

Clients will usually be able only to receive; it's reasonable to put both receiver and sender in the same package, but the ratio of senders to receivers will usually be 1:100,000 or lower, so it may not be worthwhile -- except that small organizations like towns, cities, and businesses may wish to originate their own alerts for combined consumption by their constituencies. Having the composing and sending facilities integrated in the workstation client may be worthwhile to do on a general basis for this reason.

Additionally, users who run a client program way wish to have it forward human-readable versions of alerts to a mobile device via SMS or email, in the absence of larger-scale services to provide this function; this also augurs for combining the functions in one program.

Router/Aggregators will be application layer gateways at layer 4, somewhat like SOCKS proxies, but with some aspects of the traditional layer 2 IP router. They should be able to be configured to receive feeds from any number of potential sources, in one of five modes:

• TCP acknowledged with link auth
  • This can be CAP/HTTP/TCP, RSS/HTTP/TCP, CAP/MIME/RFC2822, etc...
• UDP broadcast with FEC
• UDP multicast with FEC
• Serial
• Direct Physical (contact closure)

Link authentication protocols will differ based on scaling issues, but may be PKI or TLS based; clearly, if you are a cablemodem IAP needing to hook 3 machines inside your network to each of 3 machines in FEDWARN (a name I just this moment coined for a network of CAP routers operated by the Federal Government on behalf of its member agencies, but please feel free to steal it), then you have a much different situation on that link than you do on the UDP multicast links you use to feed your customers. The latter must be done by signature -- in addition to captive packet routing (use a server address in a private network space that your core will not let out to the Internet at large) -- instead of by password type interchanges.

On the other hand, if you run a small business with 3 sites, then username/password / PKI / TLS is perfectly serviceable.

Routers, and end nodes which send, additionally need to be able to source each of those transport methods, in addition to sinking them; routers have the additional need to cache messages locally, for (eg) the purpose of resending them for FEC.

The more I examine the problem, the clearer it becomes that every node should be a router even if not all nodes route from or to anywhere except a local UI.

So: a router application which runs as a system service on the relevant operating system, and a UI program which can perform the following services:

• Display a received alert, authenticating as possible
• Capture data for an alert to send, authenticating as possible
• Store received alerts for FEC retransmission over whichever channels require it
• (Optionally) Configure the router as to which channels it uses to receive which sources using which protocols -- the protocols to be implemented as plugins so that the program is easily extensible.
• Log all activities, including startup configuration, using the provided facilities (including Unix syslog, possibly to another machine).

The more I think on this, the more that I think that using NNTP and its flooding transport algorithm may be the best native transport method; it provides channel separation (newsgroups), and node-subscription control automatically, and attaching XML inside RFC 1036 news messages should be trivial, in our controlled environment, not even requiring MIME/BASE64 encoding, since we will not interoperate (by design) with "real" NNTP networks.

I'll be dabbling (even more inchoately than here) on the design of a potential servent program called Alerting And Readiness Framework. Yes, AARF. Yes, it's going to bark when it gets a new alert message. Sue me. I think this sort of stuff is funny.

[edit] How Does It Work?

Let's visualise how iPAWS/WARN could work in several increasingly complex scenarios involving increasing amounts of nationwide uptake:

[edit] Scenario 1 - Medium Business

A medium sized company, with 600 employees and 50 managers across 4 buildings on 2 sites (mine, as it happens :-) deploys an iPAWS client program to each of its manager PCs and configures it to receive broadcast UDP from the local LAN.

They put one router on each of the 2 sites, and tie them together over TCP links over a VPN.

They configure the client programs of the IT manager, and 3 of the operations management staff to be able to generate alerts, generating a signing private key with passphrase for each, and deploy the associated public keys to the workstations.

Each manager can then generate appropriately coded announcement messages to all the desktop workstations, which will be received substantially immediately.

[edit] Scenario 2 - Weather Alerts

Our medium-sized company, Medi-Corp, decides that it now wants to pick up weather alerts from NWS for local hurricane and tornado activity, and route these automatically to their users.

They locate an appropriate feed (from the alert data sources page, perhaps), and set up an inbound channel on one or both of their routers for it. They configure the source (URL), the transport (TCP/HTTP), the parser (CAP 1.x pass-through), and define it as source-only.

They can then configure which destinations receive the data from this source (a checklist being presented of all the channels which are configured as destination or bi-directional), and configure the received packets to be pushed via UDP Broadcast to the local LAN, and sent via TCP to the other router, which will similarly be configured to send them to its LAN clients, but not back to the source from which it received them, nor out to any external connections (since the default for a newly added inbound channel is to log and broadcast to LAN, and not to send to any other channels).

[edit] Scenario 3 - External Partner

Let us now expand our scenario: we will theorize external partner companies who transfer calls to our company. If we provision the appropriate people at these partners with client software, set up in TCP Auth mode to connect to us over the Internet, we can then make sure that they receive notices about situations (either scheduled, like "lunch in 10 minutes", sent by a Timed Reminder channel, or unscheduled, like "fire alarm evac") which will make us unable to receive their calls, so they should stop placing them to us.

[edit] Scenario 4 - External Supplier (Translated)

Let us assume that Pinellas County Fire Rescue decides to make a feed available of incidents they're responding to which may be pertinent to people in their geographic area, but they have not yet drunk the CAP Kool-Aid™. (More to the point, they already have a dispatching system, and its supplier has not created an export module which translates to well-formed CAP...)

So they provide the information as an RSS feed in their own format, or worse, as a scrapable HTML page.

We can write a channel parser which will use the transport protocol (TCP/HTTP/HTML or TCP/HTTP/RSS), and hand what it retrieves to a parser module which can break the information down into something close to CAP and then generate our own CAP packets from that. Since we generated them, they're signed by us, and marked as coming from us (hopefully the CAP protocol also differentiates Sender from From, as RFC 2822 does -- those who paid no attention in Protocol History class are condemned to repeat a grade :-). We can then, by request, distribute those to any one else who wants them until

[edit] Scenario 4a - External Provider (Native)

enough people are getting them that PCFR notices, and asks for our help running their own router, at which point the packets will come from, and be signed by, them.

If Pinellas County itself sets up a federated network (run by SPC, perhaps, on fiber between its campuses and to the local providers, Bright House, Knology, and Verizon DSL/FiOS), then those providers can accept traffic from PC-NET, vetted by its administrators, and forward it to their customers, who can run the client program on their home PCs. And all the local incident response people (hazmat, police, etc) can send pertinent incidents to that geographically local network. (I am really big on geographic locality of reference, and think not nearly enough use is made of it on non-mobile parts of the Internet.)

[edit] Scenario 5 - Cell Broadcast

At this point, enough local agencies are sending to and from PC-NET that it's reasonable for the local chief engineers of the 6 major cell phone companies to investigate setting up feeds which can be sent to their subscribers over GSM Cell Broadcast... and the rest is history.

[edit] Scenario 6 - FEDWARN

At this further point, sufficient headway has probably been made from all fronts that people wanting weather alerts can get them from NOAA via FEDWARN (which is to say that the feds would finally have seen fit to deploy FEDWARN :-) and PC-NET, instead of having to pick them up themselves; it is in the best interest of all agencies at all levels to set up such federated push networks to edge providers as early as possible for load reasons...

[edit] So that's how it could work

But we need to get the router/client code written and running first, and I'm not a programmer. Techniques for writing relatively portable system service software which accepts plugins are not all that difficult to find, I don't think.

Anyone a good, bored, C coder with some experience in all three platforms? Native code which doesn't require ridiculous amounts of libraries, and will compile down to a small tight binary without requiring a complex toolchain would be best: C#, Java and .NET need not apply at all.

(Note that this is not a full functional spec; I don't want to write one until I get some additional confirmation on finer points of the architecture.)