Introduction

The IETF held its 120th meeting in Vancouver. BC, Canada. The IETF last met in Vancouver in November 2013. Vancouver is a popular destination for the IETF - this is the sixth time the standards organization has met there. This time, there were 833 in-person attendees and 681 remote attendees. That attendance profile is consistent with what has happened at the IETF since it began to accommodate both remote and in-person attendance since the pandemic.

As is typical for meetings in North America, attendance was dominated by participants from the United States (40.1%), followed by China (9.8%), Canada (6.8%), Germany (6.5%), and the United Kingdom (4.6%). For some time, the IETF has been granting attendance fee waivers to try to diversify its participation. At the Vancouver meeting, 273 requests for fee waivers came from remote participants, and 258 were used.

In another important initiative to diversify participation, the IETF continued its on-site childcare program with 16 participants in Vancouver.

The IETF has many parts, but the protocol development and standardization work is done in 128 Working Groups divided into six major areas. Regarding workload, some areas have more than 300 adopted Working Group documents; one has less than sixty. The average number of active pieces of work per area is 142.

ALLDISPATCH

One of the most intriguing things about any standards organization is its mechanism to get new work into the standards pipeline. Each standards organization has its own model, and the IETF has several ways to start new work. At the IETF 119 meeting in Brisbane began an experiment which allowed individual authors to get guidance from the IETF community on where to take their work.

The ALLDISPATCH experiment was a qualified success in Brisbane. The IESG decided to continue the experiment in Vancouver. What was striking about the conversation at ALLDISPATCH was that many of the items to be discussed were more about how the IETF manages its business than technical protocols.

Two documents discussed the need for changes in the policies that govern how IANA registers protocol parameters and the language used in RFCs to describe those policies. RFC8126 was approved before the pandemic and describes guidelines for authoring the "IANA Considerations" section of every RFC. The two documents came from veterans of the IETF standardization process: one from John Klensin and another from Carsten Bormann. The result was that the community felt that RFC8126 itself needed to be revised. While incremental change was considered possible, holistic and complete reconsideration was considered optimal. A small working group was agreed upon for this purpose.

Diversity is a difficult challenge for the IETF. Several initiatives have been brought forward to ensure a more diverse community is participating in IETF standards work. One such proposal came to ALLDISPATCH in the form of a suggestion that the Nominating Committee that the IETF uses to select some of its leadership not be allowed to be men only. The suggestion is to update RFC8713, which is the RFC that describes how important IETF-related positions are selected. It was inevitable that the conversation around this proposal was mainly about the merit of the proposal rather than where to discuss it. Diversity and inclusion are evergreens in the IETF community - often discussed but recognized as a complex and difficult problem to solve. In Vancouver, the Chair of the IETF agreed to start a small working group to follow up on this proposal.

ALLDISPATCH in Vancouver considered three other governance and policy-related proposals. One was an adjustment to how mailing lists are managed and the mechanisms for dealing with bad behaviour on mailing lists. This topic came up several times during the week in Vancouver - probably because some recent behaviour on some of the IETF's most commonly used mailing lists has been inappropriate. Another proposal in Vancouver was a discussion of how to deal with timelines and milestones when a working group is set up. The last was [a proposal to more explicitly discuss what "IETF Experiments" are.

Finally, there were two technical proposals to be "dispatched." First was a proposal on authenticating IP encapsulation headers - answering the question: how do you steer traffic through a backbone? The authentication is proposed for specific flows and not all flows. The other technical proposal was about identity in machine-to-machine communication. The current mechanism on the Internet uses something called "user info" which is judged by recent implementers to be insecure and inefficient. A proposal is to replace this with a new, special purpose URI. In both of these cases, the decision was to start a new mailing list to discuss these documents.

Network Attestation for Secure Routing (nasr)

One of the other ways to get new work into the IETF is to hold a Birds of a Feather (BoF) session where interested parties gather together to talk about a common problem and see if there is interest in working on a solution. BoFs are often precursors to new, fully-formed Working Groups. For new participants (and, veterans too!) BoFs are often an early alert system to emerging technologies or new requirements on the Internet. BoF are only sometimes successful at forming Working Groups, but they are almost always a good indicator of areas where new standards work needs to be done.

One of the BoFs in Vancouver was on the topic of Network Attestation for Secure Routing (nasr). The main idea of nasr is this: Internet endpoints and clients have security requirements beyond providing encryption (for privacy) and traffic signing (to ensure authenticity). Instead, those clients want to add characteristics such as trustworthiness or other security properties of the traffic's path.

According to one of the drafts presented at the BoF, the goals are:

1. Allow clients to choose desired security attributes of his received network service

2. Achieve dependable forwarding by routing on top of only devices that satisfies his trust requirements

3. Provide proof to the clients that certain packets or flows traversed a network path that has certain trust or security properties.

There was significant discussion about how the nasr approach would work with other existing and new protocols. There was also discussion about how well such an approach would scale in the public Internet. In particular, the nasr solution would be built upon the existing work in the RATS working group. There was also significant doubt that this would scale beyond very simple interconnected networks. One comment was: "The problem is when there are 2 operators, this model probably works. But when there are 10+ banks and 10+ operators, how would you solve this without multi-hop routing techniques, including packet marking?"

In the end, the chairs felt that there was a need for further clarification of the use cases and the scope. A new working group was not agreed and additional work will be done on the nasr mailing list. One of the important things about the content of this BoF is that it overlaps significantly with work going on in Study Group 13 in the ITU-T. In the ITU-T work on inter-domain trust and allowing clients to choose from a menu of security characteristics for traffic flows is going in a different direction. Unfortunately, coordination between the two standards bodies is not very effective.

Digital Emblems (diem)

Another of the Vancouver BoFs was Digital Emblems (diem). The Oxford English Dictionary defines an emblem as "*a heraldic device or symbolic object as a distinctive badge of a nation, organization, or family.*" Emblems are familiar in many settings, but for this BoF, the use case is pretty straightforward. We know many emblems in international settings: a red cross or crescent, a blue helmet, a white flag, or a label of "Press" worn by a journalist in a conflict. All of these emblems are relatively well understood, and some even enjoy protection under international law. The question is: how would you extend this kind of label in the digital realm?

There are two problems to address. First, how do you protect endpoints and network objects that are part of a protected organization's infrastructure? The problem extends far beyond protecting the assets of a web server or a cloud service. Instead, the asset could signal the ownership of a phone or tablet even if it weren't connected to the network. Second, there is the problem of having markings (as symbols) in equipment and physical assets. Currently there is a proliferation of incompatible scanners for those markings depending on what the equipment is. In fact, there are thousands of organizations that are required to do markings under international law.

So, there is a humanitarian problem and a quite different commerce problem. Both need some solution to creating, using and verifying digital emblems. During the BoF it was noted that these seem like very different use cases that require very different solutions. Many participants noted how complex the solutions would be for either problem space. There was also discussion about how this overlaps with supply-chain work already going on in the IETF (for instance, in the SCITT or SPICE working groups). Other people noted work already occurring in the European Union and in other standards organizations.

The BoF concluded by deciding to continue the discussion on the diem mailing list.

Getting Ready for Energy-Efficient Networking (green)

Network operators are clearly concerned about sustainability. As recently as 2022, total energy consumption for data networks was 260-360 TWh in 2022 (source: IEA). There are also social responsibility missions and regulations that fall on network operators to be more sustainable. The Getting Ready for Energy-Efficient Networking BoF was an attempt to determine what the IETF could do in this space.

This topic is of huge interest to various standards organizations, not just the IETF. While there was clear interest in having a forum for discussion of energy management in the IETF (the vast majority of the participants in the room said they supported the formation of a working group), it was still not clear what the IETF could do usefully in 12-24 months.

We will cover this in much more detail in a future posting, but for now, the next step at the IETF is to develop a draft charter for the working group and a set of deliverables that could be achieved in the next year or two. That discussion is taking place on a very active IETF mailing list.

DNS Delegation (deleg)

We've reported earlier on this very interesting development for the DNS (here and here). This was the first meeting of the new Working Group after being a BoF. DELEG is a proposed change to the DNS that would allow for different (and new!) kinds of signalling between recursive resolvers and authoritative servers. That sounds technical (and it is), but it can potentially represent a significant change to the DNS.

The BoF sessions for DELEG were contentious and a little chaotic, with opinions all over the spectrum about its value. In Vancouver, the chaos was magically gone, replaced by a step-by-step and practical approach to identifying problems and use cases and then moving on to possible solutions.

The first item on the agenda was a presentation on the charter of the working group. The charter specifies that a requirements document be published before any solutions are proposed or discussed. It focuses on the use case where authoritative servers can signal their capabilities to recursive resolvers. Somewhat surprisingly, there were no comments about the charter from the floor.

Next, deleg moved to a discussion of a first version of the requirements document. It was worked on during the summer and first published on the 8th of July (the deleg meeting was on the 22nd of July). The draft is organized around a group of "hard requirements" and "soft requirements." Hard requirements are those that are strictly required in any proposed solution. Soft requirements are those that should be adopted by any solution. The authors sought working group adoption for this early draft, and a decision is to be made on the deleg mailing list.

The intent for any proposed solution is that the existing aspects of the pre-DELEG ecosystem will continue to work as is. The question is: what does this mean for DELEG-only zones? Will DELEG-only zones be acceptable? Another suggestion from the floor is that any proposed solution be incrementally deployable.

Then, Paul Hoffman of ICANN talked about aliasing and transport for the new protocol. Aliasing is the process of using a name to specify multiple target servers as the authoritative source of information on a child zone. Both the parent and the child zone will have DELEG requirements. Transport support is likely to be easier than dealing with aliasing.

Finally, James Galvin talked about the relationship between the IETF and ICANN in regard to affecting registrations and operations. Resource Record types in gTLD zone files are restricted and those restrictions can be changed by community input.

Decentralization of the Internet Research Group (dinrg)

DINRG has been active during in-person IETF meetings, but its mailing list is a little bit quiet. It's possible that some of the material from the Vancouver meeting will help engagement on dinrg's mailing list in the fall and winter of 2024. DINRG also has it's own wiki with quite a few pointers to presentations, reports and proceedings.

DINRG had a series of four presentations:

1) Exploring Decentralized Digital Identity Protocols by Kaliya Young;

2) DNS-Bound Client and Sender Identities by Michael Richardson;

3) Centralisation, Consolidation, and Fragmentation by Sheetal Kumar; and

4) SOLID: Your Data, Your Choice by Hadrian Zbarcea.

Of these, Ms Kumar's presentation was the most consistent with previous work in the research group. The draft is available on GitHub and is notable because, unlike other earlier contributions on decentralization and fragmentation, it has a notably positive outlook with straightforward suggestions for improving the centralization problem by focusing attention on the end user of services rather than the provider of services.

Following the presentations, the chairs of the working group attempted to have a panel discussion on centralization with the following participants:

- Geoff Huston (APNIC)

- Christian Huitema (Private Octopus)

- Dirk Kutscher (HKUST)

- Arnaud Taddei (Broadcom)

- Lixia Zhang (UCLA)

The goal was to have the panelists discuss three high-level topics:

1. "Centralization" – state of system

  - do we have a good enough understanding of the factors (economic,  

    technical, regulatory)?

  - what has changed recently?

  - what should we study more?

2. Responding to centralization

  - how should societies and market react?

  - which groups & stake-holders should get engaged?

  - whose interests do we want to push?

  - what could go wrong (risks in countering centralization)

3. Future work for DINRG

  - what should DINRG focus on?

  - what are most fruitful topics and potential projects?

  - what could/should be the results of the DINRG work?

Unfortunately, the chairs didn't schedule enough time for the panelists to discuss all these intriguing questions. In addition, there was no time for questions and comments from the floor. Hopefully, the chairs will budget more time for discussion in future panels. You can see a video recording of the session in Vancouver here.

Next Meeting

IETF 121 is to be held in Dublin, Ireland from November 2-8. 2024. Most of the substantial work of the IETF is done on mailing lists. However, since the pandemic, the IETF has used interim meetings for many of its working groups to ensure protocol development moves along. A complete list of the interim meetings is available here.