1. Emergency Services IAB Tech Chat 28 th February 2007 Hannes Tschofenig

2. Outline  Introduction  The Building Blocks  Architectural Models  Challenges  How the IAB can help us

3. Introduction  Authority to Citizen  Example: Cell broadcast for Tsunami warning  Authority to Authority  Example: Communication between emergency personnel  Citizen to Authority  Example: VoIP emergency call Authorities Citizen Note that some SDOs use the term “individuals” instead of “citizen”.

4. History JFMAMJJASONDJFMAMJJASOND 20042005 ECRIT BOF 1 st ECRIT WG Meeting IETF ECRIT WG 1 st ECRIT Interim Meeting IETF#63 JFMAMJJASONDJFMAMJJASOND 20062007 2 nd ECRIT Interim Meeting 4 th ECRIT WG Meeting IETF ECRIT WG 5 th ECRIT WG Meeting IETF#62IETF#61 2 nd ECRIT WG Meeting 3 rd ECRIT WG Meeting IETF#64 IETF#65 IETF#66 IETF ECRIT – 3GPP Workshop 1 st SDO Emergency Services Workshop 2 nd SDO Emergency Services Workshop IETF#67IETF#68 6 th ECRIT WG Meeting IETF ECRIT – IEEE Workshop 7 th ECRIT WG Meeting

5. Links  Joint IETF ECRIT / 3GPP Emergency Services Workshop http://www.ietf-ecrit.org/3GPP-IETF-2006/  SDO Emergency Services Coordination Workshop (ESW06) http://www.emergency-services-coordination.info/2006/ http://www.emergency-services-coordination.info/2006/slides/  IETF ECRIT / 3GPP / TISPAN Emergency Services Work http://www.shingou.info/twiki/bin/view/EmergencyServices/EmergencyTopics  Reviews by VoIP providers still ongoing.

6. The ECRIT Universe ECRIT GEOPRIV SIP OGC Regulators Open Geospatial Consortium (OGC) NENA, TISPAN, EMTEL, ATIS 3GPP, 3GPP2, IEEE, ITU-T, PacketCable DSL Forum, Wimax, OMA, TIA, OASIS,

7. Architectural Considerations Last Mile, Inc. (Access Provider) ISP, Inc. (Internet Service Provider) VoIP, Inc. (Application Service Provider) Layer 7 Layer 2 Layer 3 Common point - The end device!  Two main questions:  Who knows the location of the end host?  What is the relationship between access network provider and application service provider?

8. Building Blocks

9.  Manual configuration  GPS  Link layer mechanisms (e.g., LLDP-MED, ongoing work in the IEEE)  DHCP (civic and geospatial) RFC 4776 for civic location information RFC 3825 for geodetic location information  Application layer protocols (e.g., Geopriv L7 LCP, OMA) Location Configuration

10. Building Blocks

11.  Purpose  For UA : To indicate emergency call  For Proxies: To handle the emergency call specially  For Mapping Protocol: To resolve to PSAP URI  Emergency Identifier  draft-ietf-ecrit-service-urn-05.txt  Example: urn:service:sos Identifying an Emergency Call Emergency Numbers

12.  Emergency numbers vary in countries  Example: 911 for North America, 112 for Europe  some countries uses separate numbers for ambulance/police/fire  Required to support both home and visited emergency number  e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency  Configuration of emergency numbers and dial strings important  Home Emergency Number: User can set his/her home country through device configuration.  Visited Emergency Number: Obtained via LoST Emergency Numbers

13. Building Blocks

14. Location-to-Service Translation (LoST)  Status: WGLC started  http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ + Location Information (PSAP) URI Service Identifier Service Number Service Boundary + +

15. LoST Architecture T1 (.us) T2 (.de) T3 (.dk) G G G G G broadcast (gossip) T1:.us T2:.de resolver seeker 313 Westview Leonia, NJ US Leonia, NJ  sip:psap@leonianj.gov tree guide

16. Building Blocks

17. Architectural Models  Model 1: Location Information is available to End Host  This allows UA recognition & UA resolution as well as UA recognition & Proxy resolution  Model 2: Reference to Location Information is available to End Host  Might translate to model 1 if end host is allowed to resolve the reference  Translates to model 3 if end host is not allowed to resolve the reference (but relaxes assumptions of model 3)  Model 3: Location Information is NOT available to End Host  Assumption: SIP intermediaries are in the access network (or have a very close relationship to them)  Proxy recognition & Proxy resolution is a subcase of this model.

18. Mapping Server SIP proxy PSAP / Call Taker (1)Location Location + Service Identifier (2) PSAP URI + service number (3) INVITE PSAP URI To: urn:service:sos (5) INVITE PSAP URI To: urn:service:sos (6) (4) dial dialstring UA Recognition & UA Resolution  Location Information is provided by the access network.  IETF ECRIT preferred emergency service architecture  SIP Proxy is user’s preferred SIP provider. It may re-run LoST SOS caller

19. PSAP / Call Taker Mapping Server SIP proxy SOS caller (3)Location Location + Service Identifier (4) PSAP URI (5) INVITE urn:service:sos To: urn:service:sos (2) INVITE PSAP URI To: urn:service:sos (6) (1) dial dialstring Location Server UA Recognition & Proxy Resolution  Assumes that SIP proxy is able to determine the end hosts location information.  This assumes a close relationship to the access network

20. PSAP / Call Taker Mapping Server SIP proxy (3)Location Location + Service Identifier (4) PSAP URI (5) INVITE sip:911@domain To: sip:911@domain (2) INVITE PSAP URI To: urn:service:sos (6) (1) dial dialstring Location Server Proxy Recognition & Proxy Resolution  End host does not understand emergency service concept.  Legacy support scenario SOS caller

21. Challenges  Security Threat model assumes that the end host is not trustworthy.  Location Information Too many protocols to obtain location information are available. They also use different formats.  Regulators Regulators have a lot to say. Unfortunately, very little detailed guidance is available.  Business Models No unified architecture (too many cooks). Business models impacting architectural design

22. Challenge: Security  Example security threats: “location spoofing”, prank calls, fraud  Countermeasures:  Real-Time Check: PSAP receives a call with faked location information.  Determine identity of adversary for later prosecution.  Aspects are discussed mostly in GEOPRIV WG since the solutions refer to protocols developed there.  Further reading: Overview Paper on Security (NetCri Workshop 2007) http://www.shingou.info/Emergency-Service-Security.pdf http://www.shingou.info/Emergency-Service-Security.pdf

23. Challenge: Location Information  To accomplish interoperability in the Internet either the network or the end host need to implement all location configuration protocols.  Location information differ in the format and the functionality (e.g., OMA and OGC GML).  Maybe a job for the IAB liaison persons but might be too late already.  Alignment between IEEE and IETF GEOPRIV is quite good.  Architectural assumptions of some Location Configuration Protocols are not compatible; not only the format.

24. Challenge: Regulators  So far no indication from the regulator side regarding  preference for one of the architectural models  confidentiality protection of emergency calls  unauthenticated network access  priority for emergency services (  QoS and IEPREP-like mechanisms)  unauthenticated emergency call  requirements on network providers to disclose location information

25. Example: Unauthenticated Network Access  Bob wants to make an emergency call  Assume he is not yet attached to a network.  Assume he has no credentials for this particular network.  Bob uses a special link layer attachment procedure to attach to the network without authentication and authorization.  Bob initiates the emergency call.  How does the access network know whether Bob is really making an emergency call or not just calling his friend for free?  Answer: 1)It understands the concept of SIP-based emergency calls OR 1)It tunnels all emergency traffic to someone that understands it.

26. Challenge: Business Models Request Location Reference Location Reference PSAP Location Server @ Access Network End Host Dereference

27. Challenge: Business Models  Location-by-reference itself is not a bad concept; but it can be misused  The problem appears if access network providers only want to make location only available to “authorized” entities.  Authorized could mean only to entities that have a business relationship with the access network provider.  Without location information location-based routing does not work.  If VoIP has to do location-based routing then it need create business contracts with access providers.  There are many VoIP providers and even more access providers  impractical solution

28. How the IAB could help us  Interacts with other SDOs  “SDO Emergency Services Workshop” (April 2007) is only one event in the overall stream of activities  Help us to investigate security aspects of the emergency services architecture  Develop an IAB position on the IETF emergency service architecture  Provide input to the long ongoing GEOPRIV L7 LCP discussion  Help to educate regulators  Interact with PSAP operators (and regulators) regarding the public availability of PSAP boundary data. This is important for a robust global LoST architecture.