rfc9419.original   rfc9419.txt 
Network Working Group J. Arkko Internet Architecture Board (IAB) J. Arkko
Internet-Draft Ericsson Request for Comments: 9419 Ericsson
Intended status: Informational T. Hardie Category: Informational T. Hardie
Expires: August 5, 2023 Cisco ISSN: 2070-1721 Cisco
T. Pauly T. Pauly
Apple Apple
M. Kuehlewind M. Kuehlewind
Ericsson Ericsson
February 01, 2023 June 2023
Considerations on Application - Network Collaboration Using Path Signals Considerations on Application - Network Collaboration Using Path Signals
draft-iab-path-signals-collaboration-03
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
be used whether it is intended as a signal or not. The principles in used whether or not it is intended as a signal. 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 to 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on August 5, 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9419.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 (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. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Principles
2.1. Intentional Distribution . . . . . . . . . . . . . . . . 7 2.1. Intentional Distribution
2.2. Control of the Distribution of Information . . . . . . . 7 2.2. Control of the Distribution of Information
2.3. Protecting Information and Authentication . . . . . . . . 8 2.3. Protecting Information and Authentication
2.4. Minimize Information . . . . . . . . . . . . . . . . . . 9 2.4. Minimize Information
2.5. Limiting Impact of Information . . . . . . . . . . . . . 10 2.5. Limiting Impact of Information
2.6. Minimum Set of Entities . . . . . . . . . . . . . . . . . 11 2.6. Minimum Set of Entities
2.7. Carrying Information . . . . . . . . . . . . . . . . . . 11 2.7. Carrying Information
3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Further Work
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations
5. Informative References . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 6. Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
[RFC8558] 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; for example,
from cleartext end-to-end information by e.g. examining transport they are derived from cleartext end-to-end information by, e.g.,
protocols. For instance, on-path elements use various fields of the examining transport protocols. For instance, on-path elements use
TCP header [RFC0793] to derive information about end-to-end latency various fields of the TCP header [RFC9293] to derive information
as well as congestion. These techniques have evolved because the about end-to-end latency as well as congestion. These techniques
information was available and its use required no coordination with have evolved because the information was available and its use
anyone. This made such techniques more easily deployable than required no coordination with anyone. This made such techniques more
alternative, potentially more explicit or cooperative, approaches. easily deployable than alternative, potentially more explicit or
cooperative, approaches.
However, this also means that applications and networks have often However, this also means that applications and networks have often
evolved their interaction without comprehensive design for how this evolved their interaction without comprehensive design for how this
interaction should happen or which (minimal) information would be interaction should happen or which (minimal) information would be
needed for a certain function. This has led to a situation where needed for a certain function. This has led to a situation where
simply information that happens to be easily available is used information that happens to be easily available is used instead of
instead the information that would be actually needed. As such that the information that is actually needed. As such, that information
information may be incomplete, incorrect, or only indirectly may be incomplete, incorrect, or only indirectly representative of
representative of the information that is actually needed. In the information that is actually needed. In addition, dependencies
addition, dependencies on information and mechanisms that were on information and mechanisms that were designed for a different
designed for a different function limits the evolvability of the function limit the evolvability of the protocols in question.
protocols in question.
In summary, such unplanned interactions end up having several In summary, such unplanned interactions end up having several
negative effects: negative effects:
o Ossifying protocols by introducing dependencies to unintended * 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 * 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 * Basing network behavior on information that may be incomplete or
incorrect incorrect
o Creating a model where network entities expect to be able to use * Creating a model where network entities expect to be able to use
rich information about sessions passing through rich information about sessions passing through
For instance, features such as DNS resolution or TLS setup have been For instance, features such as DNS resolution or TLS setup have been
used beyond their original intent, such as in name-based filtering. used beyond their original intent, such as in name-based filtering.
MAC addresses have been used for access control, captive portals have Media Access Control (MAC) addresses have been used for access
been used to take over cleartext HTTP sessions, and so on. (This control, captive portals have been used to take over cleartext HTTP
document is not about whether those practices are good or bad, it is sessions, and so on. (This document is not about whether those
simply stating a fact that the features were used beyond their practices are good or bad; it is simply stating a fact that the
original intent.) features were used beyond their original intent.)
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 private communication that is only visible
visible to a very limited set of parties, often one on each "end"; to a very limited set of parties, often one on each "end", and
and unauthenticated public communication that is also visible to all unauthenticated public communication that is visible to all network
network elements on a path. 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 [RFC7258]. It may also be used for commercial purposes
purposes, or form a basis for filtering that the applications or or to form a basis for filtering that the applications or users do
users do not desire. But a lack of all path signalling, on the other not desire. However, a lack of all path signaling, on the other
hand, may limit network management, debugging, or the ability for hand, may limit network management, debugging, or the ability for
networks to optimize their services. There are many cases where networks to optimize their services. There are many cases where
elements on the network path can provide beneficial services, but elements on the network path can provide beneficial services, but
only if they can coordinate with the endpoints. It also affects the only if they can coordinate with the endpoints. It also affects the
ability of service providers and others to observe why problems occur ability of service providers and others to observe 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 trade-off
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 to Similarly, network congestion status information does not have to
reveal network topology or the status of other users, and so on. reveal network topology, 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. The increased deployment of encryption requiring active maintenance. The increased deployment of encryption
provides an opportunity to reconsider parts of Internet architecture provides an opportunity to reconsider parts of Internet architecture
that have used implicit derivation of input signals for on-path that have used implicit derivation of input signals for on-path
functions rather than explicit signalling, as recommended by RFC 8558 functions rather than explicit signaling, as recommended by
[RFC8558]. [RFC8558].
For instance, QUIC replaces TCP for various applications and ensures For instance, QUIC replaces TCP for various applications and protects
end-to-end signals are only accessible by the endpoints, ensuring end-to-end signals so that they are only accessible by the endpoints,
evolvability [RFC9000]. QUIC does expose information dedicated for ensuring evolvability [RFC9000]. QUIC does expose information
on-path elements to consume by using explicit signals for specific dedicated for on-path elements to consume by using explicit signals
use cases, such as the Spin bit for latency measurements or for specific use cases, such as the Spin Bit for latency measurements
connection ID that can be used by load balancers or connection ID that can be used by load balancers [RFC9312]. This
[I-D.ietf-quic-manageability]. This information is accessible by all information is accessible by all on-path devices, but information is
on-path devices but information is limited to only those use cases. limited to only those use cases. Each new use case requires
Each new use case requires additional action. This points to one way additional action. This points to one way to resolve the adversity:
to resolve the adversity: the careful design of what information is 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
specific entities, endpoints as well as network path elements. VPNs specific entities, endpoints, and network path elements. VPNs are a
are a good example of a case where there is an explicit good example of a case where there is an explicit authentication and
authentication and negotiation with a network path element that is negotiation with a network path element that is used to gain access
used to gain access to specific resources. Authentication and trust to specific resources. Authentication and trust must be considered
must be considered in both directions: how endpoints trust and in both directions: how endpoints trust and authenticate signals from
authenticate signals from network path elements, and how network path network path elements and how network path elements trust and
elements trust and authenticate signals from endpoints. authenticate signals from 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 to:
o To ensure that information is distributed intentionally, not * ensure that information is distributed intentionally, not
accidentally; accidentally;
o to understand the privacy and other implications of any * understand the privacy and other implications of any distributed
distributed information; information;
o to ensure that the information distribution is limited to the * ensure that the information distribution is limited to the
intended parties; and intended parties; and
o to gate the distribution of information on the participation of * gate the distribution of information on the participation of the
the relevant parties. relevant parties.
These goals for exposure and distribution apply equally to senders, These goals for exposure and distribution apply equally to senders,
receivers, and path elements. receivers, and path elements.
Going forward, new standards work in the IETF needs to focus on Going forward, new standards work in the IETF needs to focus on
addressing this gap by providing better alternatives and mechanisms addressing this gap by providing better alternatives and mechanisms
for building functions that require some collaboration between for building functions that require some collaboration between
endpoints and path elements. endpoints and path elements.
We can establish some basic questions that any new network functions We can establish some basic questions that any new network function
should consider: should consider:
o Which entities must consent to the information exchange? * Which entities must consent to the information exchange?
o What is the minimum information each entity in this set needs? * What is the minimum information each entity in this set needs?
o What is the effect that new signals should have? * What is the effect that new signals should have?
o What is the minimum set of entities that need to be involved? * 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 * What are the right mechanism and needed level of trust to convey
this kind of information? this kind of information?
If we look ways network functions are achieved today, we find that If we look at ways network functions are achieved today, we find that
many if not most of them fall short the standard set up by the many, if not most of them, fall short of the standard set up by the
questions above. Too often, they send unnecessary information or questions above. Too often, they send unnecessary information, fail
fail to limit the scope of distribution or providing any negotiation to limit the scope of distribution, or fail to provide any
or consent. negotiation 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]
provides general advice on incremental deployability based on an provides general advice on incremental deployability based on an
analysis of successes and failures and [RFC6709] discusses protocol analysis of successes and failures, and [RFC6709] discusses protocol
extensibility. The Internet Technology Adoption and Transition extensibility. The Internet Technology Adoption and Transition
(ITAT) workshop report [RFC7305] is also recommended reading on this (ITAT) workshop report [RFC7305] is also a recommended reading on
same general topic. [RFC9049], an IRTF document, provides a this same general topic. [RFC9049], an IRTF document, provides a
catalogue of past issues to avoid and discusses incentives for catalog of past issues to avoid and discusses incentives for adoption
adoption of path signals such as the need for outperforming end-to- of path signals such as the need for outperforming end-to-end
end mechanisms or considering per-connection state. mechanisms or considering per-connection state.
This draft discusses different approaches for explicit collaboration This document discusses different approaches for explicit
and provides guidance on architectural principles to design new collaboration and provides guidance on architectural principles to
mechanisms. Section 2 discusses principles that good design can design new mechanisms. Section 2 discusses principles that good
follow. This section also provides some examples and explanation of design can follow. This section also provides examples and explores
situations that not following the principles can lead to. Section 3 the consequences of not following these principles in those examples.
points to topics that need more to be looked at more carefully before Section 3 points to topics that need to be looked at more carefully
any guidance can be given. before any guidance can be given.
2. Principles 2. Principles
This section provides architecture-level principles for protocol This section provides architecture-level principles for protocol
designers and recommends models to apply for network collaboration designers and recommends models to apply for network collaboration
and signalling. and signaling.
While RFC 8558 [RFC8558] focused specifically on communication to While [RFC8558] focuses specifically on communication to "on-path
"on-path elements", the principles described in this document apply elements", the principles described in this document apply
potentially to potentially to:
o on-path signalling, in either direction * on-path signaling (in either direction) and
o signalling with other elements in the network that are not * signaling with other elements in the network that are not directly
directly on-path, but still influence end-to-end connections. on-path but still influence end-to-end connections.
An example of on-path signalling is communication between an endpoint An example of on-path signaling is communication between an endpoint
and a router on a network path. An example of signalling with and a router on a network path. An example of signaling with another
another network element is communication between an endpoint and a network element is communication between an endpoint and a network-
network-assigned DNS server, firewall controller, or captive portal assigned DNS server, firewall controller, or captive portal API
API server. Note that these communications are conceptually server. Note that these communications are conceptually independent
independent of the base flow, even if they share a packet; they are of the base flow, even if they share a packet; they are coming from
from and to other parties, rather than creating a multiparty and going to other parties, rather than creating a multiparty
communication. communication.
Taken together, these principles focus on the inherent privacy and Taken together, these principles focus on the inherent privacy and
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 [RFC8558]: The following guideline is best expressed in [RFC8558]:
"Fundamentally, this document recommends that implicit signals should | Fundamentally, this document recommends that implicit signals
be avoided and that an implicit signal should be replaced with an | should be avoided and that an implicit signal should be replaced
explicit signal only when the signal's originator intends that it be | with an explicit signal only when the signal's originator intends
used by the network elements on the path. For many flows, this may | that it be used by the network elements on the path. For many
result in the signal being absent but allows it to be present when | flows, this may result in the signal being absent but allows it to
needed." | be present when 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
any use of information should be done within that purpose. And that any use of information should be done within that purpose. In
an analysis of the security and privacy implications of the specific addition, an analysis of the security and privacy implications of the
purpose and associated information is needed. specific purpose and associated information is needed.
This guideline applies in the network element to application This guideline applies in the network element to application
direction as well: a network element should not unintentionally leak direction as well: a network element should not unintentionally leak
information. While this document makes recommendations that are information. While this document makes recommendations that are
applicable to many different situations, it is important to note that applicable to many different situations, it is important to note that
the above call for careful analysis is key. Different types of the above call for careful analysis is key. Different types of
information, different applications, and different directions of information, applications, and directions of communication influence
communication influence the the analysis, and can lead to very the analysis and can lead to very different conclusions about what
different conclusions about what information can be shared or with information can be shared and with whom. For instance, it is easy to
whom. For instance, it is easy to find examples of information that find examples of information that applications should not share with
applications should not share with network elements (e.g., content of network elements (e.g., content of communications) or that network
communications) or network elements should not share with elements should not share with applications (e.g., detailed user
applications (e.g., detailed user location in a wireless network). location in a wireless network). But, equally, information about
But, equally, information about other things such as the onset of other things, such as the onset of congestion, should be possible to
congestion should be possible to share, and can be beneficial share and can be beneficial information to all parties.
information to all parties.
Intentional distribution is a precondition for explicit collaboration Intentional distribution is a precondition for explicit collaboration
enabling each entity to have the highest posssible level of control that enables each entity to have the highest possible level of
about what information to share. control 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 each entity adequate control over the collaboration or
or information sharing. This can be achieved as discussed below. information sharing. This can be achieved as discussed below.
The sender needs to decide that it is willing to send information to The sender needs to decide that it is willing to send information to
a specific entity or set of entities. Any passing of information or a specific entity or set of entities. Any passing of information or
request for an action needs to be explicit, and use signalling request for an action needs to be explicit and use signaling
mechanisms that are designed for the purpose. Merely sending a mechanisms that are designed for the purpose. Merely sending a
particular kind of packet to a destination should not be interpreted particular kind of packet to a destination should not be interpreted
as an implicit agreement. 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 have the option to agree or deny to receiving the request should have the option to agree or deny to receiving the
information. It should not be burdened with extra processing if it information. It should not be burdened with extra processing if it
does not have willingness or a need to do so. This happens naturally does not have willingness or a need to do so. This happens naturally
in most protocol designs, but has been a problem for some cases where in most protocol designs, but it has been a problem for some cases
"slow path" packet processing is required or implied, and the where "slow path" packet processing is required or implied, and the
recipient or router is not willing to handle this. Performance recipient or router is not willing to handle it. Performance impacts
impacts like this are best avoided, however. 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 shared information must be
evaluated carefully to identify potential privacy implications for evaluated carefully to identify potential privacy implications for
users. Information that directly relates to the user should not be users. Information that directly relates to the user should not be
shared without the user's consent. It should be noted that the shared without the user's consent. It should be noted that the
interests of the user and other parties, such as the application interests of the user and other parties, such as the application
developer, may not always coincide; some applications may wish to developer, may not always coincide; some applications may wish to
collect more information about the user than the user would like. As collect more information about the user than the user would like. As
discussed in [RFC8890], from an IETF point view, the interests of the discussed in [RFC8890], from an IETF point of view, the interests of
user should be prioritized over those of the application developer. the user should be prioritized over those of the application
The general issue of how to achieve a balance of control between the developer. The general issue of how to achieve a balance of control
actual user and an application representing an user's interest is out between the actual user and an application representing a user's
of scope for this document. interest is out of scope for this document.
2.3. Protecting Information and Authentication 2.3. Protecting Information and Authentication
Some simple forms of information often exist in cleartext form, e.g, Some simple forms of information often exist in cleartext form, e.g.,
ECN bits from routers are generally not authenticated or integrity Explicit Congestion Notification (ECN) bits from routers are
protected. This is possible when the information exchanges do not generally not authenticated or integrity protected. This is possible
carry any significantly sensitive information from the parties. when the information exchanges do not carry any significantly
Often these kind of interactions are also advisory in their nature sensitive information from the parties. Often, these kinds of
(see also section Section 2.5). interactions are also advisory in their nature (see Section 2.5).
In other cases it may be necessary to establish a secure signalling In other cases, it may be necessary to establish a secure signaling
channel for communication with a specific other party, e.g., between channel for communication with a specific other party, e.g., between
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 if there is 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 signaled 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. Still, both network elements and endpoints need to be parties. Still, both network elements and endpoints need to be
careful in processing or responding to any signal. Whether through careful in processing or responding to any signal. Whether through
bugs or attacks, the content of path signals can lead to unexpected bugs or attacks, the content of path signals can lead to unexpected
behaviors or security vulnerabilities if not properly handled. As a behaviors or security vulnerabilities if not properly handled. As a
result, the advice in Section 2.5 still applies even in situations result, the advice in Section 2.5 still applies even in situations
where 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
skipping to change at page 9, line 33 skipping to change at line 406
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
come from an address. come from an address.
Other cases may require more substantial assurances. For instance, a Other cases may require more substantial assurances. For instance, a
specific trust arrangement may be established between a particular specific trust arrangement may be established between a particular
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, sent about users, or sent by the network. This also
the network. This also applies to any information related to flow applies to any information related to flow identification.
identification.
An architecture can follow the guideline from [RFC8558] 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. [RFC6973] also outlines this principle of data be shared. [RFC6973] also outlines this principle of data
minimization as mitigation technique to protect privacy and provides minimization as a mitigation technique to protect privacy and
further guidance. provides further guidance.
In looking at what information can or cannot easily be passed, we In looking at what information can or cannot be easily passed, we
need to consider both, information from the network to the need to consider both information from the network to the application
application and from the application to the network. and from the application to the network.
For the application to the network direction, user-identifying For the application-to-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.
On the other hand, as noted above, information about general classes On the other hand, as noted above, information about general classes
of applications may be desirable to be given by application of applications may be desirable to be given by application providers
providers, if it enables prioritization that would improve service, if it enables prioritization that would improve service, e.g.,
e.g., differentiation between interactive and non-interactive differentiation between interactive and non-interactive services.
services.
For the network to application direction there is similarly sensitive For the network-to-application direction, there is similarly
information, such as the precise location of the user. On the other sensitive information, such as the precise location of the user. On
hand, various generic network conditions, predictive bandwidth and the other hand, various generic network conditions, predictive
latency capabilities, and so on might be attractive information that bandwidth and latency capabilities, and so on might be attractive
applications can use to determine, for instance, optimal strategies information that applications can use to determine, for instance,
for changing codecs. However, information given by the network about optimal strategies for changing codecs. However, information given
load conditions and so on should not form a mechanism to provide a by the network about load conditions and so on should not form a
side-channel into what other users are doing. mechanism to provide a side channel into what other users are doing.
While information needs to be specific and provided on a per-need While information needs to be specific and provided on a per-need
basis, it is often beneficial to provide declarative information basis, it is often beneficial to provide declarative information
that, for instance, expresses application needs than makes specific that, for instance, expresses application needs and then makes
requests for action. specific requests for action.
2.5. Limiting Impact of Information 2.5. Limiting Impact of Information
Information shared between a network element and an endpoint of a Information shared between a network element and an endpoint of a
connection needs to have a limited impact on the behavior of both connection needs to have a limited impact on the behavior of both
endpoints and network elements. Any action that an endpoint or endpoints and network elements. Any action that an endpoint or
network element takes based on a path signal needs to be considered network element takes based on a path signal needs to be considered
appropriately based on the level of authentication and trust that has appropriately based on the level of authentication and trust that has
been established, and be scoped to a specific network path. been established, and it needs to be scoped to a specific network
path.
For example, an ICMP signal from a network element to an endpoint can For example, an ICMP signal from a network element to an endpoint can
be used to influence future behavior on that particular network path be used to influence future behavior on that particular network path
(such as changing the effective packet size or closing a path- (such as changing the effective packet size or closing a path-
specific connection), but should not be able to cause a multipath or specific connection) but should not be able to cause a multipath or
migration-capable transport connection to close. migration-capable transport connection to close.
In many cases, path signals can be considered to be advisory In many cases, path signals can be considered advisory information,
information, with the effect of optimizing or adjusting the behavior with the effect of optimizing or adjusting the behavior of
of connections on a specific path. In the case of a firewall connections on a specific path. In the case of a firewall blocking
blocking connectivity to a given host, endpoints should only connectivity to a given host, endpoints should only interpret that as
interpret that as the host being unavailable on that particular path; the host being unavailable on that particular path; this is in
this is in contrast to an end-to-end authenticated signal, such as a contrast to an end-to-end authenticated signal, such as a DNSSEC-
DNSSEC-authenticated denial of existence [RFC7129]. authenticated denial of existence [RFC7129].
2.6. Minimum Set of Entities 2.6. Minimum Set of Entities
It is recommended that a design identifies the minimum number of It is recommended that a design identifies the minimum number of
entities needed to share a specific signal required for an identified entities needed to share a specific signal required for an identified
function. function.
Often this will be a very limited set, such as when an application Often, this will be a very limited set, such as when an application
only needs to provide a signal to its peer at the other end of the only needs to provide a signal to its peer at the other end of the
connection or a host needs to contact a specific VPN gateway. In connection or a host needs to contact a specific VPN gateway. In
other cases a broader set is needed, such as when explicit or other cases, a broader set is needed, such as when explicit or
implicit signals from a potentially unknown set of multiple routers implicit signals from a potentially unknown set of multiple routers
along the path inform the endpoints about congestion. along the path inform the endpoints about congestion.
While it is tempting to consider removing these limitations in the While it is tempting to consider removing these limitations in the
context of closed, private networks, each interaction is still best context of closed, private networks, each interaction is still best
considered separately, rather than simply allowing all information considered separately, rather than simply allowing all information
exchanges within the closed network. Even in a closed network with exchanges within the closed network. Even in a closed network with
carefully managed elements there may be compromised components, as carefully managed elements, there may be compromised components, as
evidenced in the most extreme way by the Stuxnet worm that operated evidenced in the most extreme way by the Stuxnet worm that operated
in an airgapped network. Most "closed" networks have at least some in an air-gapped network. Most "closed" networks have at least some
needs and means to access the rest of the Internet, and should not be needs and means to access the rest of the Internet and should not be
modeled as if they had an impenetrable security barrier. modeled as if they had an impenetrable security barrier.
2.7. Carrying Information 2.7. Carrying Information
There is a distinction between what information is sent and how it is There is a distinction between what information is sent and how it is
sent. The actually sent information may be limited, while the sent. The information that is actually sent may be limited, while
mechanisms for sending or requesting information can be capable of the mechanisms for sending or requesting information can be capable
sharing much more. of sharing much more.
There is a tradeoff here between flexibility and ensuring the There is a trade-off here between flexibility and ensuring that the
minimality of information in the future. The concern is that a fully information is minimal 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 signaling mechanisms that send
information are built to specifically support sending the necessary, information be built to specifically support sending the necessary,
minimal set of information (see Section 2.4) and no more. As minimal set of information (see Section 2.4) and no more. As
previously noted, flow-identifying information is a path signal in previously noted, flow-identifying information is a path signal in
itself, and as such provisioning of flow identifiers also requires itself, and as such, provisioning of flow identifiers also requires
protocol specific analysis. protocol-specific analysis.
Further, such mechanisms also need have an ability for establishing Further, such mechanisms also need to have the ability to establish
an agreement (see Section 2.2) and to establish sufficient trust to an agreement (see Section 2.2) and sufficient trust to pass the
pass the information (see Section 2.3). 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 of it 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 However, it may also provide new tools for secure collaboration and
a rethinking of how collaboration should be performed. force a rethinking of how collaboration should be performed.
While there are some examples of modern, well-designed collaboration While there are some examples of modern, well-designed collaboration
mechanisms, the list of examples is not long. Clearly more work is mechanisms, the list of examples is not long. Clearly, more work is
needed, if we wish to realize the potential benefits of collaboration needed if we wish to realize the potential benefits of collaboration
in further cases. This requires a mindset change, a migration away in further cases. This requires a mindset change, a migration away
from using implicit signals. And of course, we need to choose such from using implicit signals. And of course we need to choose such
cases where the collaboration can be performed safely, is not a cases where the collaboration can be performed safely, where it is
privacy concern, and the incentives of the relevant parties are not a privacy concern, and where the incentives of the relevant
aligned. It should also be noted that many complex cases would parties are aligned. It should also be noted that many complex cases
require significant developments in order to become feasible. would require significant developments in order to become feasible.
Some of the most difficult areas are listed below. Research on Some of the most difficult areas are listed below. Research on these
these topics would be welcome. Note that the topics include both topics would be welcome. Note that the topics include both those
those dealing directly with on-path network element collaboration, as dealing directly with on-path network element collaboration and some
well as some adjacent issues that would influence such collaboration. adjacent issues that would influence such collaboration.
o Some forms of collaboration may depend on business arrangements, * Some forms of collaboration may depend on business arrangements,
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 proposition that is much harder for end-to-end connections across
administrative domains [Claffy2015] [RFC9049]. multiple administrative domains [Claffy2015] [RFC9049].
o Secure communications with path elements is needed as discussed in * Secure communication 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,
both from the mechanics and scalability point view. And also both from the mechanics and scalability point of view, partially
because there is no easy way to find out which parties to trust or because there is no easy way to find out which parties to trust or
what trust roots would be appropriate. Some application-network what trust roots would be appropriate. Some application-network
element interaction designs have focused on information (such as element interaction designs have focused on information (such as
ECN bits) that is distributed openly within a path, but there are ECN bits) that is distributed openly within a path, but there are
limited examples of designs with secure information exchange with limited examples of designs with secure information 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- * The use of path signals to reduce the effects of denial-of-service
service attacks, e.g., perhaps modern forms of "source quench" attacks, e.g., perhaps modern forms of "source quench" designs,
designs could be developed. The difficulty is finding a solution could be developed. The difficulty is finding a solution that
that would be both effective against attacks and would not enable would be both effective against attacks and would not enable third
third parties from slowing down or censoring someone else's parties from slowing down or censoring someone else's
commmunication. communication.
o Ways of protecting information when held by network elements or * Work has begun on mechanisms that dissociate the information held
servers, beyond communications security. For instance, host by servers from knowledge of the user's network location and
applications commonly share sensitive information about the user's behavior. Among the solutions that exist for this but are not
actions with other parties, starting from basic data such as widely deployed are [Oblivious] [PDoT] [DNS-CONFIDENTIAL]
domain names learned by DNS infrastructure or source and [HTTP-OBLIVIOUS]. These solutions address specific parts of the
destination addresses and protocol header information learned by issue, and more work remains to find ways to limit the spread of
all routers on the path, to detailed end user identity and other information about the user's actions. Host applications currently
information learned by the servers. Some solutions are starting share sensitive information about the user's action with a variety
to exist for this but are not widely deployed, at least not today of infrastructure and path elements, starting from basic data,
[Oblivious] [PDoT] [I-D.arkko-dns-confidential] such as domain names, source and destination addresses, and
[I-D.thomson-http-oblivious]. These solutions address also very protocol header information. This can expand to detailed end-user
specific parts of the issue, and more work remains. identity and other information learned by the servers. Work to
protect all of this information is needed.
o Sharing information from networks to applications. There are some * Work is needed to explore how to increase the deployment of
working examples of this, e.g., ECN. A few other proposals have mechanisms for sharing information from networks to applications.
been made (see, e.g., [I-D.flinck-mobile-throughput-guidance]), There are some working examples of this, e.g., ECN. A few other
but very few of those have seen deployment. proposals have been made (see, e.g.,
[MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have seen
deployment.
o Sharing information from applications to networks. There are a * Additional work on sharing information from applications to
few more working examples of this (see Section 1). However, networks would also be valuable. There are a few working examples
numerous proposals have been made in this space, but most of them of this (see Section 1). Numerous proposals have been made in
have not progressed through standards or been deployed, for a this space, but most of them have not progressed through standards
variety of reasons [RFC9049]. Several current or recent proposals or been deployed for a variety of reasons [RFC9049]. However,
exist, however, such as [I-D.yiakoumis-network-tokens]. several current or recent proposals exist, such as
[NETWORK-TOKENS].
o Data privacy regimes generally deal with more issues than merely * Data privacy regimes generally deal with multiple issues, not just
whether some information is shared with another party or not. For whether or not some information is shared with another party. For
instance, there may be rules regarding how long information can be instance, there may be rules regarding how long information can be
stored or what purpose information may be used for. Similar stored or what purpose that information may be used for. Similar
issues may also be applicable to the kind of information sharing issues may also be applicable to the kind of information sharing
discussed in this document. discussed in this document.
o The present work has focused on the technical aspects of making * The present work has focused on the technical aspects of making
collabration safe and mutually beneficial, but of course, collaboration safe and mutually beneficial, but of course,
deployments need to take into account various regulatory and other deployments need to take into account various regulatory and other
policy matters. These include privacy regulation, competitive policy matters. These include privacy regulation, competitive
issues & network neutrality aspects, and so on. issues, network neutrality aspects, and so on.
4. Acknowledgments 4. IANA Considerations
The authors would like to thank everyone at the IETF, the IAB, and This document has no IANA actions.
our day jobs for interesting thoughts and proposals in this space.
Fragments of this document were also in
[I-D.per-app-networking-considerations] and
[I-D.arkko-path-signals-information] that were published earlier. We
would also like to acknowledge [I-D.trammell-stackevo-explicit-coop]
for presenting similar thoughts. Finally, the authors would like to
thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David
Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris Box, and
Jeffrey Haas for useful feedback on this topic and this draft.
5. Informative References 5. Security Considerations
This document has no security considerations.
6. Informative References
[Claffy2015] [Claffy2015]
kc Claffy, . and D. Clark, "Adding Enhanced Services to claffy, kc. and D. Clark, "Adding Enhanced Services to the
the Internet: Lessons from History", TPRC 43: The 43rd 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, DOI 10.2139/ssrn.2587262, November
2015, <https://papers.ssrn.com/sol3/
papers.cfm?abstract_id=2587262>.
[I-D.arkko-dns-confidential] [DNS-CONFIDENTIAL]
Arkko, J. and J. Novotny, "Privacy Improvements for DNS Arkko, J. and J. Novotny, "Privacy Improvements for DNS
Resolution with Confidential Computing", draft-arkko-dns- Resolution with Confidential Computing", Work in Progress,
confidential-02 (work in progress), July 2021, Internet-Draft, draft-arkko-dns-confidential-02, 2 July
<https://www.ietf.org/archive/id/draft-arkko-dns- 2021, <https://datatracker.ietf.org/doc/html/draft-arkko-
confidential-02.txt>. dns-confidential-02>.
[I-D.arkko-path-signals-information]
Arkko, J., "Considerations on Information Passed between
Networks and Applications", draft-arkko-path-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]
Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
Arunachalam, S., Smith, K., Devarapalli, V., and R. 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]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-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] [EXPLICIT-COOP]
Colitti, L. and T. Pauly, "Per-Application Networking Trammell, B., Ed., "Architectural Considerations for
Considerations", draft-per-app-networking- Transport Evolution with Explicit Path Cooperation", Work
considerations-00 (work in progress), November 2020, in Progress, Internet-Draft, draft-trammell-stackevo-
<https://www.ietf.org/archive/id/draft-per-app-networking- explicit-coop-00, 23 September 2015,
considerations-00.txt>. <https://datatracker.ietf.org/doc/html/draft-trammell-
stackevo-explicit-coop-00>.
[I-D.thomson-http-oblivious] [HTTP-OBLIVIOUS]
Thomson, M. and C. Wood, "Oblivious HTTP", draft-thomson- Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
http-oblivious-02 (work in progress), August 2021, Progress, Internet-Draft, draft-thomson-http-oblivious-02,
<https://www.ietf.org/archive/id/draft-thomson-http- 24 August 2021, <https://datatracker.ietf.org/doc/html/
oblivious-02.txt>. draft-thomson-http-oblivious-02>.
[I-D.trammell-stackevo-explicit-coop] [MOBILE-THROUGHPUT-GUIDANCE]
Trammell, B., "Architectural Considerations for Transport Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
Evolution with Explicit Path Cooperation", draft-trammell- Arunachalam, S., Smith, K., Devarapalli, V., and R. Bar
stackevo-explicit-coop-00 (work in progress), September Yanai, "Mobile Throughput Guidance Inband Signaling
2015, <https://www.ietf.org/archive/id/draft-trammell- Protocol", Work in Progress, Internet-Draft, draft-flinck-
stackevo-explicit-coop-00.txt>. mobile-throughput-guidance-04, 13 March 2017,
<https://datatracker.ietf.org/doc/html/draft-flinck-
mobile-throughput-guidance-04>.
[I-D.yiakoumis-network-tokens] [NETWORK-TOKENS]
Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
Tokens", draft-yiakoumis-network-tokens-02 (work in Tokens", Work in Progress, Internet-Draft, draft-
progress), December 2020, yiakoumis-network-tokens-02, 21 December 2020,
<https://www.ietf.org/archive/id/draft-yiakoumis-network- <https://datatracker.ietf.org/doc/html/draft-yiakoumis-
tokens-02.txt>. network-tokens-02>.
[Oblivious] [Oblivious]
Schmitt, P., "Oblivious DNS: Practical privacy for DNS Schmitt, P., Edmundson, A., Mankin, A., and N. Feamster,
queries", Proceedings on Privacy Enhancing Technologies "Oblivious DNS: Practical Privacy for DNS Queries",
2019.2: 228-244 , 2019. Proceedings on Privacy Enhancing Technologies, Volume
2019, Issue 2, pp. 228-244, DOI 10.2478/popets-2019-0028,
December 2018, <https://doi.org/10.2478/popets-2019-0028>.
[PATH-SIGNALS-INFO]
Arkko, J., "Considerations on Information Passed between
Networks and Applications", Work in Progress, Internet-
Draft, draft-arkko-path-signals-information-00, 22
February 2021, <https://datatracker.ietf.org/doc/html/
draft-arkko-path-signals-information-00>.
[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", Digital Threats: Research
Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/ and Practice, Volume 2, Issue 1, Article No. 3, pp. 1-22,
fullHtml/10.1145/3431171 , February 2021. DOI 10.1145/3431171, February 2021,
<https://doi.org/10.1145/3431171>.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, [PER-APP-NETWORKING]
DOI 10.17487/RFC0793, September 1981, <https://www.rfc- Colitti, L. and T. Pauly, "Per-Application Networking
editor.org/info/rfc793>. Considerations", Work in Progress, Internet-Draft, draft-
per-app-networking-considerations-00, 15 November 2020,
<https://datatracker.ietf.org/doc/html/draft-per-app-
networking-considerations-00>.
[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,
editor.org/info/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013,
editor.org/info/rfc6973>. <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,
DOI 10.17487/RFC7305, July 2014, <https://www.rfc- DOI 10.17487/RFC7305, July 2014,
editor.org/info/rfc7305>. <https://www.rfc-editor.org/info/rfc7305>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020, <https://www.rfc- DOI 10.17487/RFC8890, August 2020,
editor.org/info/rfc8890>. <https://www.rfc-editor.org/info/rfc8890>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, <https://www.rfc- DOI 10.17487/RFC9000, May 2021,
editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049, Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021, <https://www.rfc- DOI 10.17487/RFC9049, June 2021,
editor.org/info/rfc9049>. <https://www.rfc-editor.org/info/rfc9049>.
[RFC9075] Arkko, J., Farrell, S., Kuehlewind, M., and C. Perkins, [RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
"Report from the IAB COVID-19 Network Impacts Workshop "Report from the IAB COVID-19 Network Impacts Workshop
2020", RFC 9075, DOI 10.17487/RFC9075, July 2021, 2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
<https://www.rfc-editor.org/info/rfc9075>. <https://www.rfc-editor.org/info/rfc9075>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/info/rfc9312>.
IAB Members at the Time of Approval
Internet Architecture Board members at the time this document was
approved for publication were:
Jari Arkko
Deborah Brungard
Lars Eggert
Wes Hardaker
Cullen Jennings
Mallory Knodel
Mirja Kühlewind
Zhenbin Li
Tommy Pauly
David Schinazi
Russ White
Qin Wu
Jiankang Yao
Acknowledgments
The authors would like to thank everyone at the IETF, the IAB, and
our day jobs for interesting thoughts and proposals in this space.
Fragments of this document were also in [PER-APP-NETWORKING] and
[PATH-SIGNALS-INFO]. We would also like to acknowledge that similar
thoughts are presented in [EXPLICIT-COOP]. Finally, the authors
would like to thank Adrian Farrell, Toerless Eckert, Martin Thomson,
Mark Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola,
Andrew Campling, Eliot Lear, Spencer Dawkins, Christian Huitema,
David Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris
Box, and Jeffrey Haas for useful feedback on this topic and document.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
Ted Hardie Ted Hardie
Cisco Cisco
Email: ted.ietf@gmail.com Email: ted.ietf@gmail.com
Tommy Pauly Tommy Pauly
Apple Apple
Email: tpauly@apple.com Email: tpauly@apple.com
Mirja Kuehlewind Mirja Kuehlewind
Ericsson Ericsson
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
 End of changes. 128 change blocks. 
384 lines changed or deleted 408 lines changed or added

This html diff was produced by rfcdiff 1.48.