Priority for emergency communications Henning Schulzrinne Dept of

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

Overview n n n Stepping back: Why priority? Requirements and pit falls Components of a data priority system q q n Current IETF efforts q q q n data plane authentication & authorization Diff. Serv & Int. Serv IEPREP NSIS Universal access to communication resources

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

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

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

Data traffic n Data traffic for coordination and messaging minuscule q q q email and IM probably < 5% of traffic today (with spam and pictures…) 1 second of voice = at least 10 messages or: n n 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…)

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

The dangers of priority n n Data priority does not come for free Increases system complexity q q n Increases system cost q q n complex systems are less reliable human complexity: manage keys, access rights, lost passwords, … 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

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

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

Overall architecture filter management Int. Serv Diff. Serv traffic filtering n n traffic shaping, handling & measurement AQM – active queue management packets can be assigned to treatment by q q short label carried in packet Diff. Serv property (source/destination address) Int. Serv

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

Integrated Services (Int. Serv) n n 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

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

Authorization n Unless the authorization and authentication problem is solved, it is pointless to talk about priority levels for data Technically and organizationally hard problem q no existing examples of large-scale use across domains Three approaches: q By device – works only with fixed IP addresses not viable q By user: remote authentication (RADIUS, DIAMETER) n n n q 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 n n n 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)

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

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

IETF: IEPREP (Internet Emergency Preparedness) Charter n n “ 1. Conveying information about the priority of specific phone calls that originate in a Vo. IP 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. ”

IEPREP Documents - finished n n 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)

IEPREP documents – in progress n A Framework for Supporting ETS Within a Single Administrative Domain <draft-ietfieprep-domain-frame-01. txt> q summarizes existing techniques, such as n n 802. 1 d (802. 1 p) MPLS RSVP Diff. Serv

Diff. Serv operation n draft-baker-diffserv-basic-classes Service class traffic characteristics loss delay jitter administrative small packet size, one packet at a time very low yes network control inelastic short messages, can burst (BGP) low yes telephony fixed-size packets, inelastic very low signaling variable-sized packets, short-lived flows low yes multimedia conferencing reacts to loss low - medium very low real-time interactive RTP/UDP, inelastic low very low multimedia streaming elastic with variable rates low-medium yes broadcast video inelastic very low medium low-latency data telnet, ssh low-medium yes OAM short-lived flows low medium yes high-throughput data bursty, long-lived flows low medium-high yes standard (“best effort”) a bit of everything low-priority data non-real time and elastic not specified high yes

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

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

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

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

Conclusion n Limit problem scope – precision needed q n Defining priority labels is only a small (and easy) part of problem q n n n easy to get hung up on number of priorities and other secondary issues Consider complexity-gain trade-off q n private networks vs. access vs. inter-provider 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