Emergency Services for Internet Communications IETF ECRIT Working Group Fall VON 2005

1
Emergency Services for Internet Communications
IETF ECRIT Working GroupFall VON 2005

• Hannes Tschofenig (Siemens)
• Marc Linsner (Cisco)
• Working Group Chairs

2
IETF Work Group

• ECRIT Emergency Context Resolution using
  Internet Technologies
• BOF IETF61(Washington, Nov. 2004)
• BOF Chairs Jon Peterson, Hannes Tschofenig
• Official WG, first meeting in Minneapolis
  (IETF62) on March 9
• Chairs Hannes Tschofenig, Marc Linsner
• Working group had an interim meeting in New York
  (Columbia University), May 2005
• Charter Page
• http//www.ietf.org/html.charters/ecrit-charter.ht
  ml
• Weblog
• http//www.ietf-ecrit.org
• Narrowly chartered to deal with how to route
  emergency calls.
• You would like to learn more about the IETF
• Look at IETF Education Team http//edu.ietf.org/

3
ECRIT Topics (1/2)

• Terminology and requirements
• Threats and Security Considerations
• Identify an Emergency Call

• Currently actively discussed
• draft-taylor-ecrit-security-threats-00.txt
• draft-ietf-ecrit-requirements-00.txt

4
ECRIT Topics (2/2)

• Mapping protocol
• ... and some more topics
• Good news IETF protocols offer a good source for
  reuse.

5
ECRIT Relationships

• IETF Geopriv Working Group
• Location Information based on GML (civic and
  geospatial) http//www.ietf.org/internet-draft
  s/draft-ietf-geopriv-pidf-lo-03.txt
• Distribution of location information in DHCP
  RFC 3825 http//www.ietf.org/internet-drafts/dr
  aft-ietf-geopriv-dhcp-civil-07.txt
• SIP working group
• Plenty of SIP protocol specific work
• Session Initiation Protocol Location Conveyance
  http//www.ietf.org/internet-drafts/draft-ietf
  -sip-location-conveyance-01.txt

6
Architectural Considerations (1/3)

• Who knows the location of the end host?
• Often the access network, the Internet service
  provider and the application service provider are
  different parties.

OSI Model
Common point - The end device!
VoIP, Inc. (Application Service Provider)
Layer 7
ISP, Inc. (Internet Service Provider)
Layer 3
Last Mile, Inc. (Access Provider)
Layer 2
7
Architectural Considerations (2/3)
SIP Proxy
extract locationidentity determine
language determine media
911
Contact PSAP
Phone
PSAP
Fetch Location
Determine PSAP
Distributed Directory
Query / Response Protocol
48 49' N 2 29' E ? Paris fire department
Assumption Network intermediary is able to
obtain location of end host.
8
Architectural Considerations (3/3)
extract user locationidentity determine
language determine media
Contact PSAP
PSAP
Phone
Fetch Location
Query / Response Protocol
determine PSAP location
Distributed Directory
48 49' N 2 29' E ? Paris fire department
9
Next Steps Develop Mapping Protocol (1/2)

• A few proposals are available for discussion
• Location-to-URL Mapping Protocol (LUMP)
• http//www.ietf.org/internet-drafts/draft-schul
  zrinne-ecrit-lump-00.txt
• Emergency Call Information in the Domain Name
  System (DNS-SOS)
• http//www.ietf.org/internet-drafts/draft-rosen
  -dns-sos-02.txt
• An IRIS Schema for Emergency Service Contact URIs
  (ECON)
• http//www.ietf.org/internet-drafts/draft-hardi
  e-ecrit-iris-01.txt
• Requirements and security threats need to be
  understood before the work on the mapping
  protocols can be completed.

10
Next Steps Challenges (2/2)

• A number of security threats need to be
  addressed.
• The typical solution, namely cryptography, cannot
  be applied in all cases.
• Difficult part Denial of Service
• Example Adversary places an emergency call and
  attaches the wrong location information.

Denial of Service Layers of Defense
11
Questions?