doc: Add RFC documents

1 files changed, 802 insertions, 0 deletions

diff --git a/doc/rfc/rfc9490.txt b/doc/rfc/rfc9490.txt
new file mode 100644
index 0000000..1eefffb
--- /dev/null
+++ b/doc/rfc/rfc9490.txt
@@ -0,0 +1,802 @@
+
+
+
+
+Internet Architecture Board (IAB)                              M. Knodel
+Request for Comments: 9490                                              
+Category: Informational                                      W. Hardaker
+ISSN: 2070-1721                                                         
+                                                                T. Pauly
+                                                            January 2024
+
+
+   Report from the IAB Workshop on Management Techniques in Encrypted
+                            Networks (M-TEN)
+
+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 expressed during the workshop by participants and do not
+   necessarily reflect IAB views and positions.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (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 Notice
+
+   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, as 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 but instead 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 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.  The 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 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, as well as 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
+
+   The intents and goals of users, application developers, and network
+   operators align in some cases, but not in others.  One of the
+   recurring challenges that was discussed was the lack of a clear way
+   to understand or to communicate intents and requirements.  Both
+   traffic classification and traffic obfuscation attempt to change the
+   visibility of traffic without cooperation of other parties: traffic
+   classification is an attempt by the network to inspect application
+   traffic without coordination from applications, and traffic
+   obfuscation is an attempt by the application to hide that same
+   traffic as it transits a network.
+
+   Traffic adaptation and prioritization is one dimension in which the
+   incentives for cooperation seem most clear.  Even if an application
+   is trying to prevent the leaking of metadata, it could benefit from
+   signals from the network about sudden capacity changes that can help
+   it adapt its application quality, such as bitrates and codecs.  Such
+   signaling may not be appropriate for the most privacy-sensitive
+   applications, like Tor, but could be applicable for many others.
+   There are existing protocols that involve explicit signaling between
+   applications and networks, such as Explicit Congestion Notification
+   (ECN) [RFC3168], but that has yet to see wide adoption.
+
+   Managed networks (such as private corporate networks) were brought up
+   in several comments as particularly challenging for meeting
+   management requirements while maintaining encryption and privacy.
+   These networks can have legal and regulated requirements for
+   detection of specific fraudulent or malicious traffic.
+
+   Personal networks that enable managed parental controls have similar
+   complications with encrypted traffic and user privacy.  In these
+   scenarios, the parental controls that are operated by the network may
+   be as simple as a DNS filter, which can be made ineffective by a
+   device routing traffic to an alternate DNS resolver.
+
+2.2.  "Where We Want to Go" - Collaboration Principles
+
+   The second day of the workshop focused on the emerging techniques for
+   analyzing, managing, or monitoring encrypted traffic.  Presentations
+   covered advanced classification and identification, including
+   machine-learning techniques, for the purposes of managing network
+   flows or monitoring or monetizing usage.
+
+   After an introduction that covered 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
+
+   It is the intent of end-to-end encryption of traffic to create a
+   barrier between entities inside the communication channel and
+   everyone else, including network operators.  Therefore, any attempt
+   to overcome that intentional barrier requires 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 the benefits, and
+   agree to additional limitations or safeguards against bad behavior by
+   collaborators including other non-insiders [BARNES].
+
+   The Internet is designed interoperably, which means an outside entity
+   wishing to collaborate with the inside might be any number of
+   intermediaries and not, say, a specific person that can be trusted in
+   the human sense.  Additionally, the use of encryption, especially
+   network-layer or transport-layer encryption, introduces dynamic or
+   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
+   to ask whether the trade-offs and potential risks are worth it to the
+   user.
+
+   However, the answers cannot be specific, and the determinations or
+   guidance need to be general as the encryption boundary is inevitably
+   an application used by many people.  Trade-offs must make sense to
+   users who are unlikely to be thinking about network management
+   considerations.  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 does not 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 prevent passive observers of network traffic
+   from knowing the content of exchanged communications, important
+   information, such as which parties communicate and sometimes even
+   which services have been requested, may still be able to be deduced.
+   The future is to conceal more data and metadata from passive
+   observers and also to minimize information exposure to second parties
+   (where the user is the first party) by, maybe counterintuitively,
+   introducing third-party relay services to intermediate
+   communications.  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.  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 with
+   passive observation by all on-path elements, 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 of the possible network management functions that might be
+   ameliorated 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.  Therefore, a new
+   approach was presented where, 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 to 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
+
+   For enterprise networks where client behavior is potentially managed,
+   [COLLINS] proposes "Improving network monitoring through contracts",
+   where contracts describe different states of network behavior.
+
+   Because network operators have a limited amount of time to focus on
+   problems and process alerts, contracts and states let the operator
+   focus on a particular aspect of a current situation or problem.  The
+   current estimate for the number of events a Security Operations
+   Center (SOC) operator can handle is about 10 per hour.  Operators
+   must work within the limits imposed by their organization and must
+   pick among options that frequently only frustrate attackers --
+   preventing attacks entirely is potentially impossible.  Finally,
+   operators must prioritize and manage the most events possible.
+
+   Validating which alerts are true positives is challenging because
+   lots of weird traffic creates many anomalies, and not all anomalies
+   are malicious events.  Identifying which anomalous traffic is rooted
+   in malicious activity with any level of certainty is extremely
+   challenging.  Unfortunately, applying the latest machine-learning
+   techniques has produced mixed results.  To make matters worse, the
+   large amounts of Internet-wide scanning has resulted in endless
+   traffic that is technically malicious but only creates an information
+   overload and challenges event prioritization.  Any path forward must
+   free up analyst time to concentrate on the more challenging events.
+
+   The proposed contract solution is to define a collection of
+   acceptable behaviors that comprises different states that might
+   include IP addresses, domain names, and indicators of compromise.
+   Deviation from a contract might indicate that a system is acting
+   outside a normal mode of behavior or even 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 this
+   doesn't occur, then this expectation has not been met, and the system
+   should be checked as 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 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 increased encrypted traffic but is
+   also encrypting more and more of the metadata (e.g., DNS queries and
+   responses).  This makes network policy enforcement by middleboxes
+   significantly more challenging.  The result is a significant tension
+   between security enforcement and privacy protection.
+
+   Goals for solving this problem should include enabling networks to
+   enforce their policies, but should not include the weakening of
+   encryption nor the deployment of new server software.  Existing
+   solutions fail to meet at least one of these points.
+
+   A cryptographic principle of a "zero-knowledge proof" (ZKP) [GRUBBS]
+   may be one path forward to consider.  A ZKP allows a third party to
+   verify that a statement is true without revealing what the statement
+   actually is.  Applying this to network traffic has been shown to
+   allow a middlebox to 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 principle 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.).
+   Conversely, 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 ensuring
+   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 to resolve 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 as 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 in order to ensure
+   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
+
+   [BARNES]   Barnes, R., "What's In It For Me? Revisiting the reasons
+              people collaborate", August 2022, <https://www.iab.org/wp-
+              content/IAB-uploads/2023/11/Barnes-Whats-In-It-For-Me-
+              Revisiting-the-reasons-people-collaborate.pdf>.
+
+   [CASAS]    Casas, P., "Monitoring User-Perceived Quality in an
+              Encrypted Internet - AI to the Rescue", August 2022,
+              <https://www.iab.org/wp-content/IAB-uploads/2023/11/Casas-
+              AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf>.
+
+   [COLLINS]  Collins, M., "Improving Network Monitoring Through
+              Contracts", August 2022, <https://www.iab.org/wp-content/
+              IAB-uploads/2023/11/Collins-Improving-Network-Monitoring-
+              Through-Contracts.pdf>.
+
+   [DERI]     Deri, L., "nDPI Research Proposal", August 2022,
+              <https://www.iab.org/wp-content/IAB-uploads/2023/11/Deri-
+              nDPI-Research-Proposal.pdf>.
+
+   [DITTO]    Meier, R., Lenders, V., and L. Vanbever, "ditto: WAN
+              Traffic Obfuscation at Line Rate", Network and Distributed
+              Systems Security (NDSS) Symposium,
+              DOI 10.14722/ndss.2022.24056, April 2022,
+              <https://doi.org/10.14722/ndss.2022.24056>.
+
+   [ELKINS]   Elkins, N., Ackermann, M., Tahiliani, M., Dhody, D., and
+              T. Pecorella, "Performance Monitoring in Encrypted
+              Networks: PDMv2", August 2022, <https://www.iab.org/wp-
+              content/IAB-uploads/2023/11/Elkins-Performance-Monitoring-
+              in-Encrypted-Networks-PDMv2.pdf>.
+
+   [GRUBBS]   Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M.
+              Walfish, "Zero-Knowledge Middleboxes", 31st USENIX
+              Security Symposium (USENIX Security 22), August 2022,
+              <https://www.usenix.org/conference/usenixsecurity22/
+              presentation/grubbs>.
+
+   [HARDAKER] Hardaker, W., "Network Flow Management by Probability",
+              August 2022, <https://www.iab.org/wp-content/IAB-
+              uploads/2023/11/Hardaker-Encrypted-Traffic-
+              Estimation.pdf>.
+
+   [JIANG]    Jiang, X., Liu, S., Naama, S., Bronzino, F., Schmitt, P.,
+              and N. Feamster, "Towards Designing Robust and Efficient
+              Classifiers for Encrypted Traffic in the Modern Internet",
+              August 2022, <https://www.iab.org/wp-content/IAB-
+              uploads/2023/11/Jiang-Towards-Designing-Robust-and-
+              Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-
+              Internet.pdf>.
+
+   [KNODEL]   Knodel, M., "(Introduction) 'Guidelines for Performing
+              Safe Measurement on the Internet'", August 2022,
+              <https://www.iab.org/wp-content/IAB-uploads/2023/11/
+              Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-
+              Internet.pdf>.
+
+   [KUEHLEWIND]
+              Kuehlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
+              "Relying on Relays: The future of secure communication",
+              June 2022, <https://www.ericsson.com/en/blog/2022/6/
+              relays-and-online-user-privacy>.
+
+   [LEARMONTH]
+              Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines
+              for Performing Safe Measurement on the Internet", Work in
+              Progress, Internet-Draft, draft-irtf-pearg-safe-internet-
+              measurement-09, 12 January 2024,
+              <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
+              safe-internet-measurement-09>.
+
+   [LEI]      Lei, Y., Wu, J., Sun, X., Zhang, L., and Q. Wu, "Encrypted
+              Traffic Classification Through Deep Learning", August
+              2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
+              Lei-Encrypted-Traffic-Classification-Through-Deep-
+              Learning.pdf>.
+
+   [PAULY]    Pauly, T. and R. Barnes, "Red Rover: A collaborative
+              approach to content filtering", August 2022,
+              <https://www.iab.org/wp-content/IAB-uploads/2023/11/Pauly-
+              Red-Rover-A-collaborative-approach-to-content-
+              filtering.pdf>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
+              Description Specification", RFC 8520,
+              DOI 10.17487/RFC8520, March 2019,
+              <https://www.rfc-editor.org/info/rfc8520>.
+
+   [WELZL]    Welzl, M., "The Sidecar: 'Opting in' to PEP Functions",
+              August 2022, <https://www.iab.org/wp-content/IAB-
+              uploads/2023/11/Welzl-The-Sidecar-Opting-in-to-PEP-
+              Functions.pdf>.
+
+   [WU]       Wu, Q., Wu, J., and Q. Ma, "Network Management of
+              Encrypted Traffic: Detect it don't decrypt it", August
+              2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
+              Wu-mten-taxonomy.pdf>.
+
+Appendix A.  Position Papers
+
+   Interested participants were openly invited to submit position papers
+   on the workshop topics, including Internet-Drafts, relevant academic
+   papers, or short abstracts explaining their interest.  The papers
+   below constitute the inputs that were considered relevant for
+   workshop attendees and that focused the discussions themselves.  The
+   program committee grouped the papers by theme.
+
+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 workshop participants were 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.
+
+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), Qin Wu (IAB, Huawei).
+
+IAB Members at the Time of Approval
+
+   Internet Architecture Board members at the time this document was
+   approved for publication were:
+
+      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.
+
+Authors' Addresses
+
+   Mallory Knodel
+   Email: mknodel@cdt.org
+
+
+   Wes Hardaker
+   Email: ietf@hardakers.net
+
+
+   Tommy Pauly
+   Email: tpauly@apple.com