rfc9490.original   rfc9490.txt 
Network Working Group M. Knodel Internet Architecture Board (IAB) M. Knodel
Internet-Draft Center for Democracy & Technology Request for Comments: 9490
Intended status: Informational W. Hardaker Category: Informational W. Hardaker
Expires: 15 February 2024 ISSN: 2070-1721
T. Pauly T. Pauly
14 August 2023 January 2024
Report from the IAB workshop on Management Techniques in Encrypted Report from the IAB Workshop on Management Techniques in Encrypted
Networks (M-TEN) Networks (M-TEN)
draft-iab-m-ten-workshop-02
Abstract Abstract
The “Management Techniques in Encrypted Networks (M-TEN)” workshop The "Management Techniques in Encrypted Networks (M-TEN)" workshop
was convened by the Internet Architecture Board (IAB) from 17 October was convened by the Internet Architecture Board (IAB) from 17 October
2022 to 19 October 2022 as a three-day online meeting. The workshop 2022 to 19 October 2022 as a three-day online meeting. The workshop
was organized in three parts to discuss ways to improve network was organized in three parts to discuss ways to improve network
management techniques in support of even broader adoption of management techniques in support of even broader adoption of
encryption on the Internet. This report summarizes the workshop's encryption on the Internet. This report summarizes the workshop's
discussion and identifies topics that warrant future work and discussion and identifies topics that warrant future work and
consideration. consideration.
Note that this document is a report on the proceedings of the Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are workshop. The views and positions documented in this report are
those of the expressed during the workshop by participants and do not those of the expressed during the workshop by participants and do not
necessarily reflect IAB views and positions. necessarily reflect IAB views and positions.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://intarchboard.github.io/m-ten-workshop-public/draft-iab-m-ten-
workshop.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-iab-m-ten-workshop/.
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/m-ten-workshop-public.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 15 February 2024. 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 Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. About this workshop report content . . . . . . . . . . . 3 1.1. About This Workshop Report Content
2. Workshop Scope and Discussion . . . . . . . . . . . . . . . . 4 2. Workshop Scope and Discussion
2.1. “Where we are” - Requirements and Passive Observations . 4 2.1. "Where We Are" - Requirements and Passive Observations
2.1.1. Traffic classification and network management . . . . 4 2.1.1. Traffic Classification and Network Management
2.1.2. Preventing traffic analysis . . . . . . . . . . . . . 5 2.1.2. Preventing Traffic Analysis
2.1.3. Users and privacy . . . . . . . . . . . . . . . . . . 6 2.1.3. Users and Privacy
2.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Discussion
2.2. “Where we want to go” - Collaboration Principles . . . . 7 2.2. "Where We Want to Go" - Collaboration Principles
2.2.1. First party collaboration for network management . . 7 2.2.1. First-Party Collaboration for Network Management
2.2.2. Second and third party collaboration for network 2.2.2. Second- and Third-Party Collaboration for Network
management . . . . . . . . . . . . . . . . . . . . . 8 Management
2.2.3. Visible, optional network management . . . . . . . . 9 2.2.3. Visible, Optional Network Management
2.2.4. Discussion . . . . . . . . . . . . . . . . . . . . . 9 2.2.4. Discussion
2.3. “How we get there” - Collaboration Use cases . . . . . . 10 2.3. "How We Get There" - Collaboration Use Cases
2.3.1. Establishing expected contracts to enable security 2.3.1. Establishing Expected Contracts to Enable Security
management . . . . . . . . . . . . . . . . . . . . . 10 Management
2.3.2. Zero Knowledge Middleboxes . . . . . . . . . . . . . 11 2.3.2. Zero-Knowledge Middleboxes
2.3.3. Red Rover - A collaborative approach to content 2.3.3. Red Rover - a Collaborative Approach to Content
filtering . . . . . . . . . . . . . . . . . . . . . . 12 Filtering
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Conclusions
4. Informative References . . . . . . . . . . . . . . . . . . . 13 4. Informative References
Appendix A. Position Papers . . . . . . . . . . . . . . . . . . 15 Appendix A. Position Papers
A.1. Motivations and principles . . . . . . . . . . . . . . . 15 A.1. Motivations and Principles
A.2. Classification and identification of encrypted traffic . 16 A.2. Classification and Identification of Encrypted Traffic
A.3. Ideas for collaboration and coordination between devices A.3. Ideas for Collaboration and Coordination between Devices
and networks . . . . . . . . . . . . . . . . . . . . . . 16 and Networks
A.4. Other background material . . . . . . . . . . . . . . . . 16 A.4. Other Background Material
Appendix B. Workshop participants . . . . . . . . . . . . . . . 16 Appendix B. Workshop Participants
Appendix C. Program Committee . . . . . . . . . . . . . . . . . 17 Appendix C. Program Committee
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 IAB Members at the Time of Approval
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments
Authors' Addresses
1. Introduction 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 User privacy and security are constantly being improved by
increasingly strong and more widely deployed encryption. This increasingly strong and more widely deployed encryption. This
workshop aims to discuss ways to improve network management workshop aims to discuss ways to improve network management
techniques in support of even broader adoption of encryption on the techniques in support of even broader adoption of encryption on the
Internet. Internet.
Network management techniques need to evolve to work effectively and Network management techniques need to evolve to work effectively and
reliably in the presence of ubiquitous traffic encryption and support reliably in the presence of ubiquitous traffic encryption and to
techniques that enhance user privacy. In an all-encrypted network, support user privacy. In an all-encrypted network, it is not viable
it is not viable to rely on unencrypted metadata for network to rely on unencrypted metadata for network monitoring and security
monitoring and security functions, troubleshooting devices, and functions, troubleshooting devices, and passive traffic measurements.
passive traffic measurements. New approaches are needed to track New approaches are needed to track network behaviors, e.g., by
network behaviors, e.g., by directly cooperating with endpoints and directly cooperating with endpoints and applications, increasing use
applications, increasing use of in-band telemetry, increasing use of of in-band telemetry, increasing use of active measurement
active measurement approaches, and privacy-preserving inference approaches, and privacy-preserving inference techniques.
techniques.
The aim of this IAB online workshop from October 17-19, 2022, has The aim of this IAB online workshop from October 17-19, 2022, has
been to provide a platform to explore the interaction between network been to provide a platform to explore the interaction between network
management and traffic encryption and initiate new work on management and traffic encryption and to initiate work on
collaborative approaches that promote security and user privacy while collaborative approaches that promote security and user privacy while
supporting operational requirements. As such the workshop addressed supporting operational requirements. As such, the workshop addressed
the following questions: the following questions:
* What are actionable network management requirements? * What are actionable network management requirements?
* Who is willing to work on collaborative solutions? * Who is willing to work on collaborative solutions?
* What are the starting points for collaborative solutions? * What are the starting points for collaborative solutions?
1.1. About this workshop report content 1.1. About This Workshop Report Content
This document is a report on the proceedings of the workshop. The This document is a report on the proceedings of the workshop. The
views and positions documented in this report are those of the views and positions documented in this report are those of the
expressed during the workshop by participants and do not necessarily workshop participants and do not necessarily reflect IAB views and
reflect IAB views and positions. positions.
Furthermore, the content of the report comes from presentations given Furthermore, the content of the report comes from presentations given
by workshop participants and notes taken during the discussions, by workshop participants and notes taken during the discussions,
without interpretation or validation. Thus, the content of this without interpretation or validation. Thus, the content of this
report follows the flow and dialog of the workshop but does not report follows the flow and dialog of the workshop but does not
attempt to capture a consensus. attempt to capture a consensus.
2. Workshop Scope and Discussion 2. Workshop Scope and Discussion
The workshop was organized across three days with all-group The workshop was held across three days with all-group discussion
discussion slots, one per day. The following topic areas were slots, one per day. The following topic areas were identified, and
identified and the program committee organized paper submissions into the program committee organized paper submissions into three main
three main themes for each of the three discussion slots. During themes for each of the three discussion slots. During each
each discussion, those papers were presented sequentially with open discussion, those papers were presented sequentially with open
discussion held at the end of each day. discussion held at the end of each day.
2.1. “Where we are” - Requirements and Passive Observations 2.1. "Where We Are" - Requirements and Passive Observations
The first day of the workshop agenda focused on the existing state of The first day of the workshop focused on the existing state of the
the relationship between network management and encrypted traffic relationship between network management and encrypted traffic from
from various angles. Presentations ranged from discussing various angles. Presentations ranged from discussing classifiers
classifiers using machine-learning to recognize traffic, to advanced using machine learning to recognize traffic, to advanced techniques
techniques for evading traffic analysis, to user privacy for evading traffic analysis, to user privacy considerations.
considerations.
After an introduction that covered the goals of the workshop and the After an introduction that covered the goals of the workshop and the
starting questions (as described in Section 1), there were four starting questions (as described in Section 1), there were four
presentations, followed by open discussion. presentations followed by open discussion.
2.1.1. Traffic classification and network management 2.1.1. Traffic Classification and Network Management
Many existing network management techiques are passive in nature: Many existing network management techniques are passive in nature:
they don't rely on an explicit signals from end hosts to negotiate they don't rely on explicit signals from end hosts to negotiate with
with network middleboxes, but instead rely on inspecting packets to network middleboxes but instead rely on inspecting packets to
recognize traffic and apply various policies. Traffic recognize traffic and apply various policies. Traffic
classification, as a passive technique, is being challenged by classification, as a passive technique, is being challenged by
increasing encryption. increasing encryption.
Traffic classification is commonly performed by networks to infer Traffic classification is commonly performed by networks to infer
what applications and services are being used. This information is what applications and services are being used. This information is
in turn used for capacity and resource planning, Quality-of-Service in turn used for capacity and resource planning, Quality-of-Service
(QoS) monitoring, traffic prioritization, network access control, (QoS) monitoring, traffic prioritization, network access control,
identity management, and malware detection. However, since identity management, and malware detection. However, since
classification traditionally relies on recognizing unencrypted classification commonly relies on recognizing unencrypted properties
properties of packets in a flow, increasing encryption of traffic can of packets in a flow, increasing encryption of traffic can decrease
decrease the effectiveness of classification. the effectiveness of classification.
The amount of classification that can be performed on traffic also The amount of classification that can be performed on traffic also
provides a useful insight onto how "leaky" the protocols used by provides useful insight into how "leaky" the protocols used by
applications are, and points to areas where information is visible to applications are and points to areas where information is visible to
any observer, which may be malicious or not. any observer, who may or may not be malicious.
Traditionally, classification has been based on experts crafting Frequently, classification has been based on specific rules crafted
specific rules, but there is also a move toward using maching by experts, but there is also a move toward using machine learning to
learning to recognize patterns. "Deep learning" machine learning recognize patterns. "Deep learning" machine-learning models
models generally rely on analyzing a large set of traffic over time, generally rely on analyzing a large set of traffic over time and have
and have trouble reacting quickly to changes in traffic patterns. trouble reacting quickly to changes in traffic patterns.
Models that are based on closed-world data sets also become less Models that are based on closed-world data sets also become less
useful over time, as traffic changes. [JIANG] describes experiments useful over time as traffic changes. [JIANG] describes experiments
that showed that a model that performs with high accuracy on an that show that a model that performed with high accuracy on an
initial data set became severely degraded when running on a newer initial data set becomes severely degraded when running on a newer
data set that contained traffic from the same applications. Even in data set that contains traffic from the same applications. Even in
as little time as one week, the traffic classification would become as little time as one week, the traffic classification would become
degraded. However, the set of features in packets and flows that degraded. However, the set of features in packets and flows that
were useful for models stayed mostly consistent, even if the models were useful for models stayed mostly consistent, even if the models
themselves needed to be updated. Models where the feature space is themselves needed to be updated. Models where the feature space is
reduced to fewer features showed better resiliency, and could be reduced to fewer features showed better resiliency and could be
retrained more quickly. Based on this, [JIANG] recommends more work retrained more quickly. Based on this, [JIANG] recommends more work
and research on determining which set of features in IP packets are and research to determine which set of features in IP packets are
most useful for focused machine learning analysis. [WU] also most useful for focused machine-learning analysis. [WU] also
recommends further research investment in Artificial Intelligent (AI) recommends further research investment in Artificial Intelligence
analysis for network management. (AI) analysis for network management.
2.1.2. Preventing traffic analysis 2.1.2. Preventing Traffic Analysis
Just as traffic classification is continually adapting, techniques to Just as traffic classification is continually adapting, techniques to
prevent traffic analysis and obfuscate application and user traffic prevent traffic analysis and to obfuscate application and user
are continually evolving. An invited talk from the authors of traffic are continually evolving. An invited talk from the authors
[DITTO] shared a novel approach with the workshop for how to build a of [DITTO] shared a novel approach with the workshop for how to build
very robust system to prevent unwanted traffic analysis. a very robust system to prevent unwanted traffic analysis.
Usually traffic obfuscation is performed by changing the timing of Usually traffic obfuscation is performed by changing the timing of
packets or adding padding data. The practices can be costly and packets or by adding padding to data. The practices can be costly
negatively impact performance. DITTO demonstrated the feasibility of and negatively impact performance. [DITTO] demonstrated the
applying traffic obfuscation on aggregated traffic in the network feasibility of applying traffic obfuscation on aggregated traffic in
with minimal overhead and in line speed. the network with minimal overhead and inline speed.
While traffic obfuscation techniques are today not widely deployed, While traffic obfuscation techniques are not widely deployed today,
this study underlines, together with the need for continuous effort this study underlines the need for continuous effort to keep traffic
to keep traffic models updated over time, the challenges of models updated over time, the challenges of the classification of
classification of encrypted traffic as well as opportunities to encrypted traffic, as well as the opportunities to further enhance
further enhance user privacy. user privacy.
2.1.3. Users and privacy 2.1.3. Users and Privacy
The Privacy Enhancements and Assessments Research Group is working on The Privacy Enhancements and Assessments Research Group (PEARG) is
a document to discuss guidelines for how to measure traffic on the working on a document to discuss guidelines for measuring traffic on
Internet in a safe and privacy-friendly way the Internet in a safe and privacy-friendly way [LEARMONTH]. These
([I-D.irtf-pearg-safe-internet-measurement]). These guidelines and guidelines and principles provide another view on the discussion of
principles provide another angle onto the discussion of passive passive classification and analysis of traffic.
classification and analysis of traffic.
Consent for collection and measurement of metadata is an important Consent for collection and measurement of metadata is an important
consideration in deploying network measurement techniques. This consideration in deploying network measurement techniques. This
consent can be explicitly given as informed consent, or can be given consent can be given explicitly as informed consent, given by proxy,
by proxy or be only implied. For example, a user of a network might or may be only implied. For example, a user of a network might need
need to consent to certain measurement and traffic treatment when to consent to certain measurement and traffic treatment when joining
joining a network. a network.
Various techniques for data collection can also improve user privacy, Various techniques for data collection can also improve user privacy,
such as discarding data after a short period of time, masking out such as discarding data after a short period of time, masking aspects
aspects of data that contain user-identifying information, reducing of data that contain user-identifying information, reducing the
the accuracy of collected data, and aggregating data. accuracy of collected data, and aggregating data.
2.1.4. Discussion 2.1.4. Discussion
The intents and goals of users, application developers, and network The intents and goals of users, application developers, and network
operators align in some cases, but not others. One of the recurring operators align in some cases, but not in others. One of the
challenges that came up was not having a clear way to understand or recurring challenges that was discussed was the lack of a clear way
communicate intents and requirements. Both traffic classification to understand or to communicate intents and requirements. Both
and traffic obfuscation attempt to change the visibility of traffic traffic classification and traffic obfuscation attempt to change the
without cooperation of other parties: traffic classification is a visibility of traffic without cooperation of other parties: traffic
network attempting to inspect application traffic without classification is an attempt by the network to inspect application
coordination from applications, and traffic obfuscation is an attempt traffic without coordination from applications, and traffic
to hide that same traffic as it transits a network. 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 Traffic adaptation and prioritization is one dimension in which the
incentives for cooperation seem most clear. Even if an application incentives for cooperation seem most clear. Even if an application
is trying to prevent leaking metadata, it could benefit from signals is trying to prevent the leaking of metadata, it could benefit from
from network about sudden capacity changes that can help it adapt its signals from the network about sudden capacity changes that can help
application quality, such as bitrates and codecs. Such signalling it adapt its application quality, such as bitrates and codecs. Such
may not be appropriate for the most privacy-sensitive applications, signaling may not be appropriate for the most privacy-sensitive
like Tor, but could be applicable for many others. There are applications, like Tor, but could be applicable for many others.
existing protocols that involve explicit signaling between There are existing protocols that involve explicit signaling between
applications and networks, such as Explicit Congestion Notification applications and networks, such as Explicit Congestion Notification
(ECN) [RFC3168], but that has yet to see wide adoption. (ECN) [RFC3168], but that has yet to see wide adoption.
Managed networks (such a private corporate networks) was brought up Managed networks (such as private corporate networks) were brought up
in several comments as a particularly challenging area for being able in several comments as particularly challenging for meeting
to meet management requirements while maintaining encryption and management requirements while maintaining encryption and privacy.
privacy. These networks can have legal and regulated requirements These networks can have legal and regulated requirements for
for detection of specific fraudulent or malicious traffic. detection of specific fraudulent or malicious traffic.
Personal networks that enable managed parental controls have similar Personal networks that enable managed parental controls have similar
complications with encrypted traffic and user privacy. In these complications with encrypted traffic and user privacy. In these
scenarios, the parental controls being operated by the network may be scenarios, the parental controls that are operated by the network may
as simple as a DNS filter, and can be made ineffective by a device be as simple as a DNS filter, which can be made ineffective by a
routing traffic to an alternate DNS resolver. device routing traffic to an alternate DNS resolver.
2.2. “Where we want to go” - Collaboration Principles 2.2. "Where We Want to Go" - Collaboration Principles
The second day of the workshop agenda focused on the emerging The second day of the workshop focused on the emerging techniques for
techniques for analysing, managing or monitoring encrypted traffic. analyzing, managing, or monitoring encrypted traffic. Presentations
Presentations ranged from discussing advanced classification and covered advanced classification and identification, including
identification, including machine-learning techniques, for the machine-learning techniques, for the purposes of managing network
purposes of manging network flows, monitoring or monetising usage. flows or monitoring or monetizing usage.
After an introduction that covered the goals of the workshop and the After an introduction that covered the goals of the workshop and the
starting questions (as described in Section 1), there were three starting questions (as described in Section 1), there were three
presentations, followed by open discussion. presentations, followed by open discussion.
2.2.1. First party collaboration for network management 2.2.1. First-Party Collaboration for Network Management
It is the intention of encryption to create a barrier between It is the intent of end-to-end encryption of traffic to create a
entities inside the communication channel and everyone else, barrier between entities inside the communication channel and
including network operators, considering end-to-end encryption of everyone else, including network operators. Therefore, any attempt
traffic. Any attempt, therefore, to overcome that intentional to overcome that intentional barrier requires collaboration between
barrier requires an intent to collaborate between the inside and the inside and outside entities. At a minimum, those entities must
outside entities. Those entities must, at a minimum, agree on the agree on the benefits of overcoming the barrier (or solving the
benefits to overcoming the barrier (or solving the problem), that problem), agree that costs are proportional to the benefits, and
costs are proportional to the benefits, and to additional agree to additional limitations or safeguards against bad behavior by
limitations, or safeguards, against bad behaviour by collaborators collaborators including other non-insiders [BARNES].
including the inclusion of other non-insiders [BARNES].
The Internet is designed interoperably, which means an outside entity The Internet is designed interoperably, which means an outside entity
wishing to collaborate with the inside might be any number of wishing to collaborate with the inside might be any number of
intermediaries and not, say, a specific person that can be trusted in intermediaries and not, say, a specific person that can be trusted in
the human sense. Additionally the use of encryption, especially the human sense. Additionally, the use of encryption, especially
network-layer or transport-layer encryption, introduces dynamic or network-layer or transport-layer encryption, introduces dynamic or
opportunitistic or perfunctory discoverability. These realities both opportunistic or perfunctory discoverability. These realities point
point to a need to interrogate the reason why any outside entity to a need to ask why an outside entity might make an engineering case
might make an engineering case to collaborate with the user of a to collaborate with the user of a network with encrypted traffic and
network with encrypted traffic, and whether the tradeoffs and to ask whether the trade-offs and potential risks are worth it to the
potential risks are worth it to the user. user.
However, the answers cannot be specific and the determinations or However, the answers cannot be specific, and the determinations or
guidance need to be general as the encryption boundary is inevitably guidance need to be general as the encryption boundary is inevitably
an application used by many people. Tradeoffs must make sense to an application used by many people. Trade-offs must make sense to
users who are unlikely to be thinking about network management users who are unlikely to be thinking about network management
considerations. Harms need to be preemptively reduced because in considerations. Harms need to be preemptively reduced because, in
general terms few users would choose network management benefits over general terms, few users would choose network management benefits
their own privacy if given the choice. over their own privacy if given the choice.
Some have found that there appears to be little if any actual Some have found that there appears to be little, if any, evidence
evidence that encryption is causing user-meaningful network problems. that encryption causes network problems that are meaningful to the
Since alignment on problem-solving is a prerequisite to collaboration user. Since alignment on problem solving is a prerequisite to
on a solution it does not seem that collaboration across the collaboration on a solution, it does not seem that collaboration
encryption boundary is called for. across the encryption boundary is called for.
2.2.2. Second and third party collaboration for network management 2.2.2. Second- and Third-Party Collaboration for Network Management
Even with the wide-scale deployment of encryption in new protocols Even with the wide-scale deployment of encryption in new protocols
and techniques that prevent passive observers of network traffic from and of techniques that prevent passive observers of network traffic
knowing the content of exchanged communications, important from knowing the content of exchanged communications, important
information such as which parties communicate and sometimes even information, such as which parties communicate and sometimes even
which services have been requested may still be able to be deduced. which services have been requested, may still be able to be deduced.
The future is to conceal more data and metadata from passive The future is to conceal more data and metadata from passive
observers and also to minimize information exposure to second parties observers and also to minimize information exposure to second parties
(where the user is the first party) by, maybe counterintuitively, (where the user is the first party) by, maybe counterintuitively,
introducing third-party relay services to intermediate introducing third-party relay services to intermediate
communications. As discussed in [KUEHLEWIND], the relay is a communications. As discussed in [KUEHLEWIND], the relay is a
mechanism to separate (using additional levels of encryption) two mechanism that uses additional levels of encryption to separate two
important pieces of information: knowledge of the identity of the important pieces of information: knowledge of the identity of the
person accessing a service is separated from knowledge about the person accessing a service is separated from knowledge about the
service being accessed. By contrast a VPN uses only one level of service being accessed. By contrast, a VPN uses only one level of
encryption and does not separate identity (first party) and service encryption and does not separate identity (first party) and service
(second party) metadata. (second party) metadata.
Relay mechanisms are termed "oblivious", there is a future for Relay mechanisms are termed "oblivious", there is a future for
specifications in privacy-preserving measurement (PPM), and protocols specifications in privacy-preserving measurement (PPM), and protocols
like Multiplexed Application Substrate over QUIC Encryption (MASQUE) like Multiplexed Application Substrate over QUIC Encryption (MASQUE)
are discussed in the IETF. In various schemes, users are ideally are discussed in the IETF. In various schemes, users are ideally
able to share their identity only with the entity they have able to share their identity only with the entity they have
identified as a trusted one. That data is not shared with the identified as a trusted one. That data is not shared with the
service provider. However this is more complicated for network service provider. However, this is more complicated for network
management, but there may be opportunities for better collaboration management, but there may be opportunities for better collaboration
between the network and, say, the application or service at the between the network and, say, the application or service at the
endpoint. endpoint.
A queriable relay mechanism could preserve network management A queriable relay mechanism could preserve network management
functions that are disrupted by encryption, such as TCP optimisation, functions that are disrupted by encryption, such as TCP optimization,
quality of service, zero-rating, parental controls, access control, quality of service, zero-rating, parental controls, access control,
redirection, content enhancement, analytics and fraud prevention. redirection, content enhancement, analytics, and fraud prevention.
Instead of encrypting communication between only two ends with
Instead of encrypted communication between only two ends and passive passive observation by all on-path elements, intermediate relays
observation by all on-path elements, intermediate relays could be could be introduced as trusted parties that get to see limited
trusted parties with limited information for the purposes of information for the purpose of collaboration between in-network
collaboration between in-network intermediary services' support. intermediary services.
2.2.3. Visible, optional network management 2.2.3. Visible, Optional Network Management
In encrypted communications, out of all of the possible network Out of all of the possible network management functions that might be
management functions that might be ameliorated by proxying, the ameliorated by proxying, the ability to control congestion in
ability to control congestion has been researched in depth. These encrypted communications has been researched in depth. These
techniques are realized based on TCP performance enhancing proxies techniques are realized based on TCP performance-enhancing proxies
(PEP) that either entirely intercept a TCP connection or interfere (PEPs) that either entirely intercept a TCP connection or interfere
with the transport information in the TCP header. However, despite with the transport information in the TCP header. However, despite
the challenge that the new encrypted protocol will limit any such in- the challenge that the new encrypted protocol will limit any such in-
network interference, these techniques can also have a negative network interference, these techniques can also have a negative
impact on the evolvability of these protocols. Therefore, instead of impact on the evolvability of these protocols. Therefore, a new
manipulating existing information, a new approach was presented where approach was presented where, instead of manipulating existing
additional information is send using a so-called side-car protocol information, additional information is sent using a so-called sidecar
independent of the main transport protocol that is used end-to-end protocol independent of the main transport protocol that is used end
[WELZL]. E.g. side car information can contain additional to end [WELZL]. For example, sidecar information can contain
acknowledgements to enable in-network local retransmission faster additional acknowledgments to enable in-network local retransmission
end-to-end retransmission by reducing the signaling round trip time. or faster end-to-end retransmission by reducing the signaling round-
trip time.
Taking user privacy benefits for granted, there is a need to Taking user privacy benefits for granted, there is a need to
investigate the comparable performance outputs of various encrypted investigate the comparable performance outputs of various encrypted
traffic configurations such as use of an additional "side-car" traffic configurations such as the use of an additional sidecar
protocol, or explicit encrypted and trusted network communication protocol, or explicit encrypted and trusted network communication
using MASQUE in relation to existing techniques such as TCP using MASQUE in relation to existing techniques such as TCP PEPs,
performance enhancing proxies (PEP), etc. etc.
2.2.4. Discussion 2.2.4. Discussion
One size fits all? On the issue of trust, different networks or One size fits all? On the issue of trust, different networks or
devices are going to have different requirements for the level of devices will have different trust requirements for devices, users, or
trust that they have in devices, users or each other, and vice versa. each other, and vice versa. For example, imagine two networks with
For example, imagine networks with really different security really different security requirements, like a home network with a
requirements, like protecting children in a home versus a national requirement to protect its child users versus a national security
security institution. How could one network architecture solve the institution's network. How could one network architecture solve the
needs of all use cases? needs of all use cases?
Does our destination have consequences? It seems sometimes that Does our destination have consequences? It seems sometimes that
there may be consequences many years down the line of ubiquitous, there may be future consequences caused by the ubiquitous, strong
strong encryption of network traffic because it will cause a reaction encryption of network traffic because it will cause intermediaries to
by intermediaries to find ways to poke holes in what are supposed to poke holes in what are supposed to be long-term solutions for user
be long-term solutions for user privacy and security. privacy and security.
Can we bring the user along? While there has been a focus on the Can we bring the user along? While there has been a focus on the
good reasons for why people might collaborate across the encryption good reasons why people might collaborate across the encryption
barrier, there will always be others who want to disrupt that because barrier, there will always be others who want to disrupt that in
they are motivated to exploit the data for their own gain, and order to exploit the data for their own gain, and sometimes
sometimes this is called innovation. What high-level policy exploitation is called innovation. High-level policy mitigations
mitigations have done is to expose how powerless end users are to have exposed how powerless end users are against corporate practices
corporate practices of data harvesting. And yet interfaces to help of data harvesting. And yet interfaces to help users understand
users understand these lower layer traffic flows to protect their these lower-layer traffic flows to protect their financial
financial transactions or privacy haven't been achieved yet. That transactions or privacy haven't been achieved yet. That means that
means that engineers are having to make inferences about what users engineers must make inferences about user wants. Instead, we should
want. Instead we should be making these relationships and tradeoffs make these relationships and trade-offs more visible.
more visible.
2.3. “How we get there” - Collaboration Use cases 2.3. "How We Get There" - Collaboration Use Cases
The third day focused on techniques that could actually be used to The third day focused on techniques that could be used to improve the
improve management of encrypted networks. A central theme of all of management of encrypted networks.
the presentations about potential proposed paths forward included The potential paths forward described in the presentations included
some element of collaboration between networks and subscribing some element of collaboration between the networks and the
clients that simultaneously want both privacy and protection. Thus, subscribing clients that simultaneously want both privacy and
the central theme in the third day became negotiation and protection. Thus, the central theme of the third day became
collaboration. negotiation and collaboration.
2.3.1. Establishing expected contracts to enable security management 2.3.1. Establishing Expected Contracts to Enable Security Management
When thinking about enterprise networks where client behavior is For enterprise networks where client behavior is potentially managed,
potentially managed, [COLLINS] proposes "Improving network monitoring [COLLINS] proposes "Improving network monitoring through contracts",
through contracts", where contracts describe different states of where contracts describe different states of network behavior.
network behavior.
Because network operators have a limited amount of time to focus on Because network operators have a limited amount of time to focus on
problems and process alerts, contracts and states let the operator problems and process alerts, contracts and states let the operator
focus on a particular aspect of a current situation or problem. The focus on a particular aspect of a current situation or problem. The
current estimate for the number of events a Security Operations current estimate for the number of events a Security Operations
Center (SOC) operator can handle is about 10 per hour. Operators Center (SOC) operator can handle is about 10 per hour. Operators
must work within the limits imposed by their organization, and must must work within the limits imposed by their organization and must
pick between options that frequently only frustrate attackers -- pick among options that frequently only frustrate attackers --
entirely preventing attacks is potentially impossible. Finally, preventing attacks entirely is potentially impossible. Finally,
operators must prioritize and manage the most events possible. operators must prioritize and manage the most events possible.
Validating which alerts are true positives is challenging because Validating which alerts are true positives is challenging because
lots of weird traffic creates many anomalies and not all anomalies lots of weird traffic creates many anomalies, and not all anomalies
are malicious events. Identifying what anomalous traffic is rooted are malicious events. Identifying which anomalous traffic is rooted
in malicious activity with any level of certainty is extremely in malicious activity with any level of certainty is extremely
challenging. Unfortunately, applying the latest machine learning challenging. Unfortunately, applying the latest machine-learning
techniques has only produced mixed results. To make matters worse, techniques has produced mixed results. To make matters worse, the
the large amounts of Internet-wide scanning has resulted in endless large amounts of Internet-wide scanning has resulted in endless
traffic that is technically malicious but only creates an information traffic that is technically malicious but only creates an information
overload and challenges event prioritization. Any path forward must overload and challenges event prioritization. Any path forward must
succeed in freeing up analyst time to concentrate on the more free up analyst time to concentrate on the more challenging events.
challenging events.
The proposed contract solution is to define a collection of The proposed contract solution is to define a collection of
acceptable behaviors categorized into an envelope of different states acceptable behaviors that comprises different states that might
that might include IP addresses, domain names, and indicators of include IP addresses, domain names, and indicators of compromise.
compromise. Deviation from a contract might indicate that a system Deviation from a contract might indicate that a system is acting
is acting outside a normal mode of behavior, or even a normal mode of outside a normal mode of behavior or even that a normal mode of
behavior is suddenly missing. An example contract might be "this behavior is suddenly missing. An example contract might be "this
system is expected to update its base OS once a day", and if 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 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 should be checked as it failed to call home to look for (potentially
security related) updates. security-related) updates.
Within the IETF, the Manufacturer Usage Description Specification Within the IETF, the Manufacturer Usage Description Specification
(MUD) {?RFC8520} specification is one subset of contracts. Note that (MUD) [RFC8520] is one subset of contracts. Note that contracts are
contracts are likely to only succeed in a constrained, expected likely to succeed only in a constrained, expected environment
environment maintained by operational staff, and may not work in an maintained by operational staff and may not work in an open Internet
open internet environment where end users are driving all network environment where end users drive all network connections.
connections.
2.3.2. Zero Knowledge Middleboxes 2.3.2. Zero-Knowledge Middleboxes
The world is not only shifting to increased encrypted traffic but is 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 also encrypting more and more of the metadata (e.g., DNS queries and
responses). This makes network policy enforcement by middleboxes responses). This makes network policy enforcement by middleboxes
significantly more challenging. The result is the creation of a significantly more challenging. The result is a significant tension
significant tension between security enforcement and privacy between security enforcement and privacy protection.
protection.
A goal for solving this problem should include not weakening Goals for solving this problem should include enabling networks to
encryption, should enable networks to enforce their policies, and enforce their policies, but should not include the weakening of
should ideally not require newly deployed server software. Existing encryption nor the deployment of new server software. Existing
solutions fail with at least one of these points. solutions fail to meet at least one of these points.
A cryptographic principle of a "zero-knowledge proof" (ZKP) [GRUBBS] A cryptographic principle of a "zero-knowledge proof" (ZKP) [GRUBBS]
maybe one path forward to consider. A ZKP allows a third party to 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 verify that a statement is true without revealing what the statement
actually is. Applying this to network traffic has been shown to actually is. Applying this to network traffic has been shown to
allow a middlebox to verify that traffic to a web server is actually allow a middlebox to verify that traffic to a web server is compliant
compliant with a policy without revealing the actual contents. This with a policy without revealing the actual contents. This solution
solution meets the above three criteria. Using ZKP within TLS 1.3 meets the three criteria listed above. Using ZKP within TLS 1.3
traffic turns out to be plausible. traffic turns out to be plausible.
An example engine was built to test ZKP using encrypted DNS. Clients 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 were able to create DNS requests that were not listed within a DNS
block list. Middleboxes could verify, without knowing the exact block list. Middleboxes could verify, without knowing the exact
request, that the client's DNS request was not in the prohibited request, that the client's DNS request was not on the prohibited
list. Although the result was functional, the computational overhead list. Although the result was functional, the computational overhead
was still too slow and future work will be needed to decrease the ZKP was still too slow, and future work will be needed to decrease the
imposed latencies. ZKP-imposed latencies.
2.3.3. Red Rover - A collaborative approach to content filtering 2.3.3. Red Rover - a Collaborative Approach to Content Filtering
The principle challenge being studied is how to deal with the inherit The principle challenge being studied is how to handle the inherent
conflict between filtering and privacy. Network operators need to conflict between filtering and privacy. Network operators need to
implement policies and regulations that can originate from many implement policies and regulations that can originate from many
locations (e.g. security, governmental, parental, etc). Conversely, locations (e.g., security, governmental, parental, etc.).
clients need to protect user's privacy and user security. Conversely, clients need to protect their users' privacy and
security.
Safe browsing, originally created by Google, is one example of a Safe browsing, originally created by Google, is one example of a
mechanism that tries to meet both sides of this conflict. It would mechanism that tries to meet both sides of this conflict. It would
be beneficial to standardize this and other similar mechanisms. be beneficial to standardize this and other similar mechanisms.
Operating systems could continually protect their users by ensuring Operating systems could continually protect their users by ensuring
that malicious destinations are not being reached. This would that malicious destinations are not being reached. This would
require some coordination between cooperating clients and servers require some coordination between cooperating clients and servers
offering protection services. These collaborative solutions may be offering protection services. These collaborative solutions may be
the best compromise between the tension of privacy vs protection the best compromise to resolve the tension between privacy services
based services [PAULY]. and protection services [PAULY].
3. Conclusions 3. Conclusions
Looking forward, the workshop participants identified that solving Looking forward, the workshop participants identified that solving
the entire problem space with a single approach will be challenging the entire problem space with a single approach will be challenging
for several reasons: for several reasons:
* The scalability of many solutions will likely be an issue as some * The scalability of many solutions will likely be an issue as some
solutions are complex or expensive to implement. solutions are complex or expensive to implement.
* Collaboration between multiple parties will be required for many * Collaboration between multiple parties will be required for many
mechanisms to function, and the sets of parties required for mechanisms to function, and the sets of parties required for
different use cases might be disjoint. different use cases might be disjoint.
* There is an unanswered question of whether or not network * There is an unanswered question of whether or not network
operators be willing to participate and allow technologies into operators are willing to participate by allowing new encryption
their environment requirements in exchange for technologies that technologies into their environment in exchange for technologies
prove their clients are being good net-citizens. If so, some of that prove their clients are being good net-citizens. If so, some
these solutions might be required to exist before networks allow a of these solutions might be required to exist before networks
certain type of increased encryption; consider the example of TLS allow a certain type of increased encryption; consider the example
Encrypted Client Hello being blocked by some network operators. of TLS Encrypted Client Hello being blocked by some network
operators.
The breadth of the problem space itself is another complicating The breadth of the problem space itself is another complicating
factor. There is a wide variety of network architectures, and each factor. There is a wide variety of network architectures, and each
has different requirements for both data encryption and network has different requirements for both data encryption and network
management. Each problem space will have different encumbrances of management. Each problem space will have multiple, different
multiple types; for example, technical, legal, data ownership, and encumbrances: for example, technical, legal, data ownership, and
regulatory concerns. New network architectures might be needed to regulatory concerns. New network architectures might be needed to
solve this problem at a larger scope, which would in turn require solve this problem at a larger scope, which would in turn require
interoperability support from network product vendors. Education interoperability support from network product vendors. Education
about various solutions will be required in order to ensure about various solutions will be required in order to ensure
regulation and policy organizations can understand and thus support regulation and policy organizations can understand and thus support
the deployment of developed solutions. the deployment of developed solutions.
After new technologies and related standards are developed and After new technologies and related standards are developed and
deployed, unintended consequences can emerge that weren't considered deployed, unintended consequences can emerge. These lead to effects
during the design of the protocol. These lead to effects in multiple in multiple directions: on one hand, exposed protocol values not
directions: on one hand, exposed protocol values not intended for intended for network management might be used by networks to
network management might be used by networks to differentiate differentiate traffic; on the other hand, changes to a protocol that
traffic; on the other hand, changes to a protocol might have impact break existing use cases might have an impact on private network
on private network deployments that break existing use cases. While deployments. While making decisions on technology direction and
making decisions on technology direction and protocol design, it is protocol design, it is important to consider the impact on various
important to consider the impact on various kinds of network kinds of network deployments and their unique requirements. When
deployments and their unique requirements. When protocols change to protocols change to make different network management functions
make different network management functions easier or harder, the easier or harder, the impact on various deployment models ought to be
impact on various deployment models ought to be considered and considered and documented.
documented.
4. Informative References 4. Informative References
[BARNES] Barnes, R., "What’s In It For Me? Revisiting the reasons [BARNES] Barnes, R., "What's In It For Me? Revisiting the reasons
people collaborate", August 2022, people collaborate", August 2022, <https://www.iab.org/wp-
<https://github.com/intarchboard/m-ten- content/IAB-uploads/2023/11/Barnes-Whats-In-It-For-Me-
workshop/blob/main/papers/Barnes-Whats-In-It-For-Me-
Revisiting-the-reasons-people-collaborate.pdf>. Revisiting-the-reasons-people-collaborate.pdf>.
[CASAS] Casas, P., "Monitoring User-Perceived Quality in an [CASAS] Casas, P., "Monitoring User-Perceived Quality in an
Encrypted Internet", August 2022, Encrypted Internet - AI to the Rescue", August 2022,
<https://github.com/intarchboard/workshop-m- <https://www.iab.org/wp-content/IAB-uploads/2023/11/Casas-
ten/blob/main/papers/Casas-AI-driven-real-time-QoE- AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf>.
monitoring-encrypted-traffic.pdf>.
[COLLINS] Collins, M., "Improving Network Monitoring Through [COLLINS] Collins, M., "Improving Network Monitoring Through
Contracts", August 2022, <https://github.com/intarchboard/ Contracts", August 2022, <https://www.iab.org/wp-content/
workshop-m-ten/blob/main/papers/Collins-Improving-Network- IAB-uploads/2023/11/Collins-Improving-Network-Monitoring-
Monitoring-Through-Contracts.pdf>. Through-Contracts.pdf>.
[DERI] Deri, L., "nDPI Research Proposal", August 2022, [DERI] Deri, L., "nDPI Research Proposal", August 2022,
<https://github.com/intarchboard/workshop-m- <https://www.iab.org/wp-content/IAB-uploads/2023/11/Deri-
ten/blob/main/papers/Deri-nDPI-Research-Proposal.pdf>. nDPI-Research-Proposal.pdf>.
[DITTO] Meier, R., Lenders, V., and L. Vanbever, "Ditto - WAN [DITTO] Meier, R., Lenders, V., and L. Vanbever, "ditto: WAN
Traffic Obfuscation at Line Rate", April 2022, Traffic Obfuscation at Line Rate", Network and Distributed
<https://nsg.ee.ethz.ch/fileadmin/user_upload/ Systems Security (NDSS) Symposium,
publications/ditto_final_ndss22.pdf>. 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 [ELKINS] Elkins, N., Ackermann, M., Tahiliani, M., Dhody, D., and
T. Pecorella, "Performance Monitoring in Encrypted T. Pecorella, "Performance Monitoring in Encrypted
Networks", August 2022, <https://github.com/intarchboard/ Networks: PDMv2", August 2022, <https://www.iab.org/wp-
workshop-m-ten/blob/main/papers/Elkins-Performance- content/IAB-uploads/2023/11/Elkins-Performance-Monitoring-
Monitoring-in-Encrypted-Networks-PDMv2.pdf>. in-Encrypted-Networks-PDMv2.pdf>.
[GRUBBS] Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M. [GRUBBS] Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M.
Walfish, "Zero-Knowledge Middleboxes", August 2022, Walfish, "Zero-Knowledge Middleboxes", 31st USENIX
<https://github.com/intarchboard/workshop-m- Security Symposium (USENIX Security 22), August 2022,
ten/blob/main/papers/Grubbs-Zero- <https://www.usenix.org/conference/usenixsecurity22/
Knowledge%20Middleboxes.pdf>. presentation/grubbs>.
[I-D.irtf-pearg-safe-internet-measurement] [HARDAKER] Hardaker, W., "Network Flow Management by Probability",
Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines August 2022, <https://www.iab.org/wp-content/IAB-
for Performing Safe Measurement on the Internet", Work in uploads/2023/11/Hardaker-Encrypted-Traffic-
Progress, Internet-Draft, draft-irtf-pearg-safe-internet- Estimation.pdf>.
measurement-08, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
safe-internet-measurement-08>.
[JIANG] Jiang, X., Liu, S., Naama, S., Bronzino, F., Schmitt, P., [JIANG] Jiang, X., Liu, S., Naama, S., Bronzino, F., Schmitt, P.,
and N. Feamster, "Towards Designing Robust and Efficient and N. Feamster, "Towards Designing Robust and Efficient
Classifiers for Encrypted Traffic in the Modern Internet", Classifiers for Encrypted Traffic in the Modern Internet",
August 2022, <https://github.com/intarchboard/workshop-m- August 2022, <https://www.iab.org/wp-content/IAB-
ten/blob/main/papers/Jiang-Towards-Designing-Robust-and- uploads/2023/11/Jiang-Towards-Designing-Robust-and-
Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern- Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-
Internet.pdf>. Internet.pdf>.
[KNODEL] Knodel, M., "Guidelines for Performing Safe Measurement on [KNODEL] Knodel, M., "(Introduction) 'Guidelines for Performing
the Internet", August 2022, Safe Measurement on the Internet'", August 2022,
<https://github.com/intarchboard/workshop-m- <https://www.iab.org/wp-content/IAB-uploads/2023/11/
ten/blob/main/papers/Knodel-Guidelines-for-Performing- Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-
Safe-Measurement-on-the-Internet.pdf>. Internet.pdf>.
[KUEHLEWIND] [KUEHLEWIND]
Kühlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar, Kuehlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
"Relying on Relays", August 2022, "Relying on Relays: The future of secure communication",
<https://github.com/intarchboard/workshop-m- June 2022, <https://www.ericsson.com/en/blog/2022/6/
ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf>. 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-08, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
safe-internet-measurement-08>.
[LEI] Lei, Y., Wu, J., Sun, X., Zhang, L., and Q. Wu, "Encrypted [LEI] Lei, Y., Wu, J., Sun, X., Zhang, L., and Q. Wu, "Encrypted
Traffic Classification Through Deep Learning", August Traffic Classification Through Deep Learning", August
2022, <https://github.com/intarchboard/workshop-m- 2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
ten/blob/main/papers/Lei-Encrypted-Traffic-Classification- Lei-Encrypted-Traffic-Classification-Through-Deep-
Through-Deep-Learning.pdf>. Learning.pdf>.
[PAULY] Pauly, T. and R. Barnes, "Red Rover", August 2022, [PAULY] Pauly, T. and R. Barnes, "Red Rover: A collaborative
<https://github.com/intarchboard/workshop-m- approach to content filtering", August 2022,
ten/blob/main/papers/Pauly-Red-Rover-A-collaborative- <https://www.iab.org/wp-content/IAB-uploads/2023/11/Pauly-
approach-to-content-filtering.pdf>. Red-Rover-A-collaborative-approach-to-content-
filtering.pdf>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/rfc/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[WELZL] Welzl, M., "The Sidecar", August 2022, [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
<https://github.com/intarchboard/workshop-m- Description Specification", RFC 8520,
ten/blob/main/papers/Welzl-The-Sidecar-Opting-in-to-PEP- 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>. Functions.pdf>.
[WU] Wu, Q., Wu, J., and Q. Ma, "Network Management of [WU] Wu, Q., Wu, J., and Q. Ma, "Network Management of
Encrypted Traffic", August 2022, Encrypted Traffic: Detect it don't decrypt it", August
<https://github.com/intarchboard/workshop-m- 2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
ten/blob/main/papers/Wu-mten-taxonomy.pdf>. Wu-mten-taxonomy.pdf>.
Appendix A. Position Papers Appendix A. Position Papers
Interested participants were openly invited to submit position papers Interested participants were openly invited to submit position papers
on the workshop topics, including Internet-Drafts, relevant academic on the workshop topics, including Internet-Drafts, relevant academic
papers, or short abstracts explaining their interest. The papers papers, or short abstracts explaining their interest. The papers
below constitute the inputs that were considered relevant for below constitute the inputs that were considered relevant for
workshop attendees and that focused the discussions themselves. The workshop attendees and that focused the discussions themselves. The
program committee grouped the papers by theme as such. program committee grouped the papers by theme.
A.1. Motivations and principles A.1. Motivations and Principles
Richard Barnes. “What’s In It For Me? Revisiting the reasons people Richard Barnes. "What's In It For Me? Revisiting the reasons people
collaborate.” [BARNES] collaborate." [BARNES]
Iain R. Learmonth, Gurshabad Grover, Mallory Knodel. “Guidelines for Mallory Knodel. "(Introduction) 'Guidelines for Performing Safe
Performing Safe Measurement on the Internet.” (Additional rationale) Measurement on the Internet'." (Additional rationale) [KNODEL]
[KNODEL]
Qin Wu, Jun Wu, Qiufang Ma. “Network Management of Encrypted Traffic: Qin Wu, Jun Wu, Qiufang Ma. "Network Management of Encrypted
Detect it don’t decrypt it.” [WU] Traffic: Detect it don't decrypt it." [WU]
A.2. Classification and identification of encrypted traffic A.2. Classification and Identification of Encrypted Traffic
Luca Deri. “nDPI Research Proposal.” [DERI] Luca Deri. "nDPI Research Proposal." [DERI]
Wes Hardaker. “Network Flow Management by Probability.” Wes Hardaker. "Network Flow Management by Probability." [HARDAKER]
Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt, Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt,
Nick Feamster. “Towards Designing Robust and Efficient Classifiers Nick Feamster. "Towards Designing Robust and Efficient Classifiers
for Encrypted Traffic in the Modern Internet.” [JIANG] for Encrypted Traffic in the Modern Internet." [JIANG]
Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. “Encrypted Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. "Encrypted
Traffic Classification Through Deep Learning.” [LEI] Traffic Classification Through Deep Learning." [LEI]
A.3. Ideas for collaboration and coordination between devices and A.3. Ideas for Collaboration and Coordination between Devices and
networks Networks
Michael Collins. “Improving Network Monitoring Through Contracts.” Michael Collins. "Improving Network Monitoring Through Contracts."
[COLLINS] [COLLINS]
Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish.
“Zero-Knowledge Middleboxes.” [GRUBBS] "Zero-Knowledge Middleboxes." [GRUBBS]
Mirja Kühlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Mirja Kuehlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus
Ihlar. “Relying on Relays: The future of secure communication.” Ihlar. "Relying on Relays: The future of secure communication."
[KUEHLEWIND] [KUEHLEWIND]
Tommy Pauly, Richard Barnes. “Red Rover: A collaborative approach to Tommy Pauly, Richard Barnes. "Red Rover: A collaborative approach to
content filtering.” [PAULY] content filtering." [PAULY]
Michael Welzl. “The Sidecar: ‘Opting in’ to PEP Functions.“ [WELZL] Michael Welzl. "The Sidecar: 'Opting in' to PEP Functions." [WELZL]
A.4. Other background material A.4. Other Background Material
Pedro Casas. “Monitoring User-Perceived Quality in an Encrypted Pedro Casas. "Monitoring User-Perceived Quality in an Encrypted
Internet – AI to the Rescue.” [CASAS] Internet - AI to the Rescue." [CASAS]
Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody,
Prof. Tommaso Pecorella. “Performance Monitoring in Encrypted Prof. Tommaso Pecorella. "Performance Monitoring in Encrypted
Networks: PDMv2.” [ELKINS] Networks: PDMv2." [ELKINS]
Appendix B. Workshop participants Appendix B. Workshop Participants
The workshop participants were Cindy Morgan, Colin Perkins, Cullen The workshop participants were Cindy Morgan, Colin Perkins, Cullen
Jennings, Deborah Brungard, Dhruv Dhody, Eric Vyncke, Georg Carle, Jennings, Deborah Brungard, Dhruv Dhody, Éric Vyncke, Georg Carle,
Ivan Nardi, Jari Arkko, Jason Livingood, Jiankang Yao, Karen Ivan Nardi, Jari Arkko, Jason Livingood, Jiankang Yao, Karen
O'Donoghue, Keith Winstein, Lars Eggert, Laurent Vanbever, Luca Deri, O'Donoghue, Keith Winstein, Lars Eggert, Laurent Vanbever, Luca Deri,
Mallory Knodel, Marcus Ihlar, Matteo, Michael Ackermann, Michael Mallory Knodel, Marcus Ihlar, Matteo, Michael Collins, Michael
Collins, Michael Richardson, Michael Welzl, Mike Ackermann, Mirja Richardson, Michael Welzl, Mike Ackermann, Mirja Kühlewind, Mohit
Kühlewind, Mohit P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul Grubbs, Pedro
Grubbs, Pedro Casas, Qin Wu, Qiufang, Richard Barnes, Rob Wilton, Casas, Qin Wu, Qiufang Ma, Richard Barnes, Rob Wilton, Russ White,
Russ White, Saloua Naama, Shinan Liu, Srinivas C, Toerless Eckert, Saloua Naama, Shinan Liu, Srinivas C, Toerless Eckert, Tommy Pauly,
Tommy Pauly, Wes Hardaker, Xi Chase Jiang, Zaheduzzaman Sarker, and Wes Hardaker, Xi Chase Jiang, Zaheduzzaman Sarker, and Zhenbin Li.
Zhenbin Li.
Appendix C. Program Committee Appendix C. Program Committee
The workshop program committee members were Wes Hardaker (IAB, USC/ The workshop program committee members were Wes Hardaker (IAB, USC/
ISI), Mallory Knodel (IAB, Center for Democracy and Technology), ISI), Mallory Knodel (IAB, Center for Democracy and Technology),
Mirja Kühlewind (IAB, Ericsson), Tommy Pauly (IAB, Apple), Russ White Mirja Kühlewind (IAB, Ericsson), Tommy Pauly (IAB, Apple), Russ White
(IAB, Juniper), Qin Wu (IAB, Huawei). (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 Acknowledgments
TODO acknowledge. We wish to acknowledge the comments and suggestions from Elliot Lear
and Arnaud Taddei for their comments and improvements to this
document.
Authors' Addresses Authors' Addresses
Mallory Knodel Mallory Knodel
Center for Democracy & Technology
Email: mknodel@cdt.org Email: mknodel@cdt.org
Wes Hardaker Wes Hardaker
Email: ietf@hardakers.net Email: ietf@hardakers.net
Tommy Pauly Tommy Pauly
Email: tpauly@apple.com Email: tpauly@apple.com
 End of changes. 136 change blocks. 
430 lines changed or deleted 447 lines changed or added

This html diff was produced by rfcdiff 1.48.