Priority for emergency communications

1. Priority for emergency communications Henning Schulzrinne Dept. of Computer Science, Columbia University ComCARE Priority Data Summit September 15 & 16, 2004

2. Overview • Stepping back: Why priority? • Requirements and pit falls • Components of a data priority system • data plane • authentication & authorization • Current IETF efforts • DiffServ & IntServ • IEPREP • NSIS • Universal access to communication resources

3. Stepping back: why priority? • Large-scale emergencies • Cases: • dramatically increased demand • “are you ok?” calls, news access • dramatically decreased local or regional capacity due to large-scale capacity loss (fiber cuts) • access link capacity • primarily wireless • Unlikely due to emergency coordination traffic • small number of responders • Internet backbone traffic estimate: 80,000-140,000 TB/year  800,000 simultaneous 64 kb/s phone calls

4. Two view of priority • Civilian vs. emergency coordination • assume that there is enough capacity for emergency coordination • same entity may be both (e.g., school) • Multiple levels of priority • only needed if capacity insufficient for emergency communications • likelihood of occurrence? • MLPP in the military context • very hard to predict performance for different levels

5. A different view of priority • The scarcest communication resource is human • Thus, longer term need to prioritize messages at the application layer • Important, but not subject of discussion

6. Data traffic • Data traffic for coordination and messaging minuscule • email and IM probably < 5% of traffic today (with spam and pictures…) • 1 second of voice = at least 10 messages • or: • 10 minutes of spoken text = 1000 words • = 4,800 KB (at 8 KB/second) • = a very high resolution digital image •  a picture is worth a thousand words (but probably only about a hundred for web image…)

7. Internet architecture issues • Single managed IP network vs. Internet • End-to-end multiple, competing providers • Cannot predict with certainty what providers will be transited

8. The dangers of priority • Data priority does not come for free • Increases system complexity • complex systems are less reliable • human complexity: manage keys, access rights, lost passwords, … • Increases system cost • key and authorization management • traffic management infrastructure • accounting and intrusion detection • same money can be spent on increasing capacity  • Requirement: needs to quickly fall back to normal priority operation if authentication fails

9. Warning of history • Quality of service has been investigated in the Internet since 1992 (at least) • No large-scale deployments • authentication • business model (on average, performance not [much] better) • But small-scale deployment • low-speed access routers (T1, DSL)

10. Where to apply priority • In increasing complexity • Access link • outbound only • in- and outbound by traffic type or destination • outbound plus response traffic • Single administrative domain • with limited user population • all possible emergency responders • Across multiple domains • never been solved for non-emergency traffic

11. Overall architecture filter management IntServ • AQM – active queue management • packets can be assigned to treatment by • short label carried in packet  DiffServ • property (source/destination address)  IntServ DiffServ traffic shaping, handling & measurement traffic filtering

12. Differentiated Services (DiffServ) • DiffServ data packet marking • per-hop behavior (PHB), with values from 0 to 63 • AQM (active queue management) • prioritization and rate limiting • no authentication at packet level • Need to prevent unauthorized users from marking traffic as higher priority

13. Integrated Services (IntServ) • Signals data flows end-to-end or in subset of nodes • “Dear router, please give treatment 42 to IP packets with port 5000, from IP address 128.59.16.1 to 172.18.19.20” • RSVP = standard protocol for session setup and teardown • Widely available in routers, but rarely used

14. Challenges for data priority • Agree on common ways of identifying such traffic • easy part • Restrict access to high priorities • if not, provides denial of service opportunities • instead of competing equally for bandwidth, DOS traffic can push aside legitimate traffic • note that end systems can be compromised • worms • stolen systems • single end system can do lots of damage • unlike stolen cell phone or GETS card • can send multiple hundred Mb/s

15. Authorization • Unless the authorization and authentication problem is solved, it is pointless to talk about priority levels for data • Technically and organizationally hard problem • no existing examples of large-scale use across domains • Three approaches: • By device – works only with fixed IP addresses  not viable • By user: remote authentication (RADIUS, DIAMETER) • known as AAA: authentication, authorization, accounting • typically, with passwords • can be federated (e.g., alice@fema.gov, bob@fire.nyc.gov) • By user: purely based on crypto certificates • authenticate person (“signed by Joe”) or role-based (“signer has level 7 access rights”) • still need to check for certificate revocation list (CRL) • hardware crypto tokens (built-in or external)

16. Federated Authorization • Instead of a single database of all authorized users  federated set of servers, maintained by different agencies • Steps for DiffServ: • user authenticates with local RADIUS server • RADIUS server asks home server • needs to have a list of authorized agencies, but not users • tells router that packets from user’s IP address are permissible for DiffServ marking • transitive trust across packet forwarding domains • next network has to trust previous network to do its authentication job • access router ignores and resets DiffServ marking for non-authorized users

17. IETF (Internet Engineering Task Force) • Cognizant working groups • IEPREP • emergency preparedness • GEOPRIV • geospatial information • SIP, SIMPLE • call signaling, resource priority • NSIS • data plane signaling, e.g., resource control • DIAMETER, RADIUS-EXT • authentication, authorization, accounting

18. IETF: IEPREP (Internet Emergency Preparedness) Charter • “1. Conveying information about the priority of specific phone callsthat originate in a VoIP environment through gateways to the PSTN. • 2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health. • 3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging. • The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols.”

19. IEPREP Documents - finished • RFC 3487: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) • RFC 3523: Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology • RFC 3690: IP Telephony Requirements for Emergency Telecommunication Service (ETS) • RFC 3689: General Requirements for Emergency Telecommunication Service (ETS)

20. IEPREP documents – in progress • A Framework for Supporting ETS Within a Single Administrative Domain <draft-ietf-ieprep-domain-frame-01.txt> • summarizes existing techniques, such as • 802.1d (802.1p) • MPLS • RSVP • DiffServ

21. DiffServ operation • draft-baker-diffserv-basic-classes

22. IETF NSIS effort • Generic data-plane signaling protocol • not end-to-end application (SIP, etc.) • Including quality of service • Simpler than RSVP • Currently, in later stages of standardization

23. QoS-NSLP node architecture QoS-NSLP resource management policy control API GIMPS forwarding table manipulation select GIMPS packets traffic control outgoing interface selection (forwarding) packet scheduler input packet processing packet classifier

24. SIP Resource Priority • Labels VoIP calls for priority treatment at proxies, gateways, end systems • Simple header with extensible namespaces • Resource-Priority: dsn.flash • Discovery mechanism for available levels • Authentication within domain by standard SIP-level authentication (Digest authentication)

25. Emergency access to network communication • Emergency workers should be able to access local commercial 802.11 (WiFi) networks, DSL, WiMax, etc. • Can’t have individual accounts on all systems • Thus, need national “fireman’s key” for these systems • probably best done by roaming agreement with national center • may in turn consult individual agencies

26. Conclusion • Limit problem scope – precision needed • private networks vs. access vs. inter-provider • Defining priority labels is only a small (and easy) part of problem • easy to get hung up on number of priorities and other secondary issues • Consider complexity-gain trade-off • e.g., restrict to access links or intra-domain • Who should have access? • Who is going to run the AAA servers or CAs? • At least as helpful: ready emergency access to commercial local networks