atoca design team initial thoughts
DESCRIPTION
ATOCA Design Team Initial Thoughts. ATOCA Interim 13 Sept 2011. How Alerts Work Today. Authorities. Networks. Recipients. How Alerts Work Today. Step 1: Distribution From alert originator to broadcast points at network operators Properties: Small number of participants O(10^4) - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/1.jpg)
ATOCA Design Team Initial Thoughts
ATOCA Interim13 Sept 2011
![Page 2: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/2.jpg)
How Alerts Work Today
Authorities Networks Recipients
![Page 3: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/3.jpg)
How Alerts Work Today
Authorities Networks RecipientsStep 1: DistributionFrom 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
![Page 4: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/4.jpg)
How Alerts Work Today
Authorities Networks RecipientsStep 2: BroadcastFrom 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
![Page 5: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/5.jpg)
How Alerts Work Tomorrow?
Authorities Networks Recipients
![Page 6: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/6.jpg)
Standards Requirements
Authorities Networks Recipients
IP-based Distro(?)
Broadcasttor IP
Common Format
![Page 7: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/7.jpg)
Proposed ATOCA Milestones
• Architecture (see previous slides)• Secure Alert Format• IP-based Distribution Protocol (?)• IP-based Broadcast Protocol
![Page 8: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/8.jpg)
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
![Page 9: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/9.jpg)
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
![Page 10: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/10.jpg)
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)
![Page 11: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/11.jpg)
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
![Page 12: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/12.jpg)
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
![Page 13: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/13.jpg)
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
![Page 14: ATOCA Design Team Initial Thoughts](https://reader035.vdocument.in/reader035/viewer/2022062518/56814943550346895db68c6d/html5/thumbnails/14.jpg)
Questions to the WG
• Is this generally the right direction?• Do we need to work on a distribution protocol?
Proposed milestones:1.Architecture 2.Secure Alert Format3.Distribution Protocol (?)4.Broadcast Protocol