atoca design team initial thoughts
Post on 15-Jan-2016
15 Views
Preview:
DESCRIPTION
TRANSCRIPT
ATOCA Design Team Initial Thoughts
ATOCA Interim13 Sept 2011
How Alerts Work Today
Authorities Networks Recipients
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
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
How Alerts Work Tomorrow?
Authorities Networks Recipients
Standards Requirements
Authorities Networks Recipients
IP-based Distro(?)
Broadcasttor IP
Common Format
Proposed ATOCA Milestones
• Architecture (see previous slides)• Secure Alert Format• IP-based Distribution Protocol (?)• IP-based Broadcast Protocol
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
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
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)
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
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
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
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
top related