Transcript ATOCA Design Team Results

ATOCA Design Team
Initial Thoughts
ATOCA Interim
13 Sept 2011
How Alerts Work Today
Authorities
Networks
Recipients
How Alerts Work Today
Authorities
Networks
Step 1: Distribution
Recipients
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
How Alerts Work Today
Step 2: Broadcast
Authorities
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
Networks
Recipients
How Alerts Work Tomorrow?
Authorities
Networks
Recipients
Standards Requirements
Authorities
Networks
Recipients
IP-based
Distro(?)
Common
Format
Broadcast
tor IP
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 layer2 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
Proposed milestones:
1. Architecture
2. Secure Alert Format
3. Distribution Protocol (?)
4. Broadcast Protocol
• Is this generally the right direction?
• Do we need to work on a distribution protocol?