Report from the IAB workshop on Management Techniques in Encrypted Networks (M-TEN)
draft-iab-m-ten-workshop-01

Network Working Group                                          M. Knodel
Internet-Draft                         Center for Democracy & Technology
Intended status: Informational                               W. Hardaker
Expires: 31 October 2023                                                
                                                                T. Pauly
                                                           29 April 2023

   Report from the IAB workshop on Management Techniques in Encrypted
                            Networks (M-TEN)
                      draft-iab-m-ten-workshop-01

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 workshop participants and do not 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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Knodel, et al.           Expires 31 October 2023                [Page 1]
Internet-Draft            M-TEN workshop report               April 2023

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 October 2023.

Copyright Notice

   Copyright (c) 2023 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Workshop Scope and Discussion . . . . . . . . . . . . . . . .   4
     2.1.  "Where we are" - Requirements and Passive Observations  .   4
       2.1.1.  Traffic classification and network management . . . .   4
       2.1.2.  Preventing traffic analysis . . . . . . . . . . . . .   5
       2.1.3.  Users and privacy . . . . . . . . . . . . . . . . . .   6
       2.1.4.  Discussion  . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  "Where we want to go" - Collaboration Principles  . . . .   7
       2.2.1.  First party collaboration for network management  . .   7
       2.2.2.  Second and third party collaboration for network
               management  . . . . . . . . . . . . . . . . . . . . .   8
       2.2.3.  Visible, optional network management  . . . . . . . .   9
       2.2.4.  Discussion  . . . . . . . . . . . . . . . . . . . . .   9
     2.3.  "How we get there" - Collaboration Use cases  . . . . . .  10
       2.3.1.  Establishing expected contracts to enable security
               management  . . . . . . . . . . . . . . . . . . . . .  10
       2.3.2.  Zero Knowledge Middleboxes  . . . . . . . . . . . . .  11
       2.3.3.  Red Rover - A collaborative approach to content
               filtering . . . . . . . . . . . . . . . . . . . . . .  12
   3.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Appendix A.  Position Papers  . . . . . . . . . . . . . . . . . .  15
     A.1.  Motivations and principles  . . . . . . . . . . . . . . .  15

Knodel, et al.           Expires 31 October 2023                [Page 2]
Internet-Draft            M-TEN workshop report               April 2023

     A.2.  Classification and identification of encrypted traffic  .  16
     A.3.  Ideas for collaboration and coordination between devices
           and networks  . . . . . . . . . . . . . . . . . . . . . .  16
     A.4.  Other background material . . . . . . . . . . . . . . . .  16
   Appendix B.  Workshop participants  . . . . . . . . . . . . . . .  16
   Appendix C.  Program Committee  . . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   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 support
   techniques that enhance 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 initiate new 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?

Knodel, et al.           Expires 31 October 2023                [Page 3]
Internet-Draft            M-TEN workshop report               April 2023

2.  Workshop Scope and Discussion

   The workshop was organized 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 agenda 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 techiques are passive in nature:
   they don't rely on an 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 traditionally 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 a useful insight onto how "leaky" the protocols used by
   applications are, and points to areas where information is visible to
   any observer, which may be malicious or not.

Knodel, et al.           Expires 31 October 2023                [Page 4]
Internet-Draft            M-TEN workshop report               April 2023

   Traditionally, classification has been based on experts crafting
   specific rules, but there is also a move toward using maching
   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 showed that a model that performs with high accuracy on an
   initial data set became severely degraded when running on a newer
   data set that contained 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 on determining which set of features in IP packets are
   most useful for focused machine learning analysis.  [WU] also
   recommends further research investment in Artificial Intelligent (AI)
   analysis for network management.

2.1.2.  Preventing traffic analysis

   Just as traffic classification is continually adapting, techniques to
   prevent traffic analysis and 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 adding padding 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 in line speed.

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

Knodel, et al.           Expires 31 October 2023                [Page 5]
Internet-Draft            M-TEN workshop report               April 2023

2.1.3.  Users and privacy

   The Privacy Enhancements and Assessments Research Group is working on
   a document to discuss guidelines for how to measure traffic on the
   Internet in a safe and privacy-friendly way
   ([I-D.irtf-pearg-safe-internet-measurement]).  These guidelines and
   principles provide another angle onto 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 explicitly given as informed consent, or can be given
   by proxy or 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 out
   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 others.  One of the recurring
   challenges that came up was not having a clear way to understand or
   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 a
   network attempting to inspect application traffic without
   coordination from applications, and traffic obfuscation is an attempt
   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 leaking metadata, it could benefit from signals
   from network about sudden capacity changes that can help it adapt its
   application quality, such as bitrates and codecs.  Such signalling
   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.

Knodel, et al.           Expires 31 October 2023                [Page 6]
Internet-Draft            M-TEN workshop report               April 2023

   Managed networks (such a private corporate networks) was brought up
   in several comments as a particularly challenging area for being able
   to meet 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 being operated by the network may be
   as simple as a DNS filter, and 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 agenda focused on the emerging
   techniques for analysing, managing or monitoring encrypted traffic.
   Presentations ranged from discussing advanced classification and
   identification, including machine-learning techniques, for the
   purposes of manging network flows, monitoring or monetising 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 intention of encryption to create a barrier between
   entities inside the communication channel and everyone else,
   including network operators, considering end-to-end encryption of
   traffic.  Any attempt, therefore, to overcome that intentional
   barrier requires an intent to collaborate between the inside and
   outside entities.  Those entities must, at a minimum, agree on the
   benefits to overcoming the barrier (or solving the problem), that
   costs are proportional to the benefits, and to additional
   limitations, or safeguards, against bad behaviour by collaborators
   including the inclusion of 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
   opportunitistic or perfunctory discoverability.  These realities both
   point to a need to interrogate the reason why any outside entity
   might make an engineering case to collaborate with the user of a
   network with encrypted traffic, and whether the tradeoffs and
   potential risks are worth it to the user.

Knodel, et al.           Expires 31 October 2023                [Page 7]
Internet-Draft            M-TEN workshop report               April 2023

   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.  Tradeoffs 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.

   Additionally, there appears to be little if any actual evidence that
   encryption is causing user-meaningful network problems.  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 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 to separate (using additional levels of encryption) 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 optimisation,
   quality of service, zero-rating, parental controls, access control,
   redirection, content enhancement, analytics and fraud prevention.

Knodel, et al.           Expires 31 October 2023                [Page 8]
Internet-Draft            M-TEN workshop report               April 2023

   Instead of encrypted communication between only two ends and passive
   observation by all on-path elements, intermediate relays could be
   trusted parties with limited information for the purposes of
   collaboration between in-network intermediary services' support.

2.2.3.  Visible, optional network management

   In encrypted communications, out of all of the possible network
   management functions that might be ameliorated by proxying, the
   ability to control congestion has been researched in depth.  These
   techniques are realized based on TCP performance enhancing proxies
   (PEP) 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, instead of
   manipulating existing information, a new approach was presented where
   additional information is send using a so-called side-car protocol
   independent of the main transport protocol that is used end-to-end
   [WELZL].  E.g. side car information can contain additional
   acknowledgements to enable in-network local retransmission 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 use of an additional "side-car"
   protocol, or explicit encrypted and trusted network communication
   using MASQUE in relation to existing techniques such as TCP
   performance enhancing proxies (PEP), etc.

2.2.4.  Discussion

   One size fits all?  On the issue of trust, different networks or
   devices are going to have different requirements for the level of
   trust that they have in devices, users or each other, and vice versa.
   For example, imagine networks with really different security
   requirements, like protecting children in a home versus a national
   security institution.  How could one network architecture solve the
   needs of all use cases?

   Does our destination have consequences?  It seems sometimes that
   there may be consequences many years down the line of ubiquitous,
   strong encryption of network traffic because it will cause a reaction
   by intermediaries to find ways to poke holes in what are supposed to
   be long-term solutions for user privacy and security.

Knodel, et al.           Expires 31 October 2023                [Page 9]
Internet-Draft            M-TEN workshop report               April 2023

   Can we bring the user along?  While there has been a focus on the
   good reasons for why people might collaborate across the encryption
   barrier, there will always be others who want to disrupt that because
   they are motivated to exploit the data for their own gain, and
   sometimes this is called innovation.  What high-level policy
   mitigations have done is to expose how powerless end users are to
   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 are having to make inferences about what users
   want.  Instead we should be making these relationships and tradeoffs
   more visible.

2.3.  "How we get there" - Collaboration Use cases

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

2.3.1.  Establishing expected contracts to enable security management

   When thinking about 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 between options that frequently only frustrate attackers --
   entirely preventing attacks 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 what anomalous traffic is rooted
   in malicious activity with any level of certainty is extremely
   challenging.  Unfortunately, applying the latest machine learning
   techniques has only 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

Knodel, et al.           Expires 31 October 2023               [Page 10]
Internet-Draft            M-TEN workshop report               April 2023

   overload and challenges event prioritization.  Any path forward must
   succeed in freeing up analyst time to concentrate on the more
   challenging events.

   The proposed contract solution is to define a collection of
   acceptable behaviors categorized into an envelope of 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 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", and 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
   (MUDD) {?RFC8520} specification is one subset of contracts.  Note
   that contracts are likely to only succeed in a constrained, expected
   environment maintained by operational staff, and may not work in an
   open internet environment where end users are driving 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 the creation of a
   significant tension between security enforcement and privacy
   protection.

   A goal for solving this problem should include not weakening
   encryption, should enable networks to enforce their policies, and
   should ideally not require newly deployed server software.  Existing
   solutions fail with at least one of these points.

   A cryptographic principle of a "zero-knowledge proof" (ZKP) [GRUBBS]
   maybe 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 actually
   compliant with a policy without revealing the actual contents.  This
   solution meets the above three criteria.  Using ZKP within TLS 1.3
   traffic turns out to be plausible.

   An example engine was built to test ZKP using encrypted DNS.  Clients
   were able to create DNS requests that were not listed within a DNS
   block list.  Middleboxes could verify, without knowing the exact

Knodel, et al.           Expires 31 October 2023               [Page 11]
Internet-Draft            M-TEN workshop report               April 2023

   request, that the client's DNS request was not in 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 deal with the inherit
   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 user's privacy and user 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 between the tension of privacy vs protection
   based 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 be willing to participate and allow technologies into
      their environment requirements 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 different encumbrances of

Knodel, et al.           Expires 31 October 2023               [Page 12]
Internet-Draft            M-TEN workshop report               April 2023

   multiple types; 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 that weren't considered
   during the design of the protocol.  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 might have impact
   on private network deployments that break existing use cases.  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://github.com/intarchboard/m-ten-
              workshop/blob/main/papers/Barnes-Whats-In-It-For-Me-
              Revisiting-the-reasons-people-collaborate.pdf>.

   [CASAS]    Casas, P., "Monitoring User-Perceived Quality in an
              Encrypted Internet", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Casas-AI-driven-real-time-QoE-
              monitoring-encrypted-traffic.pdf>.

   [COLLINS]  Collins, M., "Improving Network Monitoring Through
              Contracts", August 2022, <https://github.com/intarchboard/
              workshop-m-ten/blob/main/papers/Collins-Improving-Network-
              Monitoring-Through-Contracts.pdf>.

   [DERI]     Deri, L., "nDPI Research Proposal", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Deri-nDPI-Research-Proposal.pdf>.

Knodel, et al.           Expires 31 October 2023               [Page 13]
Internet-Draft            M-TEN workshop report               April 2023

   [DITTO]    Meier, R., Lenders, V., and L. Vanbever, "Ditto - WAN
              Traffic Obfuscation at Line Rate", April 2022,
              <https://nsg.ee.ethz.ch/fileadmin/user_upload/
              publications/ditto_final_ndss22.pdf>.

   [ELKINS]   Elkins, N., Ackermann, M., Tahiliani, M., Dhody, D., and
              T. Pecorella, "Performance Monitoring in Encrypted
              Networks", August 2022, <https://github.com/intarchboard/
              workshop-m-ten/blob/main/papers/Elkins-Performance-
              Monitoring-in-Encrypted-Networks-PDMv2.pdf>.

   [GRUBBS]   Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M.
              Walfish, "Zero-Knowledge Middleboxes", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Grubbs-Zero-
              Knowledge%20Middleboxes.pdf>.

   [I-D.irtf-pearg-safe-internet-measurement]
              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-07, 28 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
              safe-internet-measurement-07>.

   [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://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Jiang-Towards-Designing-Robust-and-
              Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-
              Internet.pdf>.

   [KNODEL]   Knodel, M., "Guidelines for Performing Safe Measurement on
              the Internet", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Knodel-Guidelines-for-Performing-
              Safe-Measurement-on-the-Internet.pdf>.

   [KUEHLEWIND]
              Kühlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
              "Relying on Relays", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf>.

Knodel, et al.           Expires 31 October 2023               [Page 14]
Internet-Draft            M-TEN workshop report               April 2023

   [LEI]      Lei, Y., Wu, J., Sun, X., Zhang, L., and Q. Wu, "Encrypted
              Traffic Classification Through Deep Learning", August
              2022, <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Lei-Encrypted-Traffic-Classification-
              Through-Deep-Learning.pdf>.

   [PAULY]    Pauly, T. and R. Barnes, "Red Rover", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/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/rfc/rfc3168>.

   [WELZL]    Welzl, M., "The Sidecar", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/Welzl-The-Sidecar-Opting-in-to-PEP-
              Functions.pdf>.

   [WU]       Wu, Q., Wu, J., and Q. Ma, "Network Management of
              Encrypted Traffic", August 2022,
              <https://github.com/intarchboard/workshop-m-
              ten/blob/main/papers/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 as such.

A.1.  Motivations and principles

   Richard Barnes. “What’s In It For Me?  Revisiting the reasons people
   collaborate.” [BARNES]

   Iain R.  Learmonth, Gurshabad Grover, Mallory Knodel. “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]

Knodel, et al.           Expires 31 October 2023               [Page 15]
Internet-Draft            M-TEN workshop report               April 2023

A.2.  Classification and identification of encrypted traffic

   Luca Deri. “nDPI Research Proposal.” [DERI]

   Wes Hardaker. “Network Flow Management by Probability.”

   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 Kühlewind, 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, Eric 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 Ackermann, Michael
   Collins, Michael Richardson, Michael Welzl, Mike Ackermann, Mirja

Knodel, et al.           Expires 31 October 2023               [Page 16]
Internet-Draft            M-TEN workshop report               April 2023

   Kühlewind, Mohit P.  Tahiliani, Nalini Elkins, Patrick Tarpey, Paul
   Grubbs, Pedro Casas, Qin Wu, Qiufang, 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).

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Mallory Knodel
   Center for Democracy & Technology
   Email: mknodel@cdt.org

   Wes Hardaker
   Email: ietf@hardakers.net

   Tommy Pauly
   Email: tpauly@apple.com

Knodel, et al.           Expires 31 October 2023               [Page 17]