Priority for emergency communications

Henning SchulzrinneDept. of Computer Science, Columbia UniversityComCARE Priority Data SummitSeptember 15 & 16, 2004

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

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

Two view of priority

1. Civilian vs. emergency coordination assume that there is enough capacity for emergency

coordination same entity may be both (e.g., school)

2. 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

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

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…)

Internet architecture issues

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

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

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)

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

Overall architecture

AQM – active queue management packets can be assigned to treatment by

short label carried in packet DiffServ property (source/destination address) IntServ

filtermanagement

trafficfiltering

traffic shaping,handling & measurement

IntServ

DiffServ

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

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

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

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)

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

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

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.”

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)

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

DiffServ operation

draft-baker-diffserv-basic-classes

Service class traffic characteristics loss delay jitter

administrative small packet size, one packet at a time very low very low yes

network control inelastic short messages, can burst (BGP) low low yes

telephony fixed-size packets, inelastic very low very low very low

signaling variable-sized packets, short-lived flows low low yes

multimedia conferencing

reacts to loss low - medium very low low

real-time interactive RTP/UDP, inelastic low very low low

multimedia streaming elastic with variable rates low-medium medium yes

broadcast video inelastic very low medium low

low-latency data telnet, ssh low 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 not specified

low-priority data non-real time and elastic high high yes

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

QoS-NSLP node architecture

GIMPS

QoS-NSLPresource

managementpolicycontrol

packetschedulerpa

cket

clas

sifie

routgoinginterfaceselection

(forwarding)

input packetprocessing

traffic control

select GIMPS packets

API

forwarding tablemanipulation

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)

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

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