1. Emergency Services for Internet CommunicationsIETF 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 IETF#61(Washington, Nov. 2004) • BOF Chairs: Jon Peterson, Hannes Tschofenig • Official WG, first meeting in Minneapolis (IETF#62) 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.html • 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/ VON Fall 2005

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 VON Fall 2005

4. ECRIT Topics (2/2) • Mapping protocol • ... and some more topics • Good news: IETF protocols offer a good source for reuse. VON Fall 2005

5. ECRIT Relationships • IETF Geopriv Working Group: • Location Information based on GML (civic and geospatial) http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt • Distribution of location information in DHCP RFC 3825http://www.ietf.org/internet-drafts/draft-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 VON Fall 2005

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 VON Fall 2005

7. Architectural Considerations (2/3) • SIP Proxy extract location+identity+… 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. VON Fall 2005

8. Architectural Considerations (3/3) extract user location+identity+… 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 VON Fall 2005

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-schulzrinne-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-hardie-ecrit-iris-01.txt • Requirements and security threats need to be understood before the work on the mapping protocols can be completed. VON Fall 2005

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 VON Fall 2005

11. Questions? VON Fall 2005