| Internet-Draft | M-TEN workshop report | April 2023 |
| Knodel, et al. | Expires 31 October 2023 | [Page] |
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.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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. 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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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 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.¶
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].¶
Looking forward, the workshop participants identified that solving the entire problem space with a single approach will be challenging for several reasons:¶
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 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.¶
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.¶
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]¶
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]¶
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]¶
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 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.¶
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).¶
TODO acknowledge.¶