rfc9490v1.txt		rfc9490.txt
	Internet Architecture Board (IAB) M. Knodel		Internet Architecture Board (IAB) M. Knodel
	Request for Comments: 9490 Center for Democracy & Technology		Request for Comments: 9490
	Category: Informational W. Hardaker		Category: Informational W. Hardaker
	ISSN: 2070-1721		ISSN: 2070-1721
	T. Pauly		T. Pauly
	October 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)
	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
	skipping to change at line 46 ¶		skipping to change at line 46 ¶
	Internet Architecture Board (IAB). Documents approved for		Internet Architecture Board (IAB). Documents approved for
	publication by the IAB are not candidates for any level of Internet		publication by the IAB are not candidates for any level of Internet
	Standard; see Section 2 of RFC 7841.		Standard; see Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9490.		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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document.		to this document.
	Table of Contents		Table of Contents
	skipping to change at line 88 ¶		skipping to change at line 88 ¶
	3. Conclusions		3. Conclusions
	4. Informative References		4. Informative References
	Appendix A. Position Papers		Appendix A. Position Papers
	A.1. Motivations and Principles		A.1. Motivations and Principles
	A.2. Classification and Identification of Encrypted Traffic		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		and Networks
	A.4. Other Background Material		A.4. Other Background Material
	Appendix B. Workshop Participants		Appendix B. Workshop Participants
	Appendix C. Program Committee		Appendix C. Program Committee
			IAB Members at the Time of Approval
			Acknowledgments
	Authors' Addresses		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 to		reliably in the presence of ubiquitous traffic encryption and to
	support user privacy. In an all-encrypted network, it is not viable		support user privacy. In an all-encrypted network, it is not viable
	to rely on unencrypted metadata for network monitoring and security		to rely on unencrypted metadata for network monitoring and security
	skipping to change at line 169 ¶		skipping to change at line 178 ¶
	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 useful insight into 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, who may or may not be malicious.		any observer, who may or may not be malicious.
	Traditionally, classification has been based on specific rules		Frequently, classification has been based on specific rules crafted
	crafted by experts, but there is also a move toward using machine		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 show that a model that performed with high accuracy on an		that show that a model that performed with high accuracy on an
	initial data set becomes severely degraded when running on a newer		initial data set becomes severely degraded when running on a newer
	data set that contains 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
	skipping to change at line 359 ¶		skipping to change at line 368 ¶
	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 optimization,		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 encrypted communication between only two ends and passive		Instead of encrypting communication between only two ends with
	observation by all on-path elements, intermediate relays could be		passive observation by all on-path elements, intermediate relays
	trusted parties with limited information for the purposes of		could be introduced as trusted parties that get to see limited
	collaboration between in-network intermediary services' support.		information for the purpose of collaboration between in-network
			intermediary services.
	2.2.3. Visible, Optional Network Management		2.2.3. Visible, Optional Network Management
	Out of all of the possible network management functions that might be		Out of all of the possible network management functions that might be
	ameliorated by proxying, the ability to control congestion in		ameliorated by proxying, the ability to control congestion in
	encrypted communications 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
	(PEPs) 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, a new		impact on the evolvability of these protocols. Therefore, a new
	approach was presented where, instead of manipulating existing		approach was presented where, instead of manipulating existing
	information, additional information is sent using a so-called sidecar		information, additional information is sent using a so-called sidecar
	protocol independent of the main transport protocol that is used end		protocol independent of the main transport protocol that is used end
	to end [WELZL]. For example, sidecar information can contain		to end [WELZL]. For example, sidecar information can contain
	additional acknowledgments to enable in-network local retransmission		additional acknowledgments to enable in-network local retransmission
	faster end-to-end retransmission by reducing the signaling round-trip		or faster end-to-end retransmission by reducing the signaling round-
	time.		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 the use of an additional sidecar		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 PEPs,		using MASQUE in relation to existing techniques such as TCP PEPs,
	etc.		etc.
	2.2.4. Discussion		2.2.4. Discussion
	skipping to change at line 456 ¶		skipping to change at line 466 ¶
	are malicious events. Identifying which 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 produced mixed results. To make matters worse, the		techniques has produced mixed results. To make matters worse, 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
	free up analyst time to concentrate on the more challenging events.		free up analyst time to concentrate on the more 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 that a normal		outside a normal mode of behavior or even that a normal mode of
	mode of behavior is suddenly missing. An example contract might be		behavior is suddenly missing. An example contract might be "this
	"this system is expected to update its base OS once a day". 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] is one subset of contracts. Note that contracts are		(MUD) [RFC8520] is one subset of contracts. Note that contracts are
	likely to succeed only in a constrained, expected environment		likely to succeed only in a constrained, expected environment
	maintained by operational staff and may not work in an open Internet		maintained by operational staff and may not work in an open Internet
	environment where end users drive all network connections.		environment where end users drive all network connections.
	skipping to change at line 518 ¶		skipping to change at line 528 ¶
	Conversely, clients need to protect their users' privacy and		Conversely, clients need to protect their users' privacy and
	security.		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 multiple, different		management. Each problem space will have multiple, different
	encumbrances: 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
	skipping to change at line 570 ¶		skipping to change at line 581 ¶
	deployments. While making decisions on technology direction and		deployments. While making decisions on technology direction and
	protocol design, it is important to consider the impact on various		protocol design, it is important to consider the impact on various
	kinds of network deployments and their unique requirements. When		kinds of network deployments and their unique requirements. When
	protocols change to make different network management functions		protocols change to make different network management functions
	easier or harder, the impact on various deployment models ought to be		easier or harder, the impact on various deployment models ought to be
	considered and documented.		considered and 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 - AI to the Rescue", 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: PDMv2", August 2022,		Networks: PDMv2", August 2022, <https://www.iab.org/wp-
	<https://github.com/intarchboard/workshop-m-		content/IAB-uploads/2023/11/Elkins-Performance-Monitoring-
	ten/blob/main/papers/Elkins-Performance-Monitoring-in-		in-Encrypted-Networks-PDMv2.pdf>.
	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>.
			[HARDAKER] Hardaker, W., "Network Flow Management by Probability",
			August 2022, <https://www.iab.org/wp-content/IAB-
			uploads/2023/11/Hardaker-Encrypted-Traffic-
			Estimation.pdf>.
	[JIANG] Jiang, X., Liu, S., Naama, S., Bronzino, F., Schmitt, P.,		[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]
	Kuehlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,		Kuehlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
	"Relying on Relays: The future of secure communication",		"Relying on Relays: The future of secure communication",
	August 2022, <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]
	Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines		Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines
	for Performing Safe Measurement on the Internet", Work in		for Performing Safe Measurement on the Internet", Work in
	Progress, Internet-Draft, draft-irtf-pearg-safe-internet-		Progress, Internet-Draft, draft-irtf-pearg-safe-internet-
	measurement-08, 10 July 2023,		measurement-08, 10 July 2023,
	<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-		<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
	safe-internet-measurement-08>.		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: A collaborative		[PAULY] Pauly, T. and R. Barnes, "Red Rover: A collaborative
	approach to content filtering", August 2022,		approach to content filtering", August 2022,
	<https://github.com/intarchboard/workshop-m-		<https://www.iab.org/wp-content/IAB-uploads/2023/11/Pauly-
	ten/blob/main/papers/Pauly-Red-Rover-A-collaborative-		Red-Rover-A-collaborative-approach-to-content-
	approach-to-content-filtering.pdf>.		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/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage		[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
	Description Specification", RFC 8520,		Description Specification", RFC 8520,
	DOI 10.17487/RFC8520, March 2019,		DOI 10.17487/RFC8520, March 2019,
	<https://www.rfc-editor.org/info/rfc8520>.		<https://www.rfc-editor.org/info/rfc8520>.
	[WELZL] Welzl, M., "The Sidecar: 'Opting in' to PEP Functions",		[WELZL] Welzl, M., "The Sidecar: 'Opting in' to PEP Functions",
	August 2022, <https://github.com/intarchboard/workshop-m-		August 2022, <https://www.iab.org/wp-content/IAB-
	ten/blob/main/papers/Welzl-The-Sidecar-Opting-in-to-PEP-		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: Detect it don't decrypt it", August		Encrypted Traffic: Detect it don't decrypt it", August
	2022, <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.		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		Qin Wu, Jun Wu, Qiufang Ma. "Network Management of Encrypted
	Traffic: 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
	skipping to change at line 735 ¶		skipping to change at line 748 ¶
	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, Éric 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
			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. 31 change blocks.
	84 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.48.