1. Internet Protocol-based Emergency Services Hannes Tschofenig 112 Rescue Forum, 11 th October 2012, Žilina, Slovakia

2. Agenda Background NG112 Location Security

3. What is EENA? EENA, the European Emergency Number Association, is a Brussels- based NGO set up in 1999 dedicated to promoting high-quality emergency services reached by the number 112 throughout the EU. EENA serves as a discussion platform for emergency services, public authorities, decision makers, associations and solution providers in view of improving emergency response in accordance with citizens’ requirements. EENA is also promoting the establishment of an efficient system for alerting citizens about imminent or developing emergencies. The EENA memberships include 700 emergency services representatives from 43 European countries, 57 solution providers, 9 international associations/organisations as well as 25 Members of the European Parliament.

4. EENA Structure 112 ESSN Emergency Services and Authorities (700 members in September 2012) MEPs 112 Champions Members of the European Parliament + EENA Advisory Board Private Companies, International Organisations and Associations Network of Researchers Researchers on emergency services issues NG112 Committee112 Operations CommitteeLegal Committee

5. Transition to Internet Protocol-based communication infrastructure is progressing world-wide. Operators develop migration plans –For cost efficiency reasons it is not reasonable to maintain two infrastructures in parallel Many vendors discontinue support for legacy equipment End users are more and more familiar with the (mobile) Internet. New communication techniques emerge all the time. –Think about social networking, smart phone applications, and VoIP/IM systems. Industry Trends

6. "It's hard to imagine that airlines can send text messages if your flight is delayed, but you can't send a text message to 911 in an emergency." He continues, "The unfortunate truth is that the capability of our emergency- response communications has not kept pace with commercial innovation, has not kept pace with what ordinary people now do every day with communications devices." FCC Chairman Julius Genachowski August 2011

7. They decided to work together to ensure every European can access a 112 smartphone app, in their own language. This announcement was made on the European 112 day when surveys revealed that "74 % of Europeans don't know what emergency number to call when traveling in the EU". EC VPs Neelie Kroes & Siim Kallas February 2012

8. NG112

9. Why do you want IP? There are four reasons: 1. Lower CAPEX: commodity nature and competition lowers prices 2. Lower OPEX compared to legacy infrastructure 3. Future proof technology: The rest of the industry is moving to IP. 4. More functionality (e.g., multi-media support, data sharing) and better extensibility.

10. It’s just an IP network, nothing at all special about the network. –It’s private and managed but it is not a walled garden. –Redundant links for improved availability. Allow PSAPs to get VoIP calls from VSPs and data from location servers. Connect PSAPs among each other for overload situations. Sometimes integrated into a larger public safety network. E.g., Finland Emergency Services IP network (ESInet)

11. EENA NG 112 Overview

12. EENA NG 112 Overview, cont. The scope of the specification starts with the Border Control Function (a IP-based application layer firewall) or legacy network gateway, and ends with the PSAP. As such, the initial call routing to the edge of the ESINet has already happened. Additional call routing may happen within the ESINet and the specification describes this functionality. Examples: overload handling, bridging, routing based on call taker skills. ESINet operator relies on external input (e.g., location, emergency call). ESINet offers functions to external entities (e.g., routing information).

13. In March 2011 we published the Introduction to the European Next Generation 112Introduction to the European Next Generation 112 A requirements analysis for NG112 was conducted and matched against the service requirements developed by the operations committee.requirements analysis Mid 2011 we did a poll in the NG112 TC on the next steps for the work on the technical architecture. –Group reinforced the desire to progress the work on the NG112 LTD document. NG112 Long Term Definition Background

14. NG1-1-2 meets Operational Requirements 1.Standards based approach 1.Geo-Location conveyance 2.PSAP – interface 3.Call Routing 2.Multi-Media communications with citizens 3.Emergency Services Interoperability NG1-1-2 LTD Scope Q13: 98% yes Q8: 100% yes Q5: 95% yes Q9: 72% yes Q4 : 97% yes Q11: Avg. 3,65 (1 = less important; 5 = very important) EENA Survey 8/11 Survey can be found here: http://www.eena.org/ressource/static/files/2011_09_08_ng112opreqsurvey_v1.2.pdf http://www.eena.org/ressource/static/files/2011_09_08_ng112opreqsurvey_v1.2.pdf

15. NG112 Long Definition Document Document Objectives Define a long term architecture for European Emergency Services based on the i3 architecture i3 was developed by the National Emergency Number Association (NENA) http://www.nena.org/ Compatible with NENA i3 Compatible with European Emergency Services organisations See also EENA publication about PSAP in EuropePSAP in Europe

16. Publication Next Generation 112 Long Term Definition Document Final NG112 Long Term Definition document was approved by mid of April and officially published Link to the document A plenary session and a technical session were dedicated to this document during the EU Emergency Services Workshop 2012 in Riga (18-20 April). Link to the plenary presentation Link to the technical session presentation The document was also presented in the last Experts Group on Emergency Access (EGEA) meeting. Link to the presentation

17. NG 112 Overview, cont. If you do not want IP-based PSAPs then the NG 112 specification is not relevant for you. The NG112 specification helps you to deploy a system that re-uses the work from various standards organizations (e.g., 3GPP, IETF, OMA, OGC) builds on IP, SIP & HTTP, has gotten extensive reviews, and lowers vendor lock-in.

18. Scope of EENA NG112 Copyright – Guy Caron (ENP)

19. Extensibility

20. Last Mile, Inc. (Internet Access Provider) ISP, Inc. (Internet Service Provider) VoIP, Inc. (Application Service Provider) Layer 7 Layer 1/2 Layer 3 End Host Remember: Layering in the Internet Architecture

21. Interworking with other Systems Emergency services build on top of existing communication architectures. Standardized communication architectures are available with SIP-based IMS (as defined by 3GPP) SIP-based VoIP (as defined by IETF) XMPP-based IM/VoIP (as defined by IETF & XSF) RTCWeb (as currently work in progress by IETF & W3C) Also many non-standardized communication architectures available (e.g., Skype, many Smart Phone Apps)

22. http://www.amazon.com/SIP-Demystified-Gonzalo- Camarillo/dp/0071373403http://www.amazon.com/SIP-Demystified-Gonzalo- Camarillo/dp/0071373403 http://www.amazon.com/3G-IP-Multimedia- Subsystem-IMS/dp/0470516623http://www.amazon.com/3G-IP-Multimedia- Subsystem-IMS/dp/0470516623 Are you familiar with SIP and IMS?

23. Interoperability IP-based PSAP VSP or Gateway Emergency Call Dial 1- 1-2 Emergency Call Skype, PSTN, eCall, Smart Phone App SIP based on NG112 Communication Architectures

24. Interoperability, cont. Three features have to be provided by a communication architecture in order to work (failure-free and robust) with the NG112 architecture: (I)Ability to identifying an emergency call and to communicate the emergency call to the VSP. (II)Ability to communicate location and/or a location key (III)Ability to convey multi-media content (which is the actual emergency communication)

25. Location

26. Two types of usages: 1. Location for routing of the call to the PSAP 2. Location for dispatch of first responders. Requirements for the two vary considerably. Two types of location formats: Civic Location Address Geodetic Location Address Location encoding and formats had been standardized long before the EENA NG112 work started.

27. Location for Routing Three approaches possible: (1) Use whatever you have and use it. (2) Use only those mechanisms that always work. (3) Use no location: statically provisioned routes

28. Location Technologies Overview User Provided Example: User configures location with VSP when registering for the service. Device-based Example: GPS Network operator-based Examples: ISP-operated location servers Third party services Examples: WiFi SSID & Cell ID databases, IP-to-geolocation databases More detailed discussion about location technologies: http://www.eena.org/ressource/static/files/2011_05_27_2.2.2.cl_v1.3.pdf Subsequent pictures taken from Martin Dawson presentation: http://www.eena.org/ressource/static/files/commscope-eena-mobilelocation-april-2011.pdf

29. Difference in Location Technologies Cell ID

30. Difference in Location Technologies Enhanced Cell ID

31. Difference in Location Technologies A-GPS

32. Call Routing

33. Emergency Call Routing Main Options I)End host driven Model End host obtains location End host triggers resolution (which also provides information about the supported emergency services numbers) II)Proxy driven Model VSP obtains location VSP determines ESRP/PSAP. Various variants possible and described later.

34. 1.Calling device discovers the location server and gets location 2.Calling device discovers routing server and gets correct emergency service gateway address 3.Calling device address call to the emergency service gateway, includes location and sends to the voice provider. 4.Voice provider routes the call to the emergency service gateway 5.Emergency service gateway gets an updated location 6.Emergency service gateway uses the route server to get the correct PSAP to send the call to. 7.Emergency service gateway routes the call to the PSAP 8.PSAP gets an updated location if required. Emergency Call Routing Device Centric Model

35. Emergency Call Routing Switch Centric Model 1.Caller makes a call 2.Voice provider determines correct LIS and requests location 3.Voice provider determines route server and requests a route to the emergency service gateway 4.Voice provider routes the call to the emergency service gateway including location. 5.Emergency service gateway gets an updated location 6.Emergency service gateway uses the route server to get the correct PSAP to send the call to. 7.Emergency service gateway routes the call to the PSAP 8.PSAP gets an updated location if required.

36. Emergency Call Routing Variations A)Single PSAP or PSAP operating for the entire country. In this case the granularity of the location information only needs to be on a country level. This can easily provided by many of today’s location based services (e.g., IP-to-geolocation). Example: UK

37. Emergency Call Routing Variations, cont. B) Emergency Services Routing Proxies (with many PSAPs per country) Only country-level location granularity is needed to find one of the ESRPs. ESRPs can (automatically and without human involvement) retrieve more accurate location from ISPs/IAPs, when needed. Example: Variation of the Swedish deployment. German eCall approach in HeERO project.

38. Emergency Call Routing Variations, cont. C) ISPs provide Rough Location to End Hosts (for routing only) The level of provided location information depends on the number of PSAPs. Solution described in IETF ECRIT WG. D) ISPs provide ESRP URI (instead of location) to end hosts. This allows the VSP to route the call to the nearby PSAP based on the provided URI.

39. Currently discussions ongoing in the ETSI M493 group on call routing architectures. More details: –http://www.112.be/ressource/static/files/m49 3_en.pdfhttp://www.112.be/ressource/static/files/m49 3_en.pdf –”The objective of this Mandate is to stimulate further standardization work in this field to support harmonized European solutions also with regard to cost effective implementations.” My personal opinion: –Challenges are on the regulatory side (and not on the technical side). Emergency Call Routing Still work in progress

40. Security

41. Approaching security follows a process: –1. What are your threats? –2. What security requirements can you derive from these threats? –3. What ways to fulfill the security requirements do you have at your disposal? The EENA NG112 LTD document has an extension security chapter:EENA NG112 LTD document –15+ pages in Section 6 The existence of malware botnets has to be considered as well. (not just a theoretical threat) Security Overview

42. Resource consumption at the PSAP based on false calls is one biggest security threats: –See also EENA publication on this topic: http://www.eena.org/ressource/static/files/2011_03_15_3.1.2.fc_v1.0.pdf http://www.eena.org/ressource/static/files/2011_03_15_3.1.2.fc_v1.0.pdf Many of the reasons for false calls cannot be “solved” via technical means only. Note: Problem is not unique to IP-based emergency services. Legacy networks also suffer from these problems. Security False Calls

43. Location is spoofable to a certain degree –Location configuration steps are vulnerable to manipulation. –Particularly true for location determination techniques that provide better location accuracy. Focusing only on network provided location rules out –many practical deployments, and –many high quality location techniques. Security Location Spoofing

44. Before the Fact: Prevention or degradation –Example: Disallow SIM-less emergency calls Ongoing: Attribution as a part of normal activity –Example: Education about cost of emergency services infrastructure. During the Fact: Mitigation –Example: Signal ‘false call’ warning to caller. After the Fact: Retribution –Example: Prosecute Security When to react?

45. Design for global interoperability to gain from the economic benefits and to better support citizens. –Consider how to interwork with out-of-country VSPs Location: –Participate in the ongoing EC location accuracy discussion. Routing: –Join the discussions at the EENA NG112 and the M493 group on emergency call routing. Security: –A complex topic that requires more discussion. Help us to improve the state of the art The number of VoIP/Real-Time Text/Instant Messaging emergency calls will be low at the beginning. –Start early with a small deployment. Conclusions