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