The 118th IETF meeting took place in Prague between 4 and 10 November 2023, with more than 176 sessions, a 2-day hackathon and various side events. Marco Davids from SIDN Labs attended the meeting and has written a summary of the main points of relevance for CENTR members.
A pdf version of this report an be downloaded here.
Introduction
The mission of the Internet Engineering Taskforce (IETF) is to make the internet better. Most of the IETF's work is done online, but the organisation also holds 3 meetings a year. The 118th IETF meeting was held in Prague, Czechia, from 4 to 10 November.
With 1,806 registered participants, the meeting was significantly better attended than the previous one. Of those people, 1,067 (just over 59 per cent) were present on site, with the remainder following the meeting remotely. The on-site participants generated data traffic that peaked at ~750 Mbps downstream and ~250 Mbps upstream.
The IETF 118 Hackathon in the weekend prior to the meeting had 588 participants (520 on site, 68 remote). There was also a Code Sprint, at which a small group of volunteers worked at improving the tools made available by the IETF, such as the well-known Datatracker.
Every IETF meeting has a packed programme. Traditionally, meetings have ended around lunchtime on the final day. At IETF 118, however, the final day of the meeting, a Friday, was for the first time another full day. The latest week-long gathering featured 176 working group sessions, a HotRFC, a plenary session and a wide variety of side meetings, before concluding with an informal drink. Because the meeting didn't have a principal sponsor, there was no social event this time around. To the disappointment of the fans, there were no free T-shirts either!
Informal activities
During the weekend prior to the main proceedings, there were various informal activities: a hackathon, the IEPG and the HotRFC Lightning Talks.
Hackathon
The now traditional hackathon got under way on the Saturday prior to the main proceedings. At the hackathon, the applicability and interoperability of new concepts are tested by groups that get together spontaneously to carry out experiments. The event had about 588 participants, the most for any IRTF Hackathon so far. The hackathon concluded with result presentations at the Hackdemo Happy Hour. The many topics addressed included: SCION applications, DNS, post-quantum cryptography, IoT onboarding, NTPv5, and IPv6(-only).
IEPG
The Sunday morning of an IETF meeting traditionally begins with the IEPG, where attention focuses on topics with some form of operational significance.
For example, APNIC's Geoff Huston made an informative presentation about the performance of Starlink, an internet access service developed by SpaceX, which uses LEO satellites (i.e. orbiting the earth at low altitude). The service is intended to bring the internet to remote and relatively inaccessible regions. In his presentation, Geoff described the technology behind Starlink (as deduced by reverse engineering, since Starlink does not disclose exactly how the service works) and drew a number of interesting conclusions.
Figure 1: Starlink presentation slide 21 at IEPG.
HotRFC Lightning Talks
The Sunday ended with the HotRFC Lightning Talks, a fast-moving gathering where speakers talk on a wide variety of topics and pitch ideas. In this context, 'RFC' doesn't stand for 'Request for Comments' (an important category of documents produced by the IETF), but for 'Request for Conversation'. The HotRFC session is a high-paced affair. Each presenter gets just 4 minutes, and no questions are allowed during the session. Any feedback has to be given later.
The session featured a total of 12 talks on a wide range of subjects.
Formal proceedings
At IETF 118, the programme featured so many sessions that, for the first time, the whole of the Friday afternoon was given over to parallel sessions on a wide variety of subjects. A few of the sessions that may be of interest to CENTR members are outlined below.
DNSOP WG
The DNSOP Working Group, which is concerned with the evolution of (the operational aspects of) the DNS protocol, is very active, and therefore held 2 sessions during the week.
Since the previous IETF meeting, 'draft-ietf-dnsop-glue-is-not-optional' has been ratified as RFC 9471: a very useful RFC that expands on the familiar RFC1034 by clarifying how servers should handle glue records.
Meanwhile, 'draft-ietf-dnsop-svcb-https' is now RFC 9460.
If it is really as straightforward as it appears, 'draft-ietf-dnsop-qdcount-is-one' will qualify for 'working group last call' status, meaning that it is only 1 step from ratification.-- Everyone is therefore asked to take a good look at it.
A presentation was made about an idea considered at the IETF Hackathon, involving extension of a parent zone's delegation information to its child zone. The proposed new DELEG record type would support additional properties that existing NS records lack, such as: DNSSEC-signed information about the delegation, information about alternative transport media (e.g. DoT or DoQ) and various other types of information. The concept will require more work before a formal draft is put forward.
Figure 2: DELEG presentation slide 7 at DNSop.
Another interesting idea, certainly for anyone who operates a large anycast infrastructure, involves the use of simple DNS proxies, such as DNSdist. The purpose of 'draft-homburg-dnsop-igadp' is to standardise the way such proxies work. The idea is that a fine-mesh network of proxies could be established as a cost-effective way of boosting the resilience of an anycast network.
Significant discussion was also generated by 'draft-momoka-dnsop-3901bis', which proposes that authoritative name servers should be required to support IPv6. Geoff Houston was in not favour of the proposal, but found himself in the minority. After IETF 118, Geoff therefore wrote a blog on the subject. The draft's proponents argued that it is high time that name servers were required to support IPv6.
The DNSop Working Group also concerns itself with developments that are obliquely interrelated and have the potential to affect one another. So, for example, 'draft-hollenbeck-regext-epp-delete-bcp' describes best practices for the deletion of domain and host objects using EPP.
That brings us directly to the next working group:
REGEXT WG
Despite being a niche group, the Registration Extensions Working Group is responsible for two protocols that are crucial for domain name registers: EPP and RDAP.
Having reached the end of the review process, 3 drafts have been nominated for publication as RFCs:
- RDAP Reverse Search is a draft that specifies how reverse search should work in the RDAP ecosystem, paving the way for the complete functional replacement of WHOIS.
- Federated Authentication for the RDAP using OpenID Connect defines flows associated with RDAP authentication and authorisation by means of OAuth2 and OpenID Connect.
- Finally, Redacted Fields in the RDAP Response specifies methods for interaction between server and client, which ensure the protection of part of the dataset in line with the server's policy. A redacted RDAP field is a field from which data has been deleted or where data has been replaced for some reason (e.g. lack of appropriate access rights).
The group also discussed a proposal regarding standardisation of next-generation EPP protocol transport on the basis of RESTful API principles and possibly JSON data representation. First floated in 2012, the idea was (re-)presented by Maarten Wullink (SIDN Labs) as part of the discussion started in the CENTR R&D and Tech workshop in Paris. The proposal received a very positive response from the wider technical community, but the feedback was that transport and data should be dealt with separately.
OAuth WG and Secure Patterns for Internet CrEdentials (SPICE) BoF
Prompted by the discussion started in the Oauth Working Group at IETF 117, a BoF session was held with the aim of extending the working group's charter to include 'verifiable references in the three-party model' (Issuer-Holder-Verifier), standardised in the various formats by the IETF (JWT, CBOR). The move was considered essential for further development of the reference architecture for the EU eID Wallet. Although the need for the work was generally accepted, there was no consensus as to whether the scope was defined with sufficient clarity.
Meanwhile, given its importance and the need to avoid delay, the work already started by the Oauth Working Group, particularly in relation to JWT tokens for selective publication (SD-JWT) and their use in verifiable login data, will be continued and will remain the group's responsibility.
E-Impact WG
The E-Impact Working Group considers the environmental and sustainability implications of internet technologies. It is a new working group, which met for the first time at IETF 118. While there is little to report regarding its proceedings to date, the E-Impact WG is likely to be worth monitoring in future.
IRTF
Most IETF working groups are concerned with the production of internet standards. However, a number of them are engaged in more general research. Such WGs come under the umbrella of the Internet Research Task Force (IRTF). Unfortunately, it isn't possible to describe this WG's proceedings here in any detail. Nevertheless, the IRTF's discussions provide a useful picture of how the internet is developing. For example, Ramakrishnan Sundara Raman of the University of Michigan made a presentation about the localisation of 'censorship devices'. And Microsoft Research's Siva Kesava Reddy Karkala introduced the audience to SCALE, an automated tool for tracing RFC compliance bugs in DNS software.
Epilogue
Like previous IETF meetings, IETF 118 was a jam-packed and extremely varied week, involving everything from hardcore protocol design sessions to broad-brush conceptual discussions on topics such as the future (quantum) internet, human rights, the challenges presented by the IoT and centralisation, and the environmental impact of the huge edifice that we call the internet. Not to mention an entire weekend devoted to the hackathon for the production of running code, and ample opportunity for mixing and chatting informally with colleagues.
118th IETF meeting took place between 4 and 10 November 2023, in Prague, Czechia.
The next IETF meeting is scheduled for 16 to 22 March 2024 in Brisbane, Australia.
