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 lt 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
DiffServ
traffic shaping, handling measurement
traffic filtering

• AQM active queue management
• packets can be assigned to treatment by
• short label carried in packet ? DiffServ
• property (source/destination address) ? IntServ

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_at_fema.gov,
  bob_at_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 users 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 ltdraft-ietf-ieprep-domain-fr
  ame-01.txtgt
• summarizes existing techniques, such as
• 802.1d (802.1p)
• MPLS
• RSVP
• DiffServ

21
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 not specified not specified
low-priority data non-real time and elastic high high yes
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
packet classifier
input packet processing
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.
• Cant have individual accounts on all systems
• Thus, need national firemans 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