Highlights from IETF 103

We kicked off the meeting with our usual weekend events, the Code Sprint and IETF Hackathon. Each hackathon continues to draw more participants than the last, with 250 on-site and 32 remote participants collaborating on 28 different projects this time. 

Notable new projects included two that leveraged or integrated with Linux Foundation open source networking projects: one focused on implementing the latest version of the IPPM working group’s in-situ OAM in Vector Packet Processing (VPP), and one focused on SD-WAN service creation using the Open Network Automation Platform (ONAP) orchestration framework. We closed out the weekend with a packed HotRFC session with lightning talks about new drafts, new software, new research ideas, and new problem spaces.

The Security Area saw some of the more intense debates of the week. Discussions during the RATS BoF revealed that participants are considering a diverse set of use cases and architectural assumptions, with disagreement about how broadly to scope potential IETF work and what actors needed to be considered in the design. There was considerable agreement that, at a minimum, standardizing an attestation token format may provide value, so charter discussions may lead in that direction. 

In the TLS working group there has been a long-running debate about the susceptibility of the mechanism described in draft-ietf-tls-dnssec-chain-extension to attack. The mechanism is aimed at making it easier for TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. The working group declined to continue progressing the work given that TLS extensions can be specified and granted IANA code points without the need to publish a standards-track RFC, and the difficulty of constructing a robust solution that addresses all use cases.

In the Routing Area as well as the Applications and Real-Time Area, discussions at IETF 103 will be leading to proposals for new working groups or existing working group re-charters. The TEAS working group will be re-chartering to focus on API work. Participants in the Routing Area Working Group (RTGWG) held discussions about chartering a new focused working group to look at control plane and user plane separation. The HTTPBIS working group will be re-chartering and adding the next version of the HTTP protocol–now to be officially known as “HTTP/3”–to its charter. The DNS-over-HTTPS (DOH) working group  did not meet in Bangkok, but given the interest in DoH, the group will be staying open until IETF 104 to see if new work items come in over the coming months. At that point participants will decide whether to re-charter or close the group and propose a new group with a different DNS/web focus.

In the Transport Area, the QUIC working group closed in on a key decision concerning the “spin” bit, which is a single bit in the QUIC protocol header to facilitate passive measurement of round-trip time for QUIC flows. After more than a year of debate about the efficacy of using the spin bit for measurement and the risks of its presence revealing endpoint location information, the rough consensus in the room was to include the spin bit in the QUIC packet format, but not require its use, and to require implementations not to use it for at least a certain fraction of their traffic. Meanwhile, the Transport Area Working Group (TSVWG) had a fruitful discussion about the future of network management in light of broader deployment of encrypted transports like QUIC.

In the Operations and Management Area there were a couple of lengthy discussions that are likely to be continued at interim meetings in the coming months. The ANIMA working group spent significant time discussing a draft that describes processes for enrolling devices in an “autonomic” network, with the assistance of a voucher service provided by the device manufacturer. The core of the debate concerns how much control the manufacturer should be able to have over devices once they are in the field or resold, compared to the device owner. The NETMOD working group considered five different options for versioning schemes for YANG models, as the current versioning scheme documented in RFC 7950 has proved brittle as bugs in published models have been discovered. Look out for substantial further discussion in both areas before IETF 104.

Several long-standing network-layer engineering problems were the subject of extensive discussions in the Internet Area. The 6MAN working group is tackling the decades-old problem of how to efficiently and reliably discover the maximum transmission unit (MTU) size along a path. That discussion is benefitting from close collaboration with transport experts. The DNSSD working group made substantial headway in reconciling two different approaches for doing DNS-based service discovery without leaking personal information or information about offered or requested services.

IETF 103 also involved several important discussions about how we get our work done in the IETF. The GROW working group is considering experimenting with publishing “living documents” that can be updated more frequently and more easily than RFCs. That proposal will be fleshed out more thoroughly in the coming weeks. Participants in the WUGH BOF seemed to be coalescing around a basic set of conventions and tools to establish a uniform way for working groups to use GitHub for IETF work if they so chose. Charter text for a small, focused working group in that area will be forthcoming. And during the plenary open microphone session with the IESG, we heard from several participants about conduct in IETF working groups and openness to newcomers. The IESG is continuing to digest that feedback and brainstorm about how to make improvements.  

Taking advantage of being co-located with IEEE802 and back-to-back meeting weeks, two joint sessions were held over the weekend. One session was a Data Center Workshop and the other session was a joint meeting of IETF’s DETNET working group and IEEE 802’s TSN group.

Finally, this was the first IETF meeting where the NOC configured the IETF network to perform RPKI ROA validation and drop routes with “invalid” origins, resulting in approximately 6100 discarded routes. Huge thanks to them for helping to improve our routing security, and for everything else they do to help us have successful meetings.

We’ll gather again as a community at IETF 104 in Prague, March 23-29. Until then, see you on the mailing lists!