ATOCA Design Team Initial Thoughts

1. ATOCA Design Team Initial Thoughts ATOCA Interim 13 Sept 2011

2. How Alerts Work Today Authorities Networks Recipients

3. How Alerts Work Today • Step 1: Distribution • From alert originator to broadcast points at network operators • Properties: • Small number of participants • O(10^4) • Subscriptions relatively static • Often by law/regulation • Robust connectivity between authorities and networks • Not specific to type of broadcast network • Existing systems • US: EAS+, iPAWS • CA: NAAD • JP: ETWS Authorities Networks Recipients

4. How Alerts Work Today • Step 2: Broadcast • From broadcast points to end recipients • Properties: • Large number of participants • O(10^7) • Subscriptions highly dynamic • Connctivity / geolocation • Prior systems have been specific to network types • Prior art: • US: EAS, CMAS • JP: ETWS Authorities Networks Recipients

5. How Alerts Work Tomorrow? Authorities Networks Recipients

6. Standards Requirements Authorities Networks Recipients IP-based Distro(?) Common Format Broadcast tor IP

7. Proposed ATOCA Milestones • Architecture (see previous slides) • Secure Alert Format • IP-based Distribution Protocol (?) • IP-based Broadcast Protocol

8. Secure Alert Format • Primary security risk is introduction of alerts by unauthorized parties • In current systems, security is based on: • Security of distribution channel • Security of layer 2 used for broadcast • In our IP-based system • Can’t rely on layer 2 security • Prefer not to rely on the distribution channel security

9. Secure Alert Format • CAP as base alert format (actual alert info) • Include signatures over CAP by relevant parties: • Authority that originated the alert – replaces distribution channel security • Broadcast point that retransmits alert – replaces layer-2 security • To be worked out: • Authority certificate discovery • Optimization using hash pre-images

10. IP-based Distribution Protocol (?) • On the one hand, it’s unclear whether there’s a need for an IETF standard here • Lots of national standards already exist, especially for regulated use cases • Some of these are already IP/CAP-based (iPAWS) • On the other hand, this is the natural protocol for the “school closing” case • Could just put Secure Alert Format in SIP, XMPP, Atom, etc. • May be useful to extend have discovery (e.g., LoST)

11. IP-based Broadcast Requirements • Deliver messages in common format across media • Leverage lower-layer multi/broadcast • Implies non-TCP transport • Possibly implies need to work without configuration • Allow control of transport layer characteristics, especially ACKs • Work in realistic networks (firewalls and NATs) • Enable fine-grained geographical targeting of alerts • Enable endpoints to apply security checks on alerts • Secure alert format, plus advance notice of alert sources

12. IP-based Broadcast Design Principles • Discovery: Use local discovery techniques to find local alerting context • Context: Alert server address, multicast groups, authority keys, … • Registration/State: Endpoint registers contacts and location with server • Not subject to hard transport requirements • Alert transmission: Need a UDP-based protocol to be able to meet transport requirements

13. IP-based Broadcast Protocol • Discovery: Re-use techniques from ECRIT/GEOPRIV/ATOCA [RFC5985,RFC5223] • DHCP + NAPTR + HTTP[S] • Define context document format • Registration/State: Define simple protocol for registering contacts and updating location • Based on TCP, maybe WebSockets? • Alert transmission • Re-use existing protocols (SIP, SMTP) according to alert server policy • Define a simple UDP-based protocol to meet transport requirements

14. Questions to the WG • Is this generally the right direction? • Do we need to work on a distribution protocol? Proposed milestones: • Architecture • Secure Alert Format • Distribution Protocol (?) • Broadcast Protocol