Building Trust Identity IETF Open Internet Standards Privacy Technology

Rough Guide to IETF 92: Trust, Identity, and Privacy

Wrapping up the series of Rough Guide to IETF 92 posts is our focus on Trust, Identity, and Privacy. ISOC has been working over the past five years in these areas, and each subsequent IETF has seen advancing work and progress being made on multiple fronts. IETF 92 in Dallas this week is no exception.

First, while there won’t be a meeting on it this time, I’d like to remind folks of the mailing list created last fall to discuss vectors of trust at The impetus for this mailing list came out of an ISOC-sponsored workshop this past September. It is hoped that these discussions will lead to further consensus on concepts around trust and levels of assurance. There are rumors of an informal bar BoF to further discussions on this topic. Monitor the mailing list for details. This is a great opportunity to get involved in a potential IETF activity at a very early stage.

The W3C Privacy Interest Group (PING) will again meet face-to-face alongside IETF on Thursday, 26 March. Topics for the meeting include: the WiFi Privacy Experiment at IETF; W3C Technical Advisory Group (TAG) finding “Securing the Web” through the use of cryptography; Proposed Edited Recommendation Geolocation API; as well as PING’s ongoing work on privacy reviews and guidance for Web specification authors. Please join the meeting if you have an interest in privacy on the Web and would like to help develop better privacy features in Web standards. Meeting details are provided here:

And since I mentioned it above, I’d also like to highlight an experiment that will be hosted on the IETF network. As stated at the link below, the IEEE 802 EC Privacy Recommendation Study Group, in coordination with the IAB and IESG, are working on privacy enhancements for link layer technologies. As part of this effort, they are carrying out a WiFi MAC randomization trial/experiment at IETF 92. The experiment is similar to the one carried out at IETF 91, but this time it’s been upgraded with more support for operating systems (including mobile) and it will run integrated into the main IETF 92 WiFi network. If you are attending in person, you can participate in this experiment. Details on participation can be found on the IETF Meeting Wiki; there is also an article about the privacy trials in the latest issue of the IETF Journal.

As for the IETF working groups, there are several ongoing working groups addressing topics in this space.

The jose (Javascript Object Signing and Encryption) working group will have a short meeting on Tuesday evening to discuss new proposals to develop a Concise Binary Object Representation (CBOR) encoded message syntax for signatures, message authentication codes, and encryption similar to those developed for JSON. The four core jose specifications and the cookbook have both progressed to the RFC Editor and should be coming out sometime soon.

The oauth (Web Authorization Protocol) working group has a full agenda for its Monday afternoon meeting based around its continuing work on proof-of-possession security assertions, token introspection, and token exchange among others. There are several oauth documents that are currently in IESG processing or the RFC Editor queue.

The ace (Authentication and Authorization in Constrained Environments) working group is continuing to develop documents on use cases, actors, architecture comparison, and object security. There is also a side meeting organized on Monday evening to help accelerate consensus on architecture, terminology, and scope. The plan is to meet from 19:10 to 20:40 after the plenary (look to the mailing list for details). Additionally, the technical plenary on Monday evening is on Smart Object Architecture and is highly relevant to this area of work.

The scim (System for Cross-domain Identity Management) working group has successfully sent their core document to the IESG for processing. This includes use cases, an api, and core schema. The meeting this week will discuss new drafts on soft deletes and event notification.

The relatively new stir (Secure Telephone Identities Revisited) working group is looking to develop mechanisms to correctly identify where SIP requests are being originated. In a nutshell, how do you prove ownership of a telephone number on the Internet? The problem statement (RFC 7340) and threats (RFC 7375) documents were published earlier this year, and the “Authenticated Identity Management in the Session Initiation Protocol” and “Secure Telephone Identity Credentials: Certificates” documents are again on the agenda for this meeting.

The web PKI certificate infrastructure continues to be a source of trust related operational issues in the Internet. The primary effort of the trans (Public Notary Transparency) working group is the generation of a standards track version of the experimental RFC 6962 on Certificate Transparency. The primary focus of this week’s discussion will be resolution of issues on the update to RFC 6962. Additional topics for this week’s agenda include a threat analysis, client behavior, and the gossip protocol.

The httpauth (Hypertext Transfer Protocol Authentication) working group’s document for a basic http authentication scheme is in the RFC Editor queue, and the HTTP Digest Access Authentication document is with the IESG. This meeting will focus on mutual authentication, algorithms for mutual authentication, and extensions for interactive clients.

Finally, the dprive (DNS PRIVate Exchange) working group is a relatively new working group chartered to develop “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.” They are working on a problem statement and some initial proposals. And, the kitten (Common Authentication Technology Next Generation) working group is addressing a long list of documents related to authentication.

As you can see, the IETF is devoting a significant amount of time and energy on efforts related to trust, identity, and privacy. There is plenty to follow and contribute to in this space.

Related Meetings, Working Groups, and BoFs at IETF 92:

Follow Us

There’s a lot going on in Dallas, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Open Internet Standards Technology

Rough Guide to IETF 92: Internet Scalability & Performance

In this post I’ll shine a light on some of the Internet Engineering Task Force (IETF) and Internet Research Task Force (IRTF) efforts underway to explore and address more sophisticated ways to use available bandwidth, improve Internet performance, and otherwise efficiently get content to where it needs to be. These groups will all be meeting as part of the IETF 92 meeting in Dallas next week.

Following on from the recent IAB workshop on Stack Evolution in a Middlebox Internet (SEMI) that discussed the ossification of the transport layer and how to fix it for emerging applications, the Substrate Protocol for User Datagrams (spud) BoF will discuss requirements and strawman proposals for a protocol to expose selective and minimal metadata to the path. The intent is to restore control to the endpoint with regard to what data is exposed to the path so that middlebox functionality deemed useful can still be supported in the presence of encryption that otherwise renders such functionality impotent. The technical plenary meeting on Monday evening will include a brief readout from the SEMI workshop, and the Transport Area Open Meeting will include a longer presentation of the workshop discussion and outcomes.

Another outcome of the SEMI workshop will take place on Sunday evening in the form of an informal Bar BoF meeting to discuss measurement techniques and data sources that could help make better engineering decisions to work around some of the ossification in the protocol stack. The hope is that techniques similar to ‘happy eyeballs’ for IPv6 can be used to support deployment of new transport features and protocols.

Internet performance is to a large extent governed by the way transport protocols operate, and the tcpm WG will be meeting to discuss proposed new functionality to improve and enhance the working of TCP, the main transport protocol used on the Internet today.

Packet networks give rise to transient congestion by design and several groups are meeting to discuss different aspects of congestion control and avoidance (aqm, iccrg and rmcat). For regulators, being able to monitor the performance of networks, and the extent to which congestion or other factors are impacting consumers’ experience of the network is very important. The lmap working group is meeting in Dallas to advance their important work on standardizing a large-scale broadband performance measurement infrastructure.

Related Working Groups and BoFs at IETF 92

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blogTwitterFacebookGoogle+, via RSS, or see

IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 92: Routing Resilience and Security

There is considerable work underway across a number of IETF working groups to ensure the Internet’s routing infrastructure is more secure and resilient in both the short and long runs. Many of those working groups will be meeting in Dallas, TX, next week at IETF 92.

Let me begin, as always, with listing the WGs where security and resilience issues of the global routing system are discussed and solutions are developed. The groups meeting at IETF 92 are:

The SIDR WG is focusing on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the routing infrastructure.

A lot of work has been done, and there are quite a few operational deployments. This results in refinements to the protocols and fixing some issues. This is a normal cycle of protocol maturity, when operational experience is fed back into the protocol development, leading to improvements.

One such refinement is an RPKI Repository Delta Protocol (, which provides relying parties with a mechanism to query a repository for changes, improving the overall scalability and performance of the system compared to the currently used rsync protocol.

Another draft is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries. The draft, “RPKI Validation Reconsidered” (, has its next revision, but not much discussion happening despite some disagreements over the proposal within the Working Group.

There are some movements in the BGPSEC area, too. The BGPSEC protocol specification is in the WGLC (draft-ietf-sidr-bgpsec-protocol-11). People found a few omissions that are easy to fix, like unsecure AFI allowing the attacker to confuse IPv4 and IPv6 prefixes that look the same on the wire.

Extra care needs to be taken when making significant reconfiguration, like AS migration when networks are merged, for example. A draft “BGPSec Considerations for AS Migration” ( discusses this for a common method for AS migration within the BGPSEC protocol.

As a matter of fact such a common method is not trivial and requires some BGP features that are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. Absent these features, it would have required an ISP to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch, the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change.

This is addressed in the draft “Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute” ( This draft is being discussed in the IDR WG and is largely parallel to one of the SIDR WG I just mentioned, although addressing different aspects.

Speaking of network reconfigurations and maintenance, one very important requirement is operational continuity, which is also applicable to the two drafts I just mentioned. Even if an ISP has redundant connections, simply taking down or bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications, like Voice Over IP (VoIP), online gaming, or VPN. Therefore, a solution is needed for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. Such a solution is described in a draft “Graceful BGP session shutdown” (draft-ietf-grow-bgp-gshut, now expired because of dependencies on other drafts, not because of the loss of interest), that is being discussed in the GROW WG.

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see

This time there is not much work related to routing happening in the OPSEC working group. But late last year the IESG approved draft “BGP operations and security” ( as a Best Current Practice (BCP194, RFC7454). This is a very useful document that brings major operational issues and best current practices with regard to routing security. It has gone through a second Working Group Last Call and hopefully is close to be published as a BCP RFC.

Related Working Groups at IETF 92

Follow Us

There’s a lot going on in Dallas, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Open Internet Standards

Rough Guide to IETF 92: Welcome to Texas, Y’all!

Starting on Sunday, 22 March, the Internet Engineering Task Force returns to Dallas, Texas, USA, for IETF 92, where more than 1000 engineers will spend a week discussing the latest issues in open standards and protocols. As usual, the Internet Society is providing a ‘rough guide’ to the IETF via a series of blog posts on topics of mutual interest:

All these posts can be found, and will be archived, through our Rough Guide to IETF 92 overview page at

First I’ll start with an overview of some of the activities that the Internet Society is involved in and some of my personal highlights.

IETF Journal

Before we get to IETF 92, catch up on some of the highlights from IETF 91 in Honolulu by reading Volume 10, Issue 3 of the IETF Journal. You can read all the articles online at, or pick up a hard copy in Dallas. The cover article, “Open Standards, Open Source, Open Loop,” discusses the challenges for standards organizations like the IETF in the face of agile software development paradigms. We also have articles about the upcoming IETF website revamp, a new initiative on human rights and Internet protocols, a report on the WiFi privacy trial that ran in Hawaii and will run in Dallas, and reports on the most recent winners of the Applied Networking Research Prize, and the Internet Society panel that explored the question, Is Identity an Internet Building Block? Finally, the issue debuts a new look, part of a year-long celebration of the publication’s 10-year anniversary.

Speaking of the IETF Journal, did you know it is now being translated into Russian? The last issue of the Журнал IETF (Инженерного совета Интернета) is available through our site and the Russian ISOC Chapter. This issue will be translated in a few weeks and linked from the main IETF Journal page.


Through the Applied Networking Research Prize (ANRP, supported by ISOC) the Internet Research Task Force (IRTF) recognizes the best new ideas in networking, and brings them to the IETF, especially in cases where the ideas are relevant for transitioning into shipping Internet products and related standardization efforts. In Dallas, one talented researcher will present during the IRTF Open Meeting on Tuesday, 24 March:


One of the week’s highlights is the technical plenary on Monday, 23 March, during which Dave Thaler and Hannes Tschofenig will lead a discussion on “Smart Object Architecture.”

On Saturday and Sunday, the IETF is holding a Hackathon “to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards.”

Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. There are seven BoFs happening in Dallas:

Follow Us

There’s a lot going on in Dallas, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see