IETF 101 Highlights

For anyone who has been questioning the value of the IETF continuing to meet face-to-face multiple times per year, IETF 101 provided a resounding example of just how much progress can be made in one week's time and how critical in-person dialogue is to finding consensus. The community realized these benefits across all of the IETF's technical areas last week. This post focuses on selected highlights; as always, the proceedings (to be posted soon) will tell the full story.

Routing (RTG)

As our collective understanding of Internet security threats has evolved in recent years, questions are increasingly arising about the security properties of many long-standing IETF routing protocols and implementations. At IETF 101 the routing area directors initiated the creation of a routing-area-wide design team to review and propose enhancements for the IETF's routing protocols. These proposals will target current deployments and corresponding threat models as well as new use cases (e.g. data centers, service function chaining). The team will have support from the Operations and Management (OPS) area and the Security area (SEC).

While in London work also started in two new working groups focused on data center routing.  Participation was encouraging at the initial meetings for Link State Vector Routing (LSVR) and Routing In Fat Trees (RIFT) — each working group (WG) is working to develop new hybrid approaches to routing data center topologies.

Transport (TSV)

The QUIC working group used one of its two working group sessions to find a way forward on the "spin bit" proposal, where the goal is to use one or a small number of bits in the QUIC header to provide an indication of round-trip time to passive observers on the network. The working group has been discussing the spin bit since last year. The outcome of the session, which included some of the longest mic lines I've ever seen at an IETF meeting, was to ensure that the current draft specification of QUICv1 can accommodate experimentation with the spin bit over the coming months, but to reserve judgment about whether to incorporate a specific instantiation of the spin bit into the final spec for QUICv1. This outcome reflects clear interest in the room in the possibility of having a way to measure RTT, but also reservations about the quality of the signal it would provide, how to best incorporate it into the packet format, and whether exposure of the signal is justified.

There was also fruitful discussion in the Transport Area working group about TCP encapsulation that looked at empirical evidence from performance tests with TCP encapsulation for IKEv2. Participants in other areas should expect to see a forthcoming document providing guidance about usage of TCP encapsulation.

Security (SEC)

The security area hosted a successful Birds of a Feather (BoF) session: Message Layer Security (MLS). The goal of MLS is to standardize protocols for key management and message protection for group messaging. Providers of numerous widely used messaging applications were in attendance and indicated their interest in contributing to and using this work.

Having had the Transport Layer Security (TLS) 1.3 specification approved for publication just prior to IETF 101, the TLS working group continued to charge full speed ahead on a variety of WG and non-WG items. Perhaps the most highly anticipated was the "TLS visibility" discussion based off of a proposed TLS extension to create an opt-in mechanism for a TLS client and server to grant access to TLS session plaintext. Keying off of extensive prior discussion on the mailing list, participants spoke for and against the proposal on a variety of grounds, ranging from the operational security impact of not having "visibility" to the practical ability (or lack thereof) of restricting the use of the extension to certain networks and use cases to questions and concerns about the breadth of the keying material proposed to be made available. Ultimately there was no consensus in the WG to move forward with the proposal.

Applications and Real-Time (ART)

The ART area saw a combination of work being driven to completion, progress being made on hot button issues, and the introduction of new ideas and possibilities for collaboration. The JSON Mail Access Protocol (JMAP) specifications describing a JSON interface between email clients and mail stores are nearing finalization, as is the Authentication Receive Chain (ARC) work to resolve issues identified related to Domain-based Message Authentication, Reporting & Conformance (DMARC) and mailing lists. The area-wide DISPATCH working group saw discussion of changing the registry policy for well-known URIs  and concluded that the policy should be far more permissive; this change will likely be welcome for individuals and WGs across many of the IETF's areas.

In the realm of new ideas and collaborations, ART area participants took advantage of attendance from a couple of members of the WHATWG to discuss interactions between specific WHATWG documents and IETF protocols as well as more general thoughts about how to interface between the two organizations. The ART area also saw lively discussions about new proposals related to web packaging, replacing the real-time media stack, and ideas about pre-fetching DNS records on the web as an outgrowth of DNS over HTTP (DOH).

Operations and Management (OPS)

The DNSOP working group hosted a talk about the "DNS Camel," to consider how many features and how much complexity can be added to the DNS before it breaks and what to do about it if so. As the presenter Bert Hubert noted, this conversation struck a nerve and reverberated in many corners of the IETF throughout the week. The implications from a DNS architectural, operational, and standardization perspective will continue to be discussed and may well yield lessons that extend to other long-standing and widely deployed protocols.

The OPS area also hosted the Common Operations and Management on Network Slices (COMS) BoF to look at an architecture and information model for networking slicing. As a non-working-group forming BoF it provided a good opportunity to explore the problem space and use cases, understand the existing related work in the IETF, and discuss the appropriate scope for potential new work. While some pieces of the proposed work are likely to fit into existing working group charters such as DETNET, there is more work to do on the architecture proposal to understand how it might fit into future IETF work.

Internet (INT)

The INT area hosted the Identifier Locator Addressing (ILA) non-working-group forming BoF focused on a proposed protocol to implement transparent network overlays without encapsulation. The proponents presented an overview the protocol's properties and benefits as well as a use case for ILA to support mobility in a 5G network. With the BoF slot limited to one hour it was a useful beginning of a discussion that will likely continue as the proponents provide further detail about the precise protocol mechanics, why ILA has advantages over many existing protocols with similar features, and Internet-wide deployment considerations. 

The Internet of Things (IoT) directorate also had a productive meeting focusing on coordination with other organizations working on IoT and how to better organize information about IoT-related work going on in the IETF.

General (GEN)

In the GEN area we had the IETF Administrative Support Activity (IASA) 2.0 BoF. This session followed up on similar sessions at the last several meetings. Participants considered a number of options for changing the legal structure that houses the administration of the IETF. The key outcome from the session was that we identified rough consensus in the room in favor of creating a limited liability corporation (LLC) that is treated as a division of ISOC for tax purposes to house the administration of the IETF (option 3 in thelegal memo linked above). 

This consensus is in the process of being confirmed on the iasa20@ietf.org list while participants also consider draft charter text to form a working group to effectuate the changes.

Other highlights

Aside from the WG and BoF sessions, we had: 

• Our largest IETF Hackathon ever, with about 220 on-site participants, 20 remote participants, and 35 projects,
•  A highly successful "HotRFC" lightning talk session at the beginning of the week allowing anyone looking to raise awareness or find collaborators around a new idea could give a pitch, and
• A technical plenary program that explored changes in access network technologies that inspired some thought-provoking discussion about the implications for protocol development and design.

What a week! See you in Montreal.