Subject: [atoca] How I think ATOCA works

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Jul 2011 11:08:53 -0400

How I think ATOCA works

There is a nominal tree of distributors.  It isn't really necessary for it to be a tree, but that will be a common organization.  The bottom ("root") end of the tree corresponds roughly to the lower A levels of a PIDF (nation, state/province, county).  There is a forest guide between nations.   The top of the tree is nominally ISPs of various forms including enterprises, but don't have to be.  It is acceptable for some short circuiting of the tree.  For example, a national ISP can connect to the national distributor and not have to get national alerts from the state/province distributor.  Distributors can get alerts from any notifiers they know they need to.

There is a discovery mechanism for clients to find its local distributor.  In addition to the ISPs, Subscription services are connected to the bottom of the tree.  These services are listed in the LoST server: you can query LoST with a location, and obtain a list of the subscription servers that serve that location.

A Notifier is authorized by one of the bottom level distributors.  An alert is sent to a distributor via a CAP message, probably with SIP Sub/Not.  It is propagated up (not down) through the tree, with filtering for location at every step.  Aggregation of alerts may happen in other ways (because the organization of distributors doesn't have to be a tree).

The top level (ISP) distributors may use any available L2 broadcast mechanism for alerts that are location limited.  Filtering is considered imperfect, biased towards inclusion.  This means any level may get alerts that may not apply to them, and will have to filter.  This includes the endpoints.

Clients receive alerts from the top level distributors and subscription services.  They are CAP messages probably just sent in UDP packets (fragmentation has to work) on a dedicated port;  Alerts with high importance are replicated - the more importance, the more replication. There is no acknowledgement.   Subscriptions are accomplished with a web service subscribe transaction.  It has a expiration time.  There are no keep alives.  Notifications are indistinguishable from the broadcast mechanism (no acknowledgement).

The LoST query also returns public keys of the A2 distributor.  As alerts are propagated up, they are signed.  This means the recipient has the key of the entity that signed it.  This is the ultimate security mechanism.  There is a discovery mechanism for the broadcast distributor IP address which is secure.  There is also a hash mechanism that is based on information retrieved from the LoST server.

Security is multifaceted.  The client only accepts alerts on the port.  It only accepts alerts from the IP addresses it learns are used by the distributors.  It checks the hash.  It then checks the signature.   We'll have to secure the LoST data better, but we can spend some more cycles doing that, because it's before the alert.