Hannes Tschofenig

Personal blog about various IETF and Internet related activities

 
 
Mar 14
31
2014

The privacy program of the Internet Architecture Board (IAB) has been working on a privacy tutorial for some time already and at the last IETF meeting in London I had the honor to present the work to the wider IETF community. The tutorial provided a sneak preview to a document we published last year, namely RFC 6973.

Privacy, as with security, has received increasing attention over the last few years as the number of security incidents and privacy violations increased. While security guidance has been offered in RFC 3552 and has been part of the IETF education tutorial for many years privacy related guidance has only been available recently with the publication of RFC 6973. This tutorial aims to provide the audience a brief overview of the privacy threats that engineers may encounter during their protocol work.

A core part of RFC 6973 is on offering guidance, i.e., a set of questions an engineer should ask himself or herself when designing new protocols or protocol extensions to take common privacy concerns into account.

The slides (PDF and PPT) are available. We also produced an audio recording of the session but unfortunately the audio quality is quite bad. I might just add audio to the slide deck myself and share it with the community.

Let me (us) know whether you find our approach useful. It is certainly not an easy checklist and requires a lot of thinking by the engineering designing the system but we couldn’t come up with another approach that covers the wide range of standardization activities the IETF is undertaking.

 

Mar 14
31
2014

At the last IETF meeting early March in London I had the pleasure to co-chair the Authentication and Authorization for Constrained Environments (ace) BOF with Kepeng.
The picture of the flyer we distributed during the meeting should give you a rough idea what the topic is about.

ace-BOF

(We are also working on the charter text that provides more details. The latest version can be found here and it is discussed on this mailing list.)

Here is my high-level summary of the BOF, which went pretty well (IMHO).

In a nutshell, we are trying to standardize an authentication and authorization protocol for use with constraint devices that makes use of a trusted third party.

In preparation for the BOF we scheduled a few tutorials about relevant technologies. Slides and recordings of the presentations are available.

  1. Kerberos (by Thomas Hardjono): Slides and Recording
  2. OAuth (by Justin Richer): Slides  and Recording
  3. “PKI/Certificate Model” (by Sean Turner): Slides and Recording
  4. AAA (by Lionel Morand during the IETF EDU session): Slides

Note: .arf files are Webex recordings. You might need to use a Webex player. See http://www.webex.com/play-webex-recording.html

We are planning to schedule one additional tutorial about ABFAB.

Sep 13
9
2013

Many have been wondering about government spying activities on Internet communication and of course everyone is puzzled what to do about it. More specifically, who should do what for certain applications (since the application behavior is quite different).

I wrote down my thoughts in a presentation given to data protection authorities and I wanted to provide a bit more context to understand the slide deck. It also want to illustrate that there are various challenges (even when thinking about a single application, namely VoIP communication).

The Background

The International Working Group on Data Protection in Telecommunications (IWGDPT), which consists of mostly data protection authorities (DPAs) and similar organizations (e.g., the FTC) from all over the world, has published a Working Paper on Privacy and Security in Internet Telephony already in September 2006 to reach a common understanding of challenges that will arise with the introduction of VoIP technology from a data protection point of view. DPAs enforce privacy laws but they are not the only agencies able to do that. The recommendations are largely addressed to VoIP service providers and also to manufacturers of software and hardware. The recommendations are sound but were written at a time when most of the VoIP deployment was still at an early stage.

In the meanwhile VoIP deployment has increased substantially and even to an extend that some predict the end of the Plain Old Telephony System (POTS) in various regions, as discussed at the technical plenary of the Internet Architecture Board in March 2013. The plenary material can be found here. In practice it turns out that many over-the-top VoIP providers (and providers that provide real-time communication services like instant messaging, real-time text, and video) fall under a different regulatory regime than classical telecommunication companies (such as AT&T, Verizon, BT, Vodaphone). Consequently, they operate under different rules than the classical telcos with respect to telecommunication secrecy, emergency services, accessibility requirements, etc. Many over-the-top VoIP providers, such as Skype, don’t want to become electronic communications operator. Of course, just changing laws to apply the telecommunication laws also to over-the-top provider does not work since the environment is very different.

A few years have passed since the IWGDPT published their recommendations and a few things have changed in the Internet ecosystem. The community certainly has a better understanding of the degree of government surveillance. Also, the underlying technology has evolved.

To advance the understanding of what could be done to improve VoIP security and privacy I compiled a slide deck to start the discussion about how the existing working paper could be updated, i.e., what recommendations data protection enforcement agencies could provide primarily to VoIP service providers, and equipment manufacturers.

The slide deck is a first draft and I hope to receive some feedback from the Internet community as well as from data protection authorities.

Here is a summary of the story (since the slides might not be self-explanatory).

Problem Description

First, there are problems beside government surveillance but those are currently forgotten in light of all the NSA discussions. Here are a few examples:

  1. Earlier this year security researchers have found out that links exchanged via programs like Skype had been retrieved from by Microsoft, as explained in this press article. While one can easily argue that this serves a security purpose the problem here in fact was with transparency. Most users were kept under the impression that Skype is a peer-to-peer system and uses end-to-end security so that no other party than the two end points is able to read the traffic. Obviously, that does not seem to be true and the proprietary nature of Skype makes is very difficult to find out what is happening.
  2. It is quite common to re-invent the wheel when it comes to Internet services. Of course the existing standards (like SIP, XMPP, and WebRTC) look very complicated for a newbie. So, why not develop something much simpler and better? The guys behind WhatsApp and also Cryptocat thought that this is the way to go. Well. Of course designing security into a system requires a lot of expertise and you can get it wrong very easily. Here are some blog posts that report problems with WhatsApp and Cryptocat.
  3. Of course you may also have VoIP providers who have rather relaxed security practices in general or may operate with a business model that does not provide a lot of incentives for privacy protection in general.

Note that I mix providers offering voice services with those offering other real-time communication services. I do this since there is often very little difference in terms of the actually involved protocols (although deployment-wise they may differ).

 

Today’s VoIP Landscape

Once the problems are understood there is the question about how various VoIP services today look like and there have been changes as well.

First, more and more application providers on the Internet establish silos in their communication architecture. The problem is that you cannot take random client software (like you can do today with an email client) and get it to work with a random VoIP provider. The RTCWeb model is a classical example but even smart phone applications follow a similar scheme. In the RTCWeb example the server provides the code (in form of JavaScript) for the browser to execute. Of course, from an innovation point of view this gives service providers much better possibilities to adapt the software to new needs. The IAB covered this trend at one technical plenary under the title “Post Standardization” (see plenary content here and an accompanying document here).

From a security and privacy point of view the challenge, however, is that a user never knows what software it is actually running. Everything may change at any time. Unless there is a lot of trust from the user in the service provider everything is lost.

A secondary effect is that many of the previously standardized protocols are not necessarily used in the way expected and hence custom designs dominate but security features are hard to get correct, as the last 20 years clearly demonstrate. For privacy protection the situation is even worse since many companies have incentives that are in conflict to users since the entire industry is looking for cloud computing, and big data analytics to discover “something new”. These industry trends do not line up nicely with basic privacy principles like data minimization and purpose limitation.

Data Routing and Interconnection

Two other aspects need to be considered, namely

  1. The involvement of interconnection providers, and
  2. The route VoIP data takes

In the early days of VoIP standardization in the IETF the idea was that interconnection would work similar to email (which lets one email provider talk directly to another email provider without any other entities in the middle). That was a good idea but the business models of operators were different. Consequently, intermediaries were introduced and, for end users, these intermediaries are invisible to a large extend. Another way to understand the role of these intermediaries is to glance at the credit card industry: Credit card companies use, in certain circumstances, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) to process financial transactions. End users have not been aware of the presence of SWIFT in the transactions and even less aware of the fact that SWIFT make personal data accessible to US authorities, as this write-up of the Article 29 working party describes.

Is it too farfetched to wonder whether governments work together with interconnection providers to obtain transaction data of VoIP calls or, worse, the actual content of the communication?

It has to be pointed out that XMPP today is deployed without intermediaries, very much in the same way as email systems are deployed. It also provides a standardized way to build federated communication systems. XMPP is, however, mostly used for instant messaging and Google, who is using XMPP for Google Hangout, dropped support for server-to-server federation in May 2013 turning their services into a silo similar to the Facebook silo (who are also using XMPP). Consequently, a user who is on Facebook using XMPP cannot communicate with a user who uses Google’s XMPP services.

The route the data takes may, of course, be different than the route the signaling messages take when communication between two or more endpoints. There is even a standardized protocol to allow the best possible route to be determined, namely the Interactive Connectivity Establishment (ICE). One could also provide VPN tunnels, independent TURN servers, or even Tor as input to ICE so that the routing of the VoIP data packets remains separate.

However, in most cases the service provider has ultimately the full control of the routing of the packets and will therefore be able to see the content. As such, playing with the packet routing to obtain some level of security by itself is insufficient. Only cryptographic security mechanisms can help.

Securing Communication

There are at least two important areas in securing real-time communication protocols, namely

  1. Securing the signaling messages, and
  2. Securing the actual communication payload (voice packets, for example)

The security mechanisms look somewhat differently and a discussion about the design decisions with impact to privacy in case of SIP-based presence services can be found in RFC 6973.

For signaling traffic it is not possible to protect the entire communication end-to-end since various parts of the messages need to be understood by the different servers to ensure routing of the messages. Typically, one differentiates between client-to-server and server-to-server communication. For server-to-server communication it is assumed (on paper) that those exchanges are protected using TLS (or IPsec) but of course many deployments rather fall back to an illusion of physical security. For the client-to-server communication the story is more complicated. TLS with server-side authentication is assumed (although often not provided) but the client/user authentication typically happens via username & password layered on top of TLS.

If this type of security is indeed provided then it provides protection against eavesdroppers, who are not part of the legitimate protocol exchange. The protection is of course not provided against collecting information about the user’s communication behavior by VoIP providers and intermediaries (or even by the VoIP client software running on the end device).

An important task in end-to-end communication is to either present the calling party identity to the callee or to hide it. In the context of VoIP this identity information typically comes in form of the calling party identifier (phone number or URI) + contact information. On one hand conveying these identifiers is a privacy violation but on the other hand it provides privacy protection for the callee since he can decide based on the calling party whether he wants to get interrupted or not. Typically, many systems today use some form of whitelist (in the form of a buddy list) to filter incoming communication attempts. New users have to go through an “introduction” phase first.

Two types of approaches have been developed to communicate identity information within the signaling messages, namely:

  1. A chain of trust/non-cryptographic approach (for example, P-Asserted-Identity)
  2. A cryptographic approach (for example, SIP Identity)

Various problems surfaced with the chain of trust approach (which is also used in today’s telephone system) with caller-id spoofing and telephony denial of service attacks. The cryptographic approach is, however, also not without problems from a deployment point of view due to the nature of the intermediaries, who invalidate the cryptographic protection.

A more detailed discussion of the topic can be found here and with IETF#87 a new working group, called “Secure Telephone Identity Revised” (STIR), has been started to tackle some of the problems.

To protect the content of the communication is story is even more complicated since the goal is to securely authenticate the parties on both ends of the communication. It turns out that the solutions very much depend on who to trust and what the anticipated capabilities of the adversary are. On top of it, there are also challenges in the interworking with existing technologies (e.g., PSTN interworking).

As an example of what is meant by the assumptions consider ZRTP and DTLS-SRTP:

  • ZRTP assumes that callee/caller recognize each other’s voice (due to the voice fingerprint authentication procedure). Of course, without voice there is no voice fingerprint and there are also communication interactions where the voice of the other communication partner is not known.
  • DTLS-SRTP on the other hand assumes that SIP identity protects the fingerprints of public keys exchanged between the two parties. While SIP identity can be added by the endpoints themselves it is more realistic that they are added by the voice service provider. Consequently, the user has to select voice server provide they trust.

Of course, this is not a new area of work and a document with requirements and use cases can be found in RFC 5479.

My Recommendations

After all this background, what are the possible recommendations that can be given to VoIP providers and their equipment manufacturers.

  1. Requirement for Transparency
    1. In particular, it is important to know what information is collected by whom and for what purpose? What is the retention period?
    2. What security technology is available? How is information protected?
  2. User Participation
    1. What are the controls for users to control sharing with other users and with intermediaries? e.g., identity information
    2. Are whitelists (buddylists) available? How can the delivery of identity information to the callee be suppressed?
    3. In the Web context with many possible communication partners Is there an ability to view granted permissions and to revoke them (e.g., access to camera, microphone).
  3. Security
    1. Mandatory security for signaling traffic (client-to-server & server-to-server)
    2. Mandatory E2E security for data traffic: is it possible to mandate SRTP for all voice communication? Can something be recommended about the actual key management technique, particularly since there are various techniques available and some of them with questionable security benefits (like SDES). There will obviously be an inherit conflict between lawful intercept and the desire of end users to keep the communication content confidential.
    3. For the case where the exchanged data is not voice but rather instant messaging, or pure data the security solutions are obviously very different. What can be recommended in that case? For XMPP the e2e security mechanism (using the IETF JOSE work) is still work in progress and the S/MIME-based solution in SIP might not be deployable unless it is paired with another technology, such as SIP Cert, which provides a way to distribute the certificates. RFC 3923 provides the e2e security version using S/MIME for XMPP, which of course suffers from the same limitations as the SIP-based counterpart.
    4. Allow key exchange mechanisms to be replaced by third parties (pluggable models). This is a common concept used in other authentication protocols, like EAP, SASL or the GSS-API. It gives the communications partners the ability to adjust their capabilities to their needs.
    5. Should perfect forward secrecy be mandated to avoid future compromise of the communication content?
    6. Protection against unauthorized access of stored data.
    7. Software has to come with an update mechanism to react quickly to discovered vulnerabilities.
  4. Privacy-friendly defaults
  5. Re-use open standards that have enjoyed wide community review to ensure the quality of the used technology. (-> to increase transparency)
  6. Use open source code. This should also increase the quality and transparency.
  7. Allow users to choose their identity provider (-> to increase competition and choice)
  8. Offer federated use (-> to increase competition and choice)
  9. Enable data portability to make it easier for users to switch their provider (for example by extracting the buddy list) (-> to increase competition and choice)
  10. Preference for cryptographic identity conveyance (-> to lower misattribution & intrusion)
  11. Offer capabilities for direct exchange of data (-> to provide data minimization)

For users there is only one recommendation, namely to select the application providers operating in jurisdictions they feel comfortable with. This selection will also impact the applicable data protection laws.

Final remarks

To solicit feedback I am curious whether these recommendations are detailed enough? What else could be recommended?  What can be said about the real-time web case where the security and privacy challenges are even bigger?

Please drop me a message to hannes.tschofenig AT gmx.net, respond on this mailing list, or comment on the blog post.

Sep 13
2
2013

HTTP 2.0

The IETF is working on a new version of HTTP, called HTTP 2.0, in the HTTPbis working group already for some time. The Wiki page provides a bit of additional data about the goals. The working draft of HTTP 2.0 introduces some major changes to HTTP 1.1 and the possibility to mandate the use of TLS (as the only option) was discussed some time ago but the group decided against it.

However, with the recent debate about PRISM the group has at the last meeting decided to revisit this decision. A presentation from the working group chair from the last IETF meeting in Berlin can be found here. The media has picked this item up, see for example FT article “Internet launches fightback against state snoopers“.  The decision at the meeting got a bit misinterpreted since the author of the article already anticipates the outcome of the discussion.

 

RTCWeb and E2E Security

The IETF has a long history in developing real-time communication protocols, such as the Session Initiation Protocol (SIP, which is also used by the 3GPP IMS), the Extensible Messaging and Presence Protocol (XMPP), and most recently the RTCWeb protocol, which builds on the Web infrastructure and JavaScript.

The work around RTCWeb has an impact to various other IETF areas but the core specifications are developed in the IETF RTCWEB group and in the W3C.  In addition to various functional aspects the chairs put an important item on the agenda for the last meeting: the group had to decide about the automated key management protocol and two proposals were put forward, namely (a) SDES and (b) DTLS-SRTP.

SDES carries keying material for e2e media security along the signaling path so that signaling intermediaries are able to see the keying material. This approach is simple to implement and convenient for those who want to provide lawful intercept functionality (or other form of inspection) of the end-to-end voice communication.

The argument in favor of SDES has been presented during the meeting by Hadriel Kaplan (Oracle) and Martin Thomson (Skype). The arguments for DTLS-SRTP have been provided by Eric Rescorla. It is worthwhile to take a look at the slide decks to see how differently technical solutions can be presented. I sometimes have to think about the movie “Thank You for Smoking“.

At the end of the meeting the participants hummed in favor of DTLS-SRTP, as the meeting minutes capture. For many IETF meeting participants this was a very important decision and various security experts decided to attend the RTCWeb face-to-face meeting, particularly in light of the PRISM discussions, to influence the decision.

 

TLS 1.3: The Next Generation of Transport Layer Security

A side-effect of the design of HTTP 2.0, the work on RTCWeb, and the overall attempt to make the Web (particularly for the mobile environment) is the renewed interest in the IETF TLS working group. On one hand there is a desire for more security protection and on the other hand TLS needs to become faster. Cryptographic computations and the latency of the security handshake come at a cost and therefore major Web companies, most notable Google, have been looking at ways to reduce optimize TLS.

These new developments include application layer protocol negotiation to allow de-multiplexing of HTTP 1.1 and HTTP 2.0 payloads, OCSP stapling and multiple OCSP stapling to avoid separate protocol exchanges for checking the status of certificates,,TLS channel ids to develop a sort-of cryptographic cookie at the TLS layer, and mostly recently TLS 1.3. A presentation that outlines some of the design characteristics from the TLS co-chair and TLS author, Eric Rescorla, can be found here. While Eric describes the changes as minor they constitute a major improvement compared to earlier TLS versions, such as the addition of a Diffie-Hellman exchange to avoid passive eavesdropping on the TLS exchange (which is a privacy increasing functionality).

In general, privacy concerns had come up in the TLS working group in various discussions and it appears that there is a better understanding of the need for considering privacy in the design of various TLS protocol extensions.

 

IAB Privacy Considerations

The IAB privacy consideration document has now been published as RFC 6973. To better inform the IETF community about the guidelines found in that document the IAB privacy program has been working on a tutorial. The IETF #87 meeting was used for a trial run with selected persons (typically working group chairs) to solicit feedback on how to better approach the wider IETF community.

A recording of the presentation is available and the slides are available for download here. The trial run resulted in lots of feedback and adjustments to the tutorial will be made. A revised tutorial for a much larger audience is planned for the upcoming IETF meeting in Vancouver (Nov. 2013).

The IETF security area directors are planning to publish a document that requires IETF document authors to address privacy in the protocols since the IAB document is currently a guidance document but the Internet Engineering Group (IESG) is in a much better position to encourage document authors to consider privacy. This approach would be similar to what was done with security and BCP 107 and BCP 61.

 

Tor meets the IETF

Various members of the Tor project, including Jacob Appelbaum and Linus Nordberg, decided to attend the Berlin IETF meeting to discuss the news about PRISM, to share information about their work, and to determine how cooperation with the IETF community could look like.

In addition to side meetings, a presentation at the Security Area Advisory Group was given and a new mailing list, perpass@ietf.org, was created to continue the discussions.

The interaction with the Tor community will provide the IETF with additional insight on how to prevent fingerprinting and to learn about the state of middleboxes throughout networks (as part of the Tor project work on the Open Observatory of Network Interference). The Tor community on the other hand will benefit from additional reviews and involvement of the IETF community in the ongoing developments.

 

Security Incident Information Sharing

High-profile data breaches and security incidents on the Internet are gaining increasing attention from the Internet community, but also from the public and from governments. Various CyberSecurity activities have recently been launched, such as the EU CyberSecurity strategy, the EC created Network and Information Security Platform, and the NIST CyberSecurity framework. Sharing of security incident information is one of the items that is supposed to improve awareness and shall ensure a quicker response to security incidents.

Since the IETF has standardization efforts ongoing in the area of incident and abuse information sharing a workshop was held prior to the IETF #87 meeting. The workshop page also contains slides from the presenters, including presentations about privacy and legal aspects. The workshop report is still work in progress.

While there are many challenges it became clear that the privacy related aspects are not well understood. For example, what information about the communication interactions is allowed to be collected? What information can be shared with third parties and under what conditions? While various techniques have been deployed for a long time already (such as in the case of spam filtering) it is was not obvious from the discussions at the workshop how well they have been analyzed against the data protection frameworks. Further discussions will be certainly needed and recommendations will have to be developed as more sharing is expected in the near future, also due to recently created work in the IETF such as Security Automation and Continuous Monitoring (SACM).

 

Improving the Web Public Key Infrastructure (WebPKI)

The problems with the WebPKI have received the attention by the Internet security community when DigiNotar, a Dutch certificate authority, had a security breach and in the same year a Comodo affiliate was compromised. Both cases lead to fraudulent issue of certificates and raise questions regarding the strength of the PKI used by many applications today.

A compromise of the PKI obviously leads to privacy violations since it allows an attacker to intercept encrypted communication.

Almost two years have passed since these incidents happened. Although new technical mechanisms have been developed within the IETF, such as DANEkey pinning, and certificate transparency, very little has happened in terms of actual deployment. Consequently, the attacks that have happened two years ago may happen any time again.

With the NIST workshop on “Improving Trust in the Online Marketspace” various stakeholders were invited to discuss the technical options for improving the state-of-the-art. It became clear that there are very few organizations who have the desired properties, such as technical expertise, appropriate membership model, and independence, to lead the follow-up discussions.

As a follow-up activity the Internet Architecture Board will work together with the Internet Society to initiate work on a roadmap and shared vision on how to proceed on this topic. A meeting is planned at the upcoming IETF meeting and a workshop will be organized early next year.

May 13
31
2013

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”.

May 13
8
2013

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.

Apr 13
24
2013

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:

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

Chat with Mark Fletcher




Forgot?

Categories

Tags

Hannes Tschofenig's Recent Tweets