draft-iab-path-signals-collaboration-01.txt		draft-iab-path-signals-collaboration.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T. Hardie		Intended status: Informational T. Hardie
	Expires: January 12, 2023 Cisco		Expires: April 22, 2023 Cisco
	T. Pauly		T. Pauly
	Apple		Apple
	M. Kuehlewind		M. Kuehlewind
	Ericsson		Ericsson
	July 11, 2022		October 19, 2022
	Considerations on Application - Network Collaboration Using Path Signals		Considerations on Application - Network Collaboration Using Path Signals
	draft-iab-path-signals-collaboration-01		draft-iab-path-signals-collaboration-02
	Abstract		Abstract
	This document discusses principles for designing mechanisms that use		This document discusses principles for designing mechanisms that use
	or provide path signals, and calls for standards action in specific		or provide path signals, and calls for standards action in specific
	valuable cases. RFC 8558 describes path signals as messages to or		valuable cases. RFC 8558 describes path signals as messages to or
	from on-path elements, and points out that visible information will		from on-path elements, and points out that visible information will
	be used whether it is intended as a signal or not. The principles in		be used whether it is intended as a signal or not. The principles in
	this document are intended as guidance for the design of explicit		this document are intended as guidance for the design of explicit
	path signals, which are encouraged to be authenticated and include a		path signals, which are encouraged to be authenticated and include a
	minimal set of parties and minimize information sharing. These		minimal set of parties to minimize information sharing. These
	principles can be achieved through mechanisms like encryption of		principles can be achieved through mechanisms like encryption of
	information and establishing trust relationships between entities on		information and establishing trust relationships between entities on
	a path.		a path.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 12, 2023.		This Internet-Draft will expire on April 22, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 32		skipping to change at page 2, line 32
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Intentional Distribution . . . . . . . . . . . . . . . . 7		2.1. Intentional Distribution . . . . . . . . . . . . . . . . 7
	2.2. Control of the Distribution of Information . . . . . . . 7		2.2. Control of the Distribution of Information . . . . . . . 7
	2.3. Protecting Information and Authentication . . . . . . . . 8		2.3. Protecting Information and Authentication . . . . . . . . 8
	2.4. Minimize Information . . . . . . . . . . . . . . . . . . 9		2.4. Minimize Information . . . . . . . . . . . . . . . . . . 9
	2.5. Limiting Impact of Information . . . . . . . . . . . . . 10		2.5. Limiting Impact of Information . . . . . . . . . . . . . 10
	2.6. Minimum Set of Entities . . . . . . . . . . . . . . . . . 11		2.6. Minimum Set of Entities . . . . . . . . . . . . . . . . . 11
	2.7. Carrying Information . . . . . . . . . . . . . . . . . . 11		2.7. Carrying Information . . . . . . . . . . . . . . . . . . 11
	3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Informative References . . . . . . . . . . . . . . . . . . . 14		5. Informative References . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	RFC 8558 defines the term "path signals" as signals to or from on-		[RFC8558] defines the term "path signals" as signals to or from on-
	path elements. Today path signals are often implicit, e.g. derived		path elements. Today path signals are often implicit, e.g. derived
	from cleartext end-to-end information by e.g. examining transport		from cleartext end-to-end information by e.g. examining transport
	protocols. For instance, on-path elements use various fields of the		protocols. For instance, on-path elements use various fields of the
	TCP header [RFC0793] to derive information about end-to-end latency		TCP header [RFC0793] to derive information about end-to-end latency
	as well as congestion. These techniques have evolved because the		as well as congestion. These techniques have evolved because the
	information was available and its use required no coordination with		information was available and its use required no coordination with
	anyone. This made such techniques more easily deployed than		anyone. This made such techniques more easily deployable than
	alternative, potentially more explicit or cooperative approaches.		alternative, potentially more explicit or cooperative, approaches.
	Such techniques had some drawbacks as well, such as having to
	interpret information designed to be carried for one purpose for a
	new, different purpose.
	Today, applications and networks have often evolved their interaction		However, this also means that applications and networks have often
	without comprehensive design for how this interaction should happen		evolved their interaction without comprehensive design for how this
	or which information would be needed for a certain function. This		interaction should happen or which (minimal) information would be
	has led to a situation where sometimes information that happens to be		needed for a certain function. This has led to a situation where
	easily available is used. But that information may be incomplete,		simply information that happens to be easily available is used
	incorrect, or only indirectly representative of the information that		instead the information that would be actually needed. As such that
	is actually needed. In addition, dependencies on information and		information may be incomplete, incorrect, or only indirectly
	mechanisms that were designed for a different function limits the		representative of the information that is actually needed. In
	evolvability of the protocols in question.		addition, dependencies on information and mechanisms that were
			designed for a different function limits the evolvability of the
			protocols in question.
	The unplanned interaction ends up having several negative effects:		In summary, such unplanned interactions end up having several
			negative effects:
	o Ossifying protocols by introducing dependencies to unintended		o Ossifying protocols by introducing dependencies to unintended
	parties that may not be updating, such as how middleboxes have		parties that may not be updating, such as how middleboxes have
	limited the use of TCP options		limited the use of TCP options
	o Creating systemic incentives against deploying more secure or		o Creating systemic incentives against deploying more secure or
	otherwise updated versions of protocols		otherwise updated versions of protocols
	o Basing network behaviour on information that may be incomplete or		o Basing network behaviour on information that may be incomplete or
	incorrect		incorrect
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	Many protocol mechanisms throughout the stack fall into one of two		Many protocol mechanisms throughout the stack fall into one of two
	categories: authenticated and private communication that is only		categories: authenticated and private communication that is only
	visible to a very limited set of parties, often one on each "end";		visible to a very limited set of parties, often one on each "end";
	and unauthenticated public communication that is also visible to all		and unauthenticated public communication that is also visible to all
	network elements on a path.		network elements on a path.
	Exposed information encourages pervasive monitoring, which is		Exposed information encourages pervasive monitoring, which is
	described in RFC 7258 [RFC7258], and may also be used for commercial		described in RFC 7258 [RFC7258], and may also be used for commercial
	purposes, or form a basis for filtering that the applications or		purposes, or form a basis for filtering that the applications or
	users do not desire. But a lack of all path signalling, on the other		users do not desire. But a lack of all path signalling, on the other
	hand, may be harmful to network management, debugging, or the ability		hand, may limit network management, debugging, or the ability for
	for networks to provide the most efficient services. There are many		networks to optimize their services. There are many cases where
	cases where elements on the network path can provide beneficial		elements on the network path can provide beneficial services, but
	services, but only if they can coordinate with the endpoints. It		only if they can coordinate with the endpoints. It also affects the
	also affects the ability of service providers and others to observe		ability of service providers and others to observe why problems occur
	why problems occur [RFC9075].		[RFC9075].
	As such, this situation is sometimes cast as an adversarial tradeoff		As such, this situation is sometimes cast as an adversarial tradeoff
	between privacy and the ability for the network path to provide		between privacy and the ability for the network path to provide
	intended functions. However, this is perhaps an unnecessarily		intended functions. However, this is perhaps an unnecessarily
	polarized characterization as a zero-sum situation. Not all		polarized characterization as a zero-sum situation. Not all
	information passing implies loss of privacy. For instance,		information passing implies loss of privacy. For instance,
	performance information or preferences do not require disclosing the		performance information or preferences do not require disclosing the
	content being accessed, the user identity, or the application in use.		content being accessed, the user identity, or the application in use.
	Similarly, network congestion status information does not have reveal		Similarly, network congestion status information does not have to
	network topology or the status of other users, and so on.		reveal network topology or the status of other users, and so on.
	Increased deployment of encryption is changing this situation.		Increased deployment of encryption is changing this situation.
	Encryption provides tools for controlling information access and		Encryption provides tools for controlling information access and
	protects against ossification by avoiding unintended dependencies and		protects against ossification by avoiding unintended dependencies and
	requiring active maintenance.		requiring active maintenance. The increased deployment of encryption
			provides an opportunity to reconsider parts of Internet architecture
	The increased deployment of encryption provides an opportunity to		that have used implicit derivation of input signals for on-path
	reconsider parts of Internet architecture that have used implicit		functions rather than explicit signalling, as recommended by RFC 8558
	derivation of input signals for on-path functions rather than		[RFC8558].
	explicit signalling, as recommended by RFC 8558 [RFC8558].
	For instance, QUIC replaces TCP for various applications and ensures		For instance, QUIC replaces TCP for various applications and ensures
	end-to-end signals are only be accessible by the endpoints, ensuring		end-to-end signals are only accessible by the endpoints, ensuring
	evolvability [RFC9000]. QUIC does expose information dedicated for		evolvability [RFC9000]. QUIC does expose information dedicated for
	on-path elements to consume by using explicit signals for specific		on-path elements to consume by using explicit signals for specific
	use cases, such as the Spin bit for latency measurements or		use cases, such as the Spin bit for latency measurements or
	connection ID that can be used by load balancers		connection ID that can be used by load balancers
	[I-D.ietf-quic-manageability]. This information is accessible by all		[I-D.ietf-quic-manageability]. This information is accessible by all
	on-path devices but information is limited to only those use cases.		on-path devices but information is limited to only those use cases.
	Each new use case requires additional action. This points to one way		Each new use case requires additional action. This points to one way
	to resolve the adversity: the careful design of what information is		to resolve the adversity: the careful design of what information is
	passed.		passed.
	Another extreme is to employ explicit trust and coordination between		Another extreme is to employ explicit trust and coordination between
	all involved entities, endpoints as well as network devices. VPNs		specific entities, endpoints as well as network path elements. VPNs
	are a good example of a case where there is an explicit		are a good example of a case where there is an explicit
	authentication and negotiation with a network path element that is		authentication and negotiation with a network path element that is
	used to optimize behavior or gain access to specific resources.		used to gain access to specific resources. Authentication and trust
	Authentication and trust must be considered in multiple directions:		must be considered in both directions: how endpoints trust and
	how endpoints trust and authenticate signals from network devices,		authenticate signals from network path elements, and how network path
	and how network devices trust and authenticate signals from		elements trust and authenticate signals from endpoints.
	endpoints.
	The goal of improving privacy and trust on the Internet does not		The goal of improving privacy and trust on the Internet does not
	necessarily need to remove the ability for network elements to		necessarily need to remove the ability for network elements to
	perform beneficial functions. We should instead improve the way that		perform beneficial functions. We should instead improve the way that
	these functions are achieved and design new ways to support explicit		these functions are achieved and design new ways to support explicit
	collaboration where it is seen as beneficial. As such our goals		collaboration where it is seen as beneficial. As such our goals
	should be:		should be:
	o To ensure that information is distributed intentionally, not		o To ensure that information is distributed intentionally, not
	accidentally;		accidentally;
	skipping to change at page 5, line 39		skipping to change at page 5, line 39
	o What is the minimum information each entity in this set needs?		o What is the minimum information each entity in this set needs?
	o What is the effect that new signals should have?		o What is the effect that new signals should have?
	o What is the minimum set of entities that need to be involved?		o What is the minimum set of entities that need to be involved?
	o What is the right mechanism and needed level of trust to convey		o What is the right mechanism and needed level of trust to convey
	this kind of information?		this kind of information?
	If we look at many of the ways network functions are achieved today,		If we look ways network functions are achieved today, we find that
	we find that many if not most of them fall short the standard set up		many if not most of them fall short the standard set up by the
	by the questions above. Too often, they send unnecessary information		questions above. Too often, they send unnecessary information or
	or fail to limit the scope of distribution or providing any		fail to limit the scope of distribution or providing any negotiation
	negotiation or consent.		or consent.
	Designing explicit signals between applications and network elements,		Designing explicit signals between applications and network elements,
	and ensuring that all information is appropriately protected, enables		and ensuring that all information is appropriately protected, enables
	information exchange in both directions that is important for		information exchange in both directions that is important for
	improving the quality of experience and network management. The		improving the quality of experience and network management. The
	clean separation provided by explicit signals is also more conducive		clean separation provided by explicit signals is also more conducive
	to protocol evolvability.		to protocol evolvability.
	Beyond the recommendation in [RFC8558], the IAB has provided further		Beyond the recommendation in [RFC8558], the IAB has provided further
	guidance on protocol design. Among other documents, [RFC5218]		guidance on protocol design. Among other documents, [RFC5218]
	skipping to change at page 7, line 10		skipping to change at page 7, line 10
	security concerns of sharing information between endpoints and		security concerns of sharing information between endpoints and
	network elements, emphasizing that careful scrutiny and a high bar of		network elements, emphasizing that careful scrutiny and a high bar of
	consent and trust need to be applied. Given the known threat of		consent and trust need to be applied. Given the known threat of
	pervasive monitoring, the application of these principles is critical		pervasive monitoring, the application of these principles is critical
	to ensuring that the use of path signals does not create a		to ensuring that the use of path signals does not create a
	disproportionate opportunity for observers to extract new data from		disproportionate opportunity for observers to extract new data from
	flows.		flows.
	2.1. Intentional Distribution		2.1. Intentional Distribution
	This guideline is best expressed in RFC 8558:		This guideline is best expressed in [RFC8558]:
	"Fundamentally, this document recommends that implicit signals should		"Fundamentally, this document recommends that implicit signals should
	be avoided and that an implicit signal should be replaced with an		be avoided and that an implicit signal should be replaced with an
	explicit signal only when the signal's originator intends that it be		explicit signal only when the signal's originator intends that it be
	used by the network elements on the path. For many flows, this may		used by the network elements on the path. For many flows, this may
	result in the signal being absent but allows it to be present when		result in the signal being absent but allows it to be present when
	needed."		needed."
	The goal is that any information should be provided knowingly, for a		The goal is that any information should be provided knowingly, for a
	specific purpose, sent in signals designed for that purpose, and that		specific purpose, sent in signals designed for that purpose, and that
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	about what information to share.		about what information to share.
	2.2. Control of the Distribution of Information		2.2. Control of the Distribution of Information
	Explicit signals are not enough. The entities also need to agree to		Explicit signals are not enough. The entities also need to agree to
	exchange the information. Trust and mutual agreement between the		exchange the information. Trust and mutual agreement between the
	involved entities must determine the distribution of information, in		involved entities must determine the distribution of information, in
	order to give adequate control to each entity over the collaboration		order to give adequate control to each entity over the collaboration
	or information sharing. This can be achieved as discussed below.		or information sharing. This can be achieved as discussed below.
	The sender needs to agree to sending the information. Any passing of		The sender needs to decide that it is willing to send information to
	information or request for an action needs to be explicit, and use		a specific entity or set of entities. Any passing of information or
	signalling mechanisms that are designed for the purpose. Merely		request for an action needs to be explicit, and use signalling
	sending a particular kind of packet to a destination should not be		mechanisms that are designed for the purpose. Merely sending a
	interpreted as an implicit agreement.		particular kind of packet to a destination should not be interpreted
			as an implicit agreement.
	At the same time, the recipient of information or the target of a		At the same time, the recipient of information or the target of a
	request should agree to receiving the information. It should not be		request should have the option to agree or deny to receiving the
	burdened with extra processing if it does not have willingness or a		information. It should not be burdened with extra processing if it
	need to do so. This happens naturally in most protocol designs, but		does not have willingness or a need to do so. This happens naturally
	has been a problem for some cases where "slow path" packet processing		in most protocol designs, but has been a problem for some cases where
	is required or implied, and the recipient or router is not willing to		"slow path" packet processing is required or implied, and the
	handle this. Performance impacts like this are best avoided,		recipient or router is not willing to handle this. Performance
	however.		impacts like this are best avoided, however.
	In any case, all involved entities must be identified and potentially		In any case, all involved entities must be identified and potentially
	authenticated if trust is required as a prerequisite to share certain		authenticated if trust is required as a prerequisite to share certain
	information.		information.
	Many Internet communications are not performed on behalf of the		Many Internet communications are not performed on behalf of the
	applications, but are ultimately made on behalf of users. However,		applications, but are ultimately made on behalf of users. However,
	not all information that may be shared directly relates to user		not all information that may be shared directly relates to user
	actions or other sensitive data. All information shared must be		actions or other sensitive data. All information shared must be
	evaluated carefully to identify potential privacy implications for		evaluated carefully to identify potential privacy implications for
	skipping to change at page 9, line 10		skipping to change at page 9, line 11
	a network element and an application. This channel may need to be		a network element and an application. This channel may need to be
	authenticated, integrity protected and confidential. This is		authenticated, integrity protected and confidential. This is
	necessary, for instance, if the particular information or request		necessary, for instance, if the particular information or request
	needs to be shared in confidence only with a particular, trusted		needs to be shared in confidence only with a particular, trusted
	network element or endpoint, or there's a danger of an attack where		network element or endpoint, or there's a danger of an attack where
	someone else may forge messages that could endanger the		someone else may forge messages that could endanger the
	communication.		communication.
	Authenticated integrity protections on signalled data can help ensure		Authenticated integrity protections on signalled data can help ensure
	that data received in a signal has not been modified by other		that data received in a signal has not been modified by other
	parties, but both network elements and endpoints need to be careful		parties. Still, both network elements and endpoints need to be
	in processing or responding to any signal. Whether through bugs or		careful in processing or responding to any signal. Whether through
	attacks, the content of path signals can lead to unexpected behaviors		bugs or attacks, the content of path signals can lead to unexpected
	or security vulnerabilities if not properly handled. As a result,		behaviors or security vulnerabilities if not properly handled. As a
	the advice in Section 2.5 still applies even in situations where		result, the advice in Section 2.5 still applies even in situations
	there's a secure channel for sending information.		where there's a secure channel for sending information.
	However, it is important to note that authentication does not equal		However, it is important to note that authentication does not equal
	trust. Whether a communication is with an application server or		trust. Whether a communication is with an application server or
	network element that can be shown to be associated with a particular		network element that can be shown to be associated with a particular
	domain name, it does not follow that information about the user can		domain name, it does not follow that information about the user can
	be safely sent to it.		be safely sent to it.
	In some cases, the ability of a party to show that it is on the path		In some cases, the ability of a party to show that it is on the path
	can be beneficial. For instance, an ICMP error that refers to a		can be beneficial. For instance, an ICMP error that refers to a
	valid flow may be more trustworthy than any ICMP error claiming to		valid flow may be more trustworthy than any ICMP error claiming to
	skipping to change at page 9, line 40		skipping to change at page 9, line 41
	network and application. Or technologies such as confidential		network and application. Or technologies such as confidential
	computing can be applied to provide an assurance that information		computing can be applied to provide an assurance that information
	processed by a party is handled in an appropriate manner.		processed by a party is handled in an appropriate manner.
	2.4. Minimize Information		2.4. Minimize Information
	Each party should provide only the information that is needed for the		Each party should provide only the information that is needed for the
	other parties to perform the task for which collaboration is desired,		other parties to perform the task for which collaboration is desired,
	and no more. This applies to information sent by an application		and no more. This applies to information sent by an application
	about itself, information sent about users, or information sent by		about itself, information sent about users, or information sent by
	the network.		the network. This also applies to any information related to flow
			identification.
	An architecture can follow the guideline from RFC 8558 in using		An architecture can follow the guideline from [RFC8558] in using
	explicit signals, but still fail to differentiate properly between		explicit signals, but still fail to differentiate properly between
	information that should be kept private and information that should		information that should be kept private and information that should
	be shared.		be shared. [RFC6973] also outlines this principle of data
			minimization as mitigation technique to protect privacy and provides
			further guidance.
	In looking at what information can or cannot easily be passed, we		In looking at what information can or cannot easily be passed, we
	need to consider both, information from the network to the		need to consider both, information from the network to the
	application and from the application to the network.		application and from the application to the network.
	For the application to the network direction, user-identifying		For the application to the network direction, user-identifying
	information can be problematic for privacy and tracking reasons.		information can be problematic for privacy and tracking reasons.
	Similarly, application identity can be problematic, if it might form		Similarly, application identity can be problematic, if it might form
	the basis for prioritization or discrimination that the application		the basis for prioritization or discrimination that the application
	provider may not wish to happen.		provider may not wish to happen.
	skipping to change at page 11, line 45		skipping to change at page 11, line 49
	There is a tradeoff here between flexibility and ensuring the		There is a tradeoff here between flexibility and ensuring the
	minimality of information in the future. The concern is that a fully		minimality of information in the future. The concern is that a fully
	generic data sharing approach between different layers and parties		generic data sharing approach between different layers and parties
	could potentially be misused, e.g., by making the availability of		could potentially be misused, e.g., by making the availability of
	some information a requirement for passing through a network, such as		some information a requirement for passing through a network, such as
	making it mandatory to identify specific applications or users. This		making it mandatory to identify specific applications or users. This
	is undesirable.		is undesirable.
	This document recommends that signalling mechanisms that send		This document recommends that signalling mechanisms that send
	information are built to specifically support sending the necessary,		information are built to specifically support sending the necessary,
	minimal set of information (see Section 2.4) and no more. Such		minimal set of information (see Section 2.4) and no more. As
	mechanisms also need have an ability for establishing an agreement		previously noted, flow-identifying information is a path signal in
	(see Section 2.2) and to establish sufficient trust to pass the		itself, and as such provisioning of flow identifiers also requires
	information (see Section 2.3).		protocol specific analysis.
			Further, such mechanisms also need have an ability for establishing
			an agreement (see Section 2.2) and to establish sufficient trust to
			pass the information (see Section 2.3).
	3. Further Work		3. Further Work
	This is a developing field, and it is expected that our understanding		This is a developing field, and it is expected that our understanding
	will continue to grow. One recent change is much higher use of		will continue to grow. One recent change is much higher use of
	encryption at different protocol layers. This obviously impacts the		encryption at different protocol layers. This obviously impacts the
	field greatly, by removing the ability to use most implicit signals.		field greatly, by removing the ability to use most implicit signals.
	But it may also provide new tools for secure collaboration, and force		But it may also provide new tools for secure collaboration, and force
	a rethinking of how collaboration should be performed.		a rethinking of how collaboration should be performed.
	skipping to change at page 12, line 40		skipping to change at page 12, line 46
	which may or may not be easy to put in place. For instance, some		which may or may not be easy to put in place. For instance, some
	quality-of-service mechanisms involve an expectation of paying for		quality-of-service mechanisms involve an expectation of paying for
	a service. This is possible and has been successful within		a service. This is possible and has been successful within
	individual domains, e.g., users can pay for higher data rates or		individual domains, e.g., users can pay for higher data rates or
	data caps in their ISP networks. However, it is a business-wise		data caps in their ISP networks. However, it is a business-wise
	much harder proposition for end-to-end connections across multiple		much harder proposition for end-to-end connections across multiple
	administrative domains [Claffy2015] [RFC9049].		administrative domains [Claffy2015] [RFC9049].
	o Secure communications with path elements is needed as discussed in		o Secure communications with path elements is needed as discussed in
	Section 2.3. Finding practical ways for this has been difficult,		Section 2.3. Finding practical ways for this has been difficult,
	however, both from the mechanics and scalability point view. And		both from the mechanics and scalability point view. And also
	also because there is no easy way to find out which parties to		because there is no easy way to find out which parties to trust or
	trust or what trust roots would be appropriate. Some application-		what trust roots would be appropriate. Some application-network
	network element interaction designs have focused on information		element interaction designs have focused on information (such as
	(such as ECN bits) that is distributed openly within a path, but		ECN bits) that is distributed openly within a path, but there are
	there are limited examples of designs with secure information		limited examples of designs with secure information exchange with
	exchange with specific network elements or endpoints.		specific network elements or endpoints.
	o The use of path signals for reducing the effects of denial-of-		o The use of path signals for reducing the effects of denial-of-
	service attacks, e.g., perhaps modern forms of "source quench"		service attacks, e.g., perhaps modern forms of "source quench"
	designs could be developed. The difficulty is finding a solution		designs could be developed. The difficulty is finding a solution
	that would be both effective against attacks and would not enable		that would be both effective against attacks and would not enable
	third parties from slowing down or censoring someone else's		third parties from slowing down or censoring someone else's
	commmunication.		commmunication.
	o Ways of protecting information when held by network elements or		o Ways of protecting information when held by network elements or
	servers, beyond communications security. For instance, host		servers, beyond communications security. For instance, host
	skipping to change at page 14, line 9		skipping to change at page 14, line 17
	The authors would like to thank everyone at the IETF, the IAB, and		The authors would like to thank everyone at the IETF, the IAB, and
	our day jobs for interesting thoughts and proposals in this space.		our day jobs for interesting thoughts and proposals in this space.
	Fragments of this document were also in		Fragments of this document were also in
	[I-D.per-app-networking-considerations] and		[I-D.per-app-networking-considerations] and
	[I-D.arkko-path-signals-information] that were published earlier. We		[I-D.arkko-path-signals-information] that were published earlier. We
	would also like to acknowledge [I-D.trammell-stackevo-explicit-coop]		would also like to acknowledge [I-D.trammell-stackevo-explicit-coop]
	for presenting similar thoughts. Finally, the authors would like to		for presenting similar thoughts. Finally, the authors would like to
	thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark		thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
	Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew		Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
	Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, Mallory		Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, Mallory
	Knodel, Zhenbin Li, and Jeffrey Haas for useful feedback in the		Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for useful feedback
	IABOPEN sessions and on the list.		on this topic and this draft.
	5. Informative References		5. Informative References
	[Claffy2015]		[Claffy2015]
	kc Claffy, . and D. Clark, "Adding Enhanced Services to		kc Claffy, . and D. Clark, "Adding Enhanced Services to
	the Internet: Lessons from History", TPRC 43: The 43rd		the Internet: Lessons from History", TPRC 43: The 43rd
	Research Conference on Communication, Information and		Research Conference on Communication, Information and
	Internet Policy Paper , April 2015.		Internet Policy Paper , April 2015.
	[I-D.arkko-dns-confidential]		[I-D.arkko-dns-confidential]
	Ericsson and Ericsson, "Privacy Improvements for DNS		Jari Arkko, and Jiri Novotny, "Privacy Improvements for
	Resolution with Confidential Computing", draft-arkko-dns-		DNS Resolution with Confidential Computing", draft-arkko-
	confidential-02 (work in progress), July 2021.		dns-confidential-02 (work in progress), July 2021,
			<https://www.ietf.org/archive/id/draft-arkko-dns-
			confidential-02.txt>.
	[I-D.arkko-path-signals-information]		[I-D.arkko-path-signals-information]
	Ericsson, "Considerations on Information Passed between		Jari Arkko, , "Considerations on Information Passed
	Networks and Applications", draft-arkko-path-signals-		between Networks and Applications", draft-arkko-path-
	information-00 (work in progress), February 2021.		signals-information-00 (work in progress), February 2021,
			<https://www.ietf.org/archive/id/draft-arkko-path-signals-
			information-00.txt>.
	[I-D.flinck-mobile-throughput-guidance]		[I-D.flinck-mobile-throughput-guidance]
	, , , , , , , and , "Mobile Throughput Guidance Inband		Ankur Jain, , Andreas Terzis, , Hannu Flinck, , Nurit
	Signaling Protocol", draft-flinck-mobile-throughput-		Sprecher, , Swaminathan Arunachalam, , Kevin Smith, ,
	guidance-04 (work in progress), March 2017.		Vijay Devarapalli, , and Roni Bar Yanai, "Mobile
			Throughput Guidance Inband Signaling Protocol", draft-
			flinck-mobile-throughput-guidance-04 (work in progress),
			March 2017, <https://www.ietf.org/archive/id/draft-flinck-
			mobile-throughput-guidance-04.txt>.
	[I-D.ietf-quic-manageability]		[I-D.ietf-quic-manageability]
	Ericsson and Google Switzerland GmbH, "Manageability of		Mirja Kuehlewind, and Brian Trammell, "Manageability of
	the QUIC Transport Protocol", draft-ietf-quic-		the QUIC Transport Protocol", draft-ietf-quic-
	manageability-17 (work in progress), July 2022.		manageability-18 (work in progress), July 2022,
			<https://www.ietf.org/archive/id/draft-ietf-quic-
			manageability-18.txt>.
	[I-D.per-app-networking-considerations]		[I-D.per-app-networking-considerations]
	Google and Apple Inc., "Per-Application Networking		Lorenzo Colitti, and Tommy Pauly, "Per-Application
	Considerations", draft-per-app-networking-		Networking Considerations", draft-per-app-networking-
	considerations-00 (work in progress), November 2020.		considerations-00 (work in progress), November 2020,
			<https://www.ietf.org/archive/id/draft-per-app-networking-
			considerations-00.txt>.
	[I-D.thomson-http-oblivious]		[I-D.thomson-http-oblivious]
	Mozilla and Cloudflare, "Oblivious HTTP", draft-thomson-		Martin Thomson, and A. Christopher Wood, "Oblivious HTTP",
	http-oblivious-02 (work in progress), August 2021.		draft-thomson-http-oblivious-02 (work in progress), August
			2021, <https://www.ietf.org/archive/id/draft-thomson-http-
			oblivious-02.txt>.
	[I-D.trammell-stackevo-explicit-coop]		[I-D.trammell-stackevo-explicit-coop]
	"Architectural Considerations for Transport Evolution with		Brian Trammell, , "Architectural Considerations for
	Explicit Path Cooperation", draft-trammell-stackevo-		Transport Evolution with Explicit Path Cooperation",
	explicit-coop-00 (work in progress), September 2015.		draft-trammell-stackevo-explicit-coop-00 (work in
			progress), September 2015,
			<https://www.ietf.org/archive/id/draft-trammell-stackevo-
			explicit-coop-00.txt>.
	[I-D.yiakoumis-network-tokens]		[I-D.yiakoumis-network-tokens]
	Selfie Networks, Stanford University, and Norwegian		Yiannis Yiakoumis, , Nick McKeown, , and Frode Sorensen,
	Communications Authority, "Network Tokens", draft-		"Network Tokens", draft-yiakoumis-network-tokens-02 (work
	yiakoumis-network-tokens-02 (work in progress), December		in progress), December 2020,
	2020.		<https://www.ietf.org/archive/id/draft-yiakoumis-network-
			tokens-02.txt>.
	[Oblivious]		[Oblivious]
	Schmitt, P., "Oblivious DNS: Practical privacy for DNS		Schmitt, P., "Oblivious DNS: Practical privacy for DNS
	queries", Proceedings on Privacy Enhancing Technologies		queries", Proceedings on Privacy Enhancing Technologies
	2019.2: 228-244 , 2019.		2019.2: 228-244 , 2019.
	[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private		[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
	DNS-over-TLS with TEE Support", Digit. Threat.: Res.		DNS-over-TLS with TEE Support", Digit. Threat.: Res.
	Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/		Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/
	fullHtml/10.1145/3431171 , February 2021.		fullHtml/10.1145/3431171 , February 2021.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		DOI 10.17487/RFC0793, September 1981, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc793>.		editor.org/info/rfc793>.
	[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful		[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
	Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,		Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
	<https://www.rfc-editor.org/info/rfc5218>.		<https://www.rfc-editor.org/info/rfc5218>.
	[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design		[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
	Considerations for Protocol Extensions", RFC 6709,		Considerations for Protocol Extensions", RFC 6709,
	DOI 10.17487/RFC6709, September 2012, <https://www.rfc-		DOI 10.17487/RFC6709, September 2012, <https://www.rfc-
	editor.org/info/rfc6709>.		editor.org/info/rfc6709>.
			[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
			Morris, J., Hansen, M., and R. Smith, "Privacy
			Considerations for Internet Protocols", RFC 6973,
			DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
			editor.org/info/rfc6973>.
	[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of		[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
	Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,		Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
	February 2014, <https://www.rfc-editor.org/info/rfc7129>.		February 2014, <https://www.rfc-editor.org/info/rfc7129>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet		[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
	Technology Adoption and Transition (ITAT)", RFC 7305,		Technology Adoption and Transition (ITAT)", RFC 7305,
End of changes. 39 change blocks.
	110 lines changed or deleted		140 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/