RFC 9490

Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)

📅 published January 2024, from ietf

Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN) 🦋

Okay bestie, this is RFC 9490, the IAB's report on the M-TEN workshop (that's Management Techniques in Encrypted Networks, fr fr). It's Informational (ISSN 2070-1721), it was published in January 2024, and it's written by M. Knodel, W. Hardaker, and T. Pauly for the Internet Architecture Board (IAB) 💜. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅.

Abstract ✨

The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the participants expressed during the workshop, and they do not necessarily reflect IAB views and positions. 🫶

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not a standard, just a super useful record.

This document is a product of the Internet Architecture Board (IAB). It represents information that the IAB has deemed valuable to provide for permanent record, and it represents the consensus of the IAB. Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9490. 🎀

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. 📜

Table of Contents 🧚

1.  Introduction
  1.1.  About This Workshop Report Content
2.  Workshop Scope and Discussion
  2.1.  "Where We Are" - Requirements and Passive Observations
    2.1.1.  Traffic Classification and Network Management
    2.1.2.  Preventing Traffic Analysis
    2.1.3.  Users and Privacy
    2.1.4.  Discussion
  2.2.  "Where We Want to Go" - Collaboration Principles
    2.2.1.  First-Party Collaboration for Network Management
    2.2.2.  Second- and Third-Party Collaboration for Network
            Management
    2.2.3.  Visible, Optional Network Management
    2.2.4.  Discussion
  2.3.  "How We Get There" - Collaboration Use Cases
    2.3.1.  Establishing Expected Contracts to Enable Security
            Management
    2.3.2.  Zero-Knowledge Middleboxes
    2.3.3.  Red Rover - a Collaborative Approach to Content
            Filtering
3.  Conclusions
4.  Informative References
Appendix A.  Position Papers
  A.1.  Motivations and Principles
  A.2.  Classification and Identification of Encrypted Traffic
  A.3.  Ideas for Collaboration and Coordination between Devices
        and Networks
  A.4.  Other Background Material
Appendix B.  Workshop Participants
Appendix C.  Program Committee
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses

1. Introduction 💖

The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF). 🌸

User privacy and security are constantly being improved by increasingly strong and more widely deployed encryption. This workshop aims to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. 🔥

Network management techniques need to evolve to work effectively and reliably in the presence of ubiquitous traffic encryption and to support user privacy. In an all-encrypted network, it is not viable to rely on unencrypted metadata for network monitoring and security functions, troubleshooting devices, and passive traffic measurements. New approaches are needed to track network behaviors, e.g., by directly cooperating with endpoints and applications, increasing use of in-band telemetry, increasing use of active measurement approaches, and privacy-preserving inference techniques. 🧠

The aim of this IAB online workshop from October 17-19, 2022, has been to provide a platform to explore the interaction between network management and traffic encryption, and to initiate work on collaborative approaches that promote security and user privacy while supporting operational requirements. As such, the workshop addressed the following questions:

  • What are actionable network management requirements?
  • Who is willing to work on collaborative solutions?
  • What are the starting points for collaborative solutions?

1.1. About This Workshop Report Content 📝

This document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

Furthermore, the content of the report comes from presentations given by workshop participants and notes taken during the discussions, without interpretation or validation. Thus, the content of this report follows the flow and dialog of the workshop but does not attempt to capture a consensus. 🙈

2. Workshop Scope and Discussion 🦋

The workshop was held across three days with all-group discussion slots, one per day. The following topic areas were identified, and the program committee organized paper submissions into three main themes for each of the three discussion slots. During each discussion, those papers were presented sequentially, with open discussion held at the end of each day. 💅

2.1. "Where We Are" - Requirements and Passive Observations 👀

The first day of the workshop focused on the existing state of the relationship between network management and encrypted traffic from various angles. Presentations ranged from discussing classifiers using machine learning to recognize traffic, to advanced techniques for evading traffic analysis, to user privacy considerations. 💜

After an introduction that covered the goals of the workshop and the starting questions (as described in Section 1), there were four presentations followed by open discussion.

2.1.1. Traffic Classification and Network Management 🔍

Many existing network management techniques are passive in nature. They don't rely on explicit signals from end hosts to negotiate with network middleboxes. Instead, they rely on inspecting packets to recognize traffic and apply various policies. Traffic classification, as a passive technique, is being challenged by increasing encryption. 😭

Traffic classification is commonly performed by networks to infer what applications and services are being used. This information is in turn used for capacity and resource planning, Quality-of-Service (QoS) monitoring, traffic prioritization, network access control, identity management, and malware detection. However, since classification commonly relies on recognizing unencrypted properties of packets in a flow, increasing encryption of traffic can decrease the effectiveness of classification. 🔐

The amount of classification that can be performed on traffic also provides useful insight into how "leaky" the protocols used by applications are, and it points to areas where information is visible to any observer, who may or may not be malicious. 👑

Frequently, classification has been based on specific rules crafted by experts, but there is also a move toward using machine learning to recognize patterns. "Deep learning" machine-learning models generally rely on analyzing a large set of traffic over time and have trouble reacting quickly to changes in traffic patterns. 🤖

Models that are based on closed-world data sets also become less useful over time as traffic changes. [JIANG] describes experiments that show that a model that performed with high accuracy on an initial data set becomes severely degraded when running on a newer data set that contains traffic from the same applications. Even in as little time as one week, the traffic classification would become degraded. However, the set of features in packets and flows that were useful for models stayed mostly consistent, even if the models themselves needed to be updated. Models where the feature space is reduced to fewer features showed better resiliency and could be retrained more quickly. Based on this, [JIANG] recommends more work and research to determine which set of features in IP packets are most useful for focused machine-learning analysis. [WU] also recommends further research investment in Artificial Intelligence (AI) analysis for network management. 🧪

2.1.2. Preventing Traffic Analysis 🕵️

Just as traffic classification is continually adapting, techniques to prevent traffic analysis and to obfuscate application and user traffic are continually evolving. An invited talk from the authors of [DITTO] shared a novel approach with the workshop for how to build a very robust system to prevent unwanted traffic analysis. ✨

Usually, traffic obfuscation is performed by changing the timing of packets or by adding padding to data. These practices can be costly and negatively impact performance. [DITTO] demonstrated the feasibility of applying traffic obfuscation on aggregated traffic in the network with minimal overhead and at inline speed. 🚀

While traffic obfuscation techniques are not widely deployed today, this study underlines the need for continuous effort to keep traffic models updated over time, the challenges of the classification of encrypted traffic, and the opportunities to further enhance user privacy. 🌟

2.1.3. Users and Privacy 🎀

The Privacy Enhancements and Assessments Research Group (PEARG) is working on a document to discuss guidelines for measuring traffic on the Internet in a safe and privacy-friendly way [LEARMONTH]. These guidelines and principles provide another view on the discussion of passive classification and analysis of traffic. 🛡️

Consent for collection and measurement of metadata is an important consideration in deploying network measurement techniques. This consent can be given explicitly as informed consent, given by proxy, or may be only implied. For example, a user of a network might need to consent to certain measurement and traffic treatment when joining a network. 🫧

Various techniques for data collection can also improve user privacy, such as discarding data after a short period of time, masking aspects of data that contain user-identifying information, reducing the accuracy of collected data, and aggregating data. 💜

2.1.4. Discussion 💬✨

okay so the intents and goals of users, app devs, and network operators line up sometimes, but not always 🫠. One of the recurring struggles was that there's no clear way to understand or communicate intents and requirements. Both traffic classification and traffic obfuscation are trying to change how visible traffic is without anyone else's cooperation 👀. Traffic classification is the network trying to peek inside application traffic without the apps coordinating, and traffic obfuscation is the app trying to hide that same traffic while it travels across a network 🥷. Chaotic, but iconic.

Traffic adaptation and prioritization is where the incentive to cooperate looks clearest 💖. Even if an app is trying to stop metadata from leaking, it could still benefit from the network telling it about sudden capacity changes, so it can adjust its quality, like bitrates and codecs 📉. That kind of signaling might not be appropriate for the most privacy-sensitive apps, like Tor 🧅, but it could totally work for lots of others. There are existing protocols that involve explicit signaling between apps and networks, such as Explicit Congestion Notification (ECN) [RFC3168], but it hasn't really seen wide adoption yet 😔.

Managed networks, like private corporate networks, came up in several comments as especially tricky for meeting management requirements while still keeping encryption and privacy 🏢. These networks can have legal and regulated requirements to detect specific fraudulent or malicious traffic 🚨.

Personal networks with managed parental controls have similar complications with encrypted traffic and user privacy 👨‍👩‍👧. In these setups, the parental controls operated by the network may be as simple as a DNS filter 🧸, which can be made ineffective when a device routes its traffic to an alternate DNS resolver 🙃.

2.2. "Where We Want to Go" - Collaboration Principles 🗺️

Day two of the workshop zoomed in on emerging techniques for analyzing, managing, or monitoring encrypted traffic 🔍. Presentations covered advanced classification and identification, including machine-learning techniques, for managing network flows or for monitoring or monetizing usage 🤖.

After an introduction covering the goals of the workshop and the starting questions (as described in Section 1), there were three presentations, followed by open discussion 🎤.

2.2.1. First-Party Collaboration for Network Management 🤝

The whole point of end-to-end encryption is to create a barrier between the entities inside the communication channel and everyone else, network operators included 🛡️. So any attempt to get past that intentional barrier needs collaboration between the inside and outside entities 🫂. At a minimum, those entities must agree on the benefits of overcoming the barrier (or solving the problem), agree that costs are proportional to those benefits, and agree to additional limitations or safeguards against bad behavior by collaborators, including other non-insiders [BARNES] 📜.

The Internet is designed to be interoperable, which means an outside entity wanting to collaborate with the inside might be any number of intermediaries, not a specific person you can trust in the human sense 🤷‍♀️. Plus, encryption (especially network-layer or transport-layer encryption) brings in dynamic, opportunistic, or perfunctory discoverability 🔎. These realities point to a need to ask why an outside entity might make an engineering case to collaborate with the user of a network with encrypted traffic, and whether the trade-offs and potential risks are worth it to that user 🧐.

However, the answers can't be specific 🙅‍♀️, and the determinations or guidance need to be general, since the encryption boundary is inevitably an application used by many people 🌍. Trade-offs have to make sense to users who aren't likely to be thinking about network management at all 😴. Harms need to be preemptively reduced because, in general terms, few users would choose network management benefits over their own privacy if given the choice 🔒.

Some have found that there appears to be little, if any, evidence that encryption causes network problems that are meaningful to the user 🤔. Since alignment on problem solving is a prerequisite to collaboration on a solution, it doesn't seem that collaboration across the encryption boundary is called for 🙃.

2.2.2. Second- and Third-Party Collaboration for Network Management 🕵️

Even with the wide-scale deployment of encryption in new protocols, and of techniques that stop passive observers from knowing the content of exchanged communications, important information can still sometimes be deduced: which parties communicate, and sometimes even which services have been requested 👀. The future is about concealing more data and metadata from passive observers, and also minimizing information exposure to second parties (where the user is the first party) by, maybe counterintuitively, introducing third-party relay services to sit in the middle 🔀. As discussed in [KUEHLEWIND], the relay is a mechanism that uses additional levels of encryption to separate two important pieces of information: knowledge of the identity of the person accessing a service is separated from knowledge about the service being accessed 🧅✨. By contrast, a VPN uses only one level of encryption and does not separate identity (first party) and service (second party) metadata 🙅.

Relay mechanisms are termed "oblivious" 🫥, there is a future for specifications in privacy-preserving measurement (PPM) 📊, and protocols like Multiplexed Application Substrate over QUIC Encryption (MASQUE) are discussed in the IETF 🗣️. In various schemes, users are ideally able to share their identity only with the entity they have identified as a trusted one, and that data is not shared with the service provider 🫶. However, this is more complicated for network management, but there may be opportunities for better collaboration between the network and, say, the application or service at the endpoint 💡.

A queriable relay mechanism could preserve network management functions that are disrupted by encryption, such as TCP optimization, quality of service, zero-rating, parental controls, access control, redirection, content enhancement, analytics, and fraud prevention 📋. Instead of encrypting communication between only two ends while all on-path elements passively observe, intermediate relays could be introduced as trusted parties that get to see limited information for the purpose of collaboration between in-network intermediary services 🧚.

2.2.3. Visible, Optional Network Management 👁️

Out of all the possible network management functions that might be helped by proxying, the ability to control congestion in encrypted communications has been researched in depth 📈. These techniques are realized based on TCP performance-enhancing proxies (PEPs) that either entirely intercept a TCP connection or interfere with the transport information in the TCP header 🛠️. However, despite the challenge that the new encrypted protocol will limit any such in-network interference, these techniques can also have a negative impact on the evolvability of these protocols 😬. So a new approach was presented: instead of manipulating existing information, additional information is sent using a so-called sidecar protocol, independent of the main transport protocol that is used end to end [WELZL] 🛸. For example, sidecar information can contain additional acknowledgments to enable in-network local retransmission, or faster end-to-end retransmission by reducing the signaling round-trip time ⏱️.

Taking user privacy benefits for granted, there is a need to investigate the comparable performance outputs of various encrypted traffic configurations 📊, such as the use of an additional sidecar protocol, or explicit encrypted and trusted network communication using MASQUE, in relation to existing techniques such as TCP PEPs, etc. 🧐

2.2.4. Discussion 🗯️

One size fits all? 🤨 On the issue of trust, different networks or devices will have different trust requirements for devices, users, or each other, and vice versa. For example, imagine two networks with really different security requirements, like a home network with a requirement to protect its child users versus a national security institution's network 🏠🏛️. How could one network architecture solve the needs of all use cases? 🤯

Does our destination have consequences? 🌪️ It seems sometimes that there may be future consequences caused by the ubiquitous, strong encryption of network traffic, because it will cause intermediaries to poke holes in what are supposed to be long-term solutions for user privacy and security 🕳️.

Can we bring the user along? 🥺 While there has been a focus on the good reasons why people might collaborate across the encryption barrier, there will always be others who want to disrupt that in order to exploit the data for their own gain, and sometimes exploitation is called innovation 💅. High-level policy mitigations have exposed how powerless end users are against corporate practices of data harvesting 😤. And yet, interfaces to help users understand these lower-layer traffic flows, so they can protect their financial transactions or privacy, haven't been achieved yet 🥲. That means that engineers must make inferences about user wants. Instead, we should make these relationships and trade-offs more visible ✨.

2.3. "How We Get There" - Collaboration Use Cases 🛣️

The third day focused on techniques that could be used to improve the management of encrypted networks 🌈. The potential paths forward described in the presentations included some element of collaboration between the networks and the subscribing clients that simultaneously want both privacy and protection 🫶. Thus, the central theme of the third day became negotiation and collaboration 🤝💜.

2.3.1. Establishing Expected Contracts to Enable Security Management ✨

Okay bestie, so for enterprise networks where client behavior might be managed 👀, [COLLINS] comes in with "Improving network monitoring through contracts" 💅. The idea is that contracts describe the different states that network behavior can be in.

Why does this matter? Network operators only have so much time to focus on problems and get through alerts 😩. Contracts and states let the operator zoom in on one aspect of whatever situation they're dealing with 🔍. The current estimate for how many events a Security Operations Center (SOC) operator can handle is about 10 per hour 💀. Operators have to work within the limits their organization sets 🎀 and pick from options that often just frustrate attackers. Stopping attacks entirely is potentially impossible 🙈. Finally, operators have to prioritize and handle as many events as they possibly can 🫶.

Validating which alerts are true positives is a whole thing 😭 because lots of weird traffic creates tons of anomalies, and not every anomaly is malicious. Figuring out which anomalous traffic is actually rooted in malicious activity, with any real certainty, is extremely hard 💔. Applying the latest machine-learning techniques has, unfortunately, produced mixed results 🤷‍♀️. And it gets worse: the massive amounts of Internet-wide scanning mean endless traffic that is technically malicious but just creates information overload and makes event prioritization a nightmare 🌪️. Any path forward has to free up analyst time so they can concentrate on the harder events ✨.

The proposed contract solution is to define a collection of acceptable behaviors made of different states that might include IP addresses, domain names, and indicators of compromise 📋. A deviation from a contract might mean that a system is acting outside a normal mode of behavior, or that a normal mode of behavior is suddenly missing 👀. An example contract might be "this system is expected to update its base OS once a day". If that doesn't happen, the expectation hasn't been met, and the system should be checked because it failed to call home to look for (potentially security-related) updates 🚨.

Within the IETF, the Manufacturer Usage Description Specification (MUD) [RFC8520] is one subset of contracts 🧚. Note that contracts are likely to succeed only in a constrained, expected environment maintained by operational staff, and they may not work in an open Internet environment where end users drive all network connections 🌍.

2.3.2. Zero-Knowledge Middleboxes 🦋

The world is not only shifting to more encrypted traffic, it's also encrypting more and more of the metadata (e.g., DNS queries and responses) 🔐. That makes network policy enforcement by middleboxes way more challenging 😤. The result is a major tension between security enforcement and privacy protection 💜.

Goals for solving this problem should include enabling networks to enforce their policies, but should not include weakening encryption or deploying new server software 🙅‍♀️. Existing solutions fail to meet at least one of these points.

A cryptographic principle called "zero-knowledge proof" (ZKP) [GRUBBS] may be one path forward worth considering 🧠. A ZKP lets a third party verify that a statement is true without revealing what the statement actually is 🤯. Applying this to network traffic has been shown to let a middlebox verify that traffic to a web server is compliant with a policy without revealing the actual contents 🫣. This solution meets the three criteria listed above. Using ZKP within TLS 1.3 traffic turns out to be plausible 🌸.

An example engine using encrypted DNS was built to test ZKP 🛠️. Clients were able to create DNS requests that were not listed within a DNS block list. Middleboxes could verify, without knowing the exact request, that the client's DNS request was not on the prohibited list 🙌. Although the result was functional, the computational overhead was still too slow 🐢, and future work will be needed to decrease the ZKP-imposed latencies ⏱️.

2.3.3. Red Rover - a Collaborative Approach to Content Filtering 🛡️

The principal challenge being studied is how to handle the inherent conflict between filtering and privacy 🥊. Network operators need to implement policies and regulations that can originate from many locations (e.g., security, governmental, parental, etc.). Meanwhile, clients need to protect their users' privacy and security 🔒.

Safe browsing, originally created by Google, is one example of a mechanism that tries to meet both sides of this conflict 🌈. It would be beneficial to standardize this and other similar mechanisms. Operating systems could continually protect their users by making sure that malicious destinations are not being reached 🛡️. This would require some coordination between cooperating clients and servers offering protection services. These collaborative solutions may be the best compromise for resolving the tension between privacy services and protection services [PAULY] 💜.

3. Conclusions 🎀

Looking forward, the workshop participants identified that solving the entire problem space with a single approach will be challenging for several reasons:

  • The scalability of many solutions will likely be an issue, since some solutions are complex or expensive to implement 💸.
  • Collaboration between multiple parties will be required for many mechanisms to function, and the sets of parties required for different use cases might be disjoint 🤝.
  • There is an unanswered question of whether or not network operators are willing to participate by allowing new encryption technologies into their environment in exchange for technologies that prove their clients are being good net-citizens 🤔. If so, some of these solutions might be required to exist before networks allow a certain type of increased encryption. Consider the example of TLS Encrypted Client Hello being blocked by some network operators 🚫.

The breadth of the problem space itself is another complicating factor 🌍. There is a wide variety of network architectures, and each has different requirements for both data encryption and network management. Each problem space will have multiple, different encumbrances: for example, technical, legal, data ownership, and regulatory concerns 📚. New network architectures might be needed to solve this problem at a larger scope, which would in turn require interoperability support from network product vendors 🏗️. Education about various solutions will be required so that regulation and policy organizations can understand, and thus support, the deployment of developed solutions 🎓.

After new technologies and related standards are developed and deployed, unintended consequences can emerge 😬. These lead to effects in multiple directions. On one hand, exposed protocol values not intended for network management might be used by networks to differentiate traffic. On the other hand, changes to a protocol that break existing use cases might have an impact on private network deployments 🫠. While making decisions on technology direction and protocol design, it is important to consider the impact on various kinds of network deployments and their unique requirements 💖. When protocols change to make different network management functions easier or harder, the impact on various deployment models ought to be considered and documented 📝✨.

4. Informative References 🧾

Okay bestie, here are all the receipts 🧾💅 Every source the doc pointed at, with the full details so you can go find them yourself.

Appendix A. Position Papers 🌸

Okay so, anyone who was into the workshop was openly invited to send in position papers 💖 That could be Internet-Drafts, academic papers, or short abstracts explaining why they cared. The papers below are the inputs the workshop folks considered relevant, the ones that actually got the discussions going ✨ The program committee sorted them into themes, and I'm obsessed with how neat that looks.

A.1. Motivations and Principles

  • Richard Barnes. "What's In It For Me? Revisiting the reasons people collaborate." [BARNES]
  • Mallory Knodel. "(Introduction) 'Guidelines for Performing Safe Measurement on the Internet'." (Additional rationale) [KNODEL]
  • Qin Wu, Jun Wu, Qiufang Ma. "Network Management of Encrypted Traffic: Detect it don't decrypt it." [WU]

A.2. Classification and Identification of Encrypted Traffic

  • Luca Deri. "nDPI Research Proposal." [DERI]
  • Wes Hardaker. "Network Flow Management by Probability." [HARDAKER]
  • Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt, Nick Feamster. "Towards Designing Robust and Efficient Classifiers for Encrypted Traffic in the Modern Internet." [JIANG]
  • Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. "Encrypted Traffic Classification Through Deep Learning." [LEI]

A.3. Ideas for Collaboration and Coordination between Devices and Networks

  • Michael Collins. "Improving Network Monitoring Through Contracts." [COLLINS]
  • Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. "Zero-Knowledge Middleboxes." [GRUBBS]
  • Mirja Kuehlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Ihlar. "Relying on Relays: The future of secure communication." [KUEHLEWIND]
  • Tommy Pauly, Richard Barnes. "Red Rover: A collaborative approach to content filtering." [PAULY]
  • Michael Welzl. "The Sidecar: 'Opting in' to PEP Functions." [WELZL]

A.4. Other Background Material

  • Pedro Casas. "Monitoring User-Perceived Quality in an Encrypted Internet - AI to the Rescue." [CASAS]
  • Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Prof. Tommaso Pecorella. "Performance Monitoring in Encrypted Networks: PDMv2." [ELKINS]

Appendix B. Workshop Participants 🎀

The whole squad of workshop participants was Cindy Morgan, Colin Perkins, Cullen Jennings, Deborah Brungard, Dhruv Dhody, Éric Vyncke, Georg Carle, Ivan Nardi, Jari Arkko, Jason Livingood, Jiankang Yao, Karen O'Donoghue, Keith Winstein, Lars Eggert, Laurent Vanbever, Luca Deri, Mallory Knodel, Marcus Ihlar, Matteo, Michael Collins, Michael Richardson, Michael Welzl, Mike Ackermann, Mirja Kühlewind, Mohit P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul Grubbs, Pedro Casas, Qin Wu, Qiufang Ma, Richard Barnes, Rob Wilton, Russ White, Saloua Naama, Shinan Liu, Srinivas C, Toerless Eckert, Tommy Pauly, Wes Hardaker, Xi Chase Jiang, Zaheduzzaman Sarker, and Zhenbin Li. That's a lot of brilliant people 😭🫶

Appendix C. Program Committee 👑

The workshop program committee members were Wes Hardaker (IAB, USC/ISI), Mallory Knodel (IAB, Center for Democracy and Technology), Mirja Kühlewind (IAB, Ericsson), Tommy Pauly (IAB, Apple), Russ White (IAB, Juniper), and Qin Wu (IAB, Huawei). The committee that made it all happen 💜

IAB Members at the Time of Approval 🌈

These Internet Architecture Board members were on the board at the time this document was approved for publication:

  • Dhruv Dhody
  • Lars Eggert
  • Wes Hardaker
  • Cullen Jennings
  • Mallory Knodel
  • Suresh Krishnan
  • Mirja Kühlewind
  • Tommy Pauly
  • Alvaro Retana
  • David Schinazi
  • Christopher Wood
  • Qin Wu
  • Jiankang Yao

Acknowledgments 🦋

We wish to acknowledge the comments and suggestions from Elliot Lear and Arnaud Taddei for their comments and improvements to this document. Thank you for the glow-up 🧚✨

Authors' Addresses 💌

  • Mallory Knodel
    • Email: mknodel@cdt.org
  • Wes Hardaker
    • Email: ietf@hardakers.net
  • Tommy Pauly
    • Email: tpauly@apple.com
📦 where this page comes from