Author Archives: Hannes Tschofenig

About Hannes Tschofenig

Hannes Tschofenig lives in Finland and is employed by Nokia Siemens Networks (NSN). In his last 10 years of IETF involvement he has been interested in security, privacy, and emergency services. Hannes co-chaired the IETF ECRIT working group from 2005 to early 2010. For his work in the area of IP-based emergency services he received the ‘Outstanding Vision for 112′ award from the European Emergency Number Association (EENA) and later even became the co-chair of the EENA Next Generation 112 Technical Committee. He contributed to the technical specifications developed within the National Emergency Number Association (NENA), is a contributor to the work in the ECRIT as well as the IETF GEOPRIV working group, and co-chairs the Emergency Services Workshop series. He has published several articles on emergency services, including an article on ‘Emergency Services for Internet Multimedia’ in the December 2010 edition of the IP Protocol Journal and a CACM article on ‘Security Risks in Next-Generation Emergency Services’ from November 2011. Hannes co-chaired the IETF Provisioning of Symmetric Keys (keyprov) and the Diameter Maintenance and Extensions (dime) working groups. Currently he co-chairs the Web Authorization Protocol (OAuth) working group developing solutions for secure and privacy-friendly data sharing on the Internet. Hannes frequently gives talks about various security and privacy related topics and is a Certified Information Privacy Professional/Europe (CIPP/E) of the International Association of Privacy Professionals (IAPP). As an active participant with over 40 RFCs he likes to work with others in different areas in the IETF.

Support our Next Generation 112 Interoperability Testing Efforts!

Those who have followed the work in the European Emergency Number Association (EENA) know that we have been trying to initiate interoperability testing events for some time now. Testing implementations of the next generation protocols developed by various major standardization organizations (e.g., IETF, 3GPP, IEEE, OMA, NENA, ETSI, and EENA) will help us to detect bugs in open source libraries and commercial software, to foster information exchange between equipment vendors and infrastructure providers along the entire emergency services value chain, to reveal gaps in protocol specifications, and will also help the wider eco-system to gain more confidence in the reliability, security, and stability of the next generation emergency services system. Ultimately, we all will benefit from a working emergency services infrastructure.

Organizing interoperability events does, however, require resources for preparing the test specifications, for arranging the face-to-face interop events itself (e.g., cost for renting rooms and network infrastructure, travel support for participants), for marketing and outreach, and for conveying results back to various organizations.

To provide a platform for these interoperability testing events we need your help: with your support we would like to convince the European Commission to consider supporting the call for such a testing program.

Download the EENA support letter or view it here:

Please indicate your support via this website or by sending a mail to Hannes Tschofenig ht@eena.org and/or to Jerome Paris jp@eena.org.

Your support is crucial: if you support such a testing programme, could you please respond at latest by Tuesday, June 4th indicating “I support this paper”.

Location, Location, Location …

At the EU Emergency Services Workshop 2013 a regulatory issues panel moderated by Tony O’Brien (Deputy Executive Director, EENA). The panel discussed a couple of topics, including the need for standards, performance indicators, and location. The location slot lead to a heated discussion with the following persons on the panel: Raed Arafat (Secretary of State for Health, Romania), Laszlo Toth (Policy Director, GSMA Europe), John Medland (999/112 Policy Manager, BT), Paulo Pereira (ANACOM, Portal), Florin Dragomir (National Authority for Management and Regulation, Romania), and Gyula Bara (European Commission).

Here is a little bit of background: Emergency calls require location information for three reasons: (1) location is necessary to route the emergency call, (2) to dispatch first responders the location of the person seeking help is needed, and (3) emergency numbers are often interpreted in context of location since different numbers are used in different countries. In the context of this panel discussion the focus is on location for dispatch.

In general, more accurate location is better for emergency services organizations since it allows to dispatch first responders faster, particularly with incidents in rural areas where search can take a longer time and tends to be more costly.

With regard to location accuracy in Europe emergency services authorities receive cell-id location. Cell-id location is rather coarse grained. Better location determination mechanisms are available to-do that offer much better accuracy and those have been deployed in the US for some time already.

The discussion that surfaced again in Europe was whether requirements for better location accuracy should be introduced because industry (mostly telecommunication operators) does not deploy them by themselves. For some reason mobile phone operators have not been able to develop a business model for location-based services that would justify the investments into their networks. Consequently, the technology is not deployed in mobile networks today in Europe. Should the European Commission and national regulators therefore demand the deployment of this location technology? Should other approaches (such as utilizing location available at smart phones) be re-used?

Here is a recording of the discussion and make your own judgement.

[display_podcast]

Interview: Mark Fletcher interview about NG 112

Last week EENA organized their yearly EU emergency services workshop in Riga/Latvia. As in the past many emergency services authorities, regulators, vendors, and service providers showed up to discuss the hottest topics.

I had the pleasure to meet Mark Fletcher again, who arrived in Riga with his podcasting equipment.

Mark Fletcher

Mark interviewed me about the Next Generation 112 work done in EENA as it was again on the agenda of this meeting because of the recently shipped update of the specification.

Here is the podcast:

[display_podcast]

Mark regularly interviews folks from the emergency services community in his E911 podcast series.

Chat with Mark Fletcher

Challenges for Emergency Services Standardization for the Mandate 439

Standardization of IP-based emergency services systems is ongoing for more than 10 years and many of the specifications have been completed already in the IETF, 3GPP, NENA and EENA.

Nevertheless, new emergency services standardization efforts are born. One of these newly added activities is the work in the ETSI M493 group (which is now transitioned to the E2NA). You may not have heard about it. This is not your fault: information about the M493 group is hard to find in the Internet. This write-up aims to provide some insight.

The story starts in March 2011 when the EGEA COCOM group [0] met and discussed the current status of emergency services development in European member states. As an outcome of the meeting a new mandate, namely EC M/493 [1], was published.

In this mandate the European Commission asks European Standards Organizations to work on caller location standards for usage with emergency services in an IP environment. ETSI kindly accepted the mandate and created a new group – the M493 group.

Bundesnetz Agentur - the most recent M493 meeting location.

Bundesnetz Agentur – the most recent M493 meeting location.

This group has now been working on a stage 2 document on a new emergency services architecture since early 2012. In a nutshell, the architectures describes how emergency calls are initiated from the end device, travel via the VoIP service provider (VSP), through the emergency services network to the PSAP. The VSP interacts with the access network provider to obtain a reference to location information and routing information. The VSP then uses this information to route the call to the PSAP (via a sort-of IP-based emergency services network). The PSAP or the emergency services network use the location reference to exchange it for location.

While there has been progress to develop this architecture document the group ran into a couple of problems. Here is a list of challenges as I see them.

0. A mandate is not a requirements document.

When the work in the M493 group was started the charter of the group was developed based on the text from the mandate. The members in the group had envisioned that the mandate would be used to shed light on specific protocol design requirements or that the European Commission would participate in the meetings to provide additional insight into their thinking.

Unfortunately, the European Commission does not participate in the work directly and attempts to solicit feedback naturally take time. An official letter with the questions has to be written and agreement within the group has to be found regarding the proper wording. Feedback is also not available immediately.

In retrospect it would have been more useful to develop a requirements document that can be discussed with the European Commission.

1. Location from the end host is considered harmful.

The M493 architecture assumes that location information comes from the access network provider only; information from the end device itself is untrusted. The concern is primarily driven by fears about security problems PSAP operators may encounter. The IETF ECRIT working group has worked on a document, called “Trustworthy Location” [2], that illustrates the problems. That document also points to the challenges with a pure location-based view and urges to look at the larger picture (and at other information associated with the call, such as identity information).

There is, however, a lot of missed opportunity here since there is a lot of development in the area of location based services at the end device (based on GPS integration into mobile phones but also based on third party location based services). These location-based services will not be re-usable in the M493 architecture as it currently seems.

The current architecture assumes that location is available for every IP caller everywhere from day one. There is no transition story for how to get to the final deployment stage.

It is also worth noting that location servers not only need to be available with every access network but also within enterprise networks. This is because the VSP uses the source IP address of the incoming call setup message to find a location server. When an end user utilizes a VPN then that lookup will resolve to the IP address obtained by the VPN and does not represent the IP address the end device has obtained from the access network provider. In addition to enterprise networks that are impacted any infrastructure provider who terminates tunnels (like IPv4-IPv6 transition gateways, VPNs, mobility anchor points, or TURN servers) is impacted. It is hard to say how large the number of impacted networks actually is.

In case you are hoping for a shift to better location for emergency services you may be disappointed. In Europe emergency services typically only have access to location at the granularity of cell ids (for cellular services). This is not likely going to change with this architecture either since the development or selection of location determination techniques are not scope of the group.

2. Focus on voice only.

The mandate by the European Commission puts a focus on voice services and the expertise in the group is on voice services only. Any considerations regarding multi-media emergency calling have been excluded and therefore the outcome may not work sufficiently well with media other than voice. This direction is also driven by the main proponents who have an integration with the current PSTN in mind, which does not support multi-media communication either.

3. Regulating VoIP providers is hard.

The current regulation on emergency services uses E.164 numbers to decide whether a company is covered by regulation or not. While this is a reasonable approach for past telecommunication infrastructure many communication services today do not use E.164 numbers. Consequently, they are not covered by regulation either. This regime seems to have been carried over to the IP world. Whenever the VSP is separate from the access network provider, which is the case for many Internet communication services and the VSP offers services outside their own country the situation gets challenging. How should the regulator impose obligations on VSPs that may essentially be located anywhere?

4. Operational complexity added.

While the M493 architecture does not require any location-to-service infrastructure like the IETF proposes with LoST it creates operational complexity.

First, the VSP is likely in the need to establish a relationship between the access network operator for the interaction with the location server. It is not likely that these location servers will be accessible for everyone on the Internet.

The next relationship that is requires is between the VSP and the emergency services provider. Here, it is also likely that a VoIP peering relationship needs to exist in order to route emergency calls from the VSP to the emergency services network. Unlike in many other architectures this emergency services network is envisioned to be operated by telecommunication operators, at least in the countries that participate in the work. This may allow a flow of money from the VSP to the provider of that emergency services network.

Finally, there is a relationship between the access network operator and the PSAP & emergency services network. This relationship is needed establish the necessary security infrastructure (such as the exchange of keys) for retrieval of location information.

5. Access Networks have no call visibility.

While the location retrieval and routing strategy follows the old telecommunication model the interaction between the end device and the VSP for emergency call handling is modern. Since one of the most popular example of an over-the-top VoIP provider is Skype and Skype uses a proprietary protocol the interaction between the end device and its VSP is left unspecified.

This also means that an emergency call itself is not understood by the access network and therefore no QoS treatment or preferential treatment of the call setup will be guaranteed for OTT providers. This also means that telecommunication operators that block certain VoIP services, or execute traffic management practices may accidentally block emergency calls or make them fail in other ways.

6. Current deployments respected.

The mandate points to the importance of considering current deployments and to consider them in the design.

While this is clearly a good idea it leads to various challenges. First, since almost no emergency services authorities are present in the discussion it is almost impossible to argue how the current emergency services deployment in Europe (from a technical point of view) looks like.

Even more important than the current deployment situation is the vision for the future since the transition to IP allows a number of short-comings of the current system to be corrected. Also in terms of finance it would be useful to make changes. In most cases emergency services authorities know about the deployment status and barely anyone else.

Consequently, the current deployment situation is mostly guessed (if considered at all).

7. Stakeholders missing.

The most severe aspect of the entire work is the lack of participation from a large part of the stakeholder community. While the European Commission may have hoped to involve more European stakeholders in the conversation it unfortunately turned out to be far less than available in other forums. This may have many reasons, including the cost of the participation in ETSI, lack of interest, recognition of ETSI in the standardization world, or the missing outreach.

In particular, the following stakeholders are largely absent:

  • Emergency services authorities: For most meetings no emergency services authorities are present.
  • Emergency services equipment vendors: Only telecommunication equipment manufacturers are present.
  • VoIP providers, and OTT players in general: Only Microsoft is present.
  • Regulators: only two regulators participate in the work.
  • Enterprise networks. No enterprise network operators are interested in the work.
  • ISPs

References

[0] EGEA COCOM, available at http://circa.europa.eu/Public/irc/infso/egea/home
[1] EC Mandate 493, available at http://www.etsi.org/images/files/ECMandates/m493.pdf
[2] H. Tschofenig, et al, “Trustworthy Location”, available at http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location

I was invited to attend the 112 Rescue Forum in Žilina, Slovakia, which took place 10-12 October 2012. My presentation was about the EENA NG112 standard that has been published earlier this year.

Unfortunately, I was not able to attend the meeting in person and so I decided to create a screencast. This was my first attempt to create such a recording and I would like to share it with you as well. The presentation focuses on selected aspects of the NG112 specification. I extended my presentation a bit to currently ongoing work about location accuracy (where there will be a meeting with the European Commission early November 2012), and about the ongoing standardization work in the ETSI M493 group.

Here are the slides of my talk for download.