draft-iab-path-signals-collaboration-00.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: September 8, 2022 Cisco Expires: January 12, 2023 Cisco
T. Pauly T. Pauly
Apple Apple
M. Kühlewind M. Kuehlewind
Ericsson Ericsson
March 07, 2022 July 11, 2022
Considerations on Application - Network Collaboration Using Path Signals Considerations on Application - Network Collaboration Using Path Signals
draft-iab-path-signals-collaboration-00 draft-iab-path-signals-collaboration-01
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 September 8, 2022. This Internet-Draft will expire on January 12, 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
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Intentional Distribution . . . . . . . . . . . . . . . . 6 2.1. Intentional Distribution . . . . . . . . . . . . . . . . 7
2.2. Minimum Set of Entities . . . . . . . . . . . . . . . . . 7 2.2. Control of the Distribution of Information . . . . . . . 7
2.3. Control of the Distribution of Information . . . . . . . 7 2.3. Protecting Information and Authentication . . . . . . . . 8
2.4. Minimize Information . . . . . . . . . . . . . . . . . . 8 2.4. Minimize Information . . . . . . . . . . . . . . . . . . 9
2.5. Carrying Information . . . . . . . . . . . . . . . . . . 9 2.5. Limiting Impact of Information . . . . . . . . . . . . . 10
2.6. Protecting Information and Authentication . . . . . . . . 9 2.6. Minimum Set of Entities . . . . . . . . . . . . . . . . . 11
2.7. Limiting Impact of Information . . . . . . . . . . . . . 10 2.7. Carrying Information . . . . . . . . . . . . . . . . . . 11
3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
5. Informative References . . . . . . . . . . . . . . . . . . . 12 5. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RFC 8558 defines the term "path signals" as signals to or from on- RFC 8558 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 deployed 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 Such techniques had some drawbacks as well, such as having to
interpret information designed to be carried for another purpose. interpret information designed to be carried for one purpose for a
new, different purpose.
Today, applications and networks have often evolved their interaction Today, applications and networks have often evolved their interaction
without comprehensive design for how this interaction should happen without comprehensive design for how this interaction should happen
or which information would be desired for a certain function. This or which information would be needed for a certain function. This
has lead to a situation where sometimes information is used that has led to a situation where sometimes information that happens to be
maybe incomplete, incorrect, or only indirectly representative of the easily available is used. But that information may be incomplete,
information that was actually desired. In addition, dependencies on incorrect, or only indirectly representative of the information that
information and mechanisms that were designed for a different is actually needed. In addition, dependencies on information and
function limits the evolvability of the protocols in question. 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: The unplanned interaction ends up having several negative effects:
o Ossifying protocols by introducing unintended parties that may not o Ossifying protocols by introducing dependencies to unintended
be updating parties that may not be updating, such as how middleboxes have
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
o Creating a model where network entities expect to be able to use o 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 portal MAC addresses have been used for access control, captive portals have
implementations that employ taking over cleartext HTTP sessions, and been used to take over cleartext HTTP sessions, and so on. (This
so on. document is not about whether those practices are good or bad, it is
simply stating a fact that the features were used beyond their
original intent.)
A large number of protocol mechanisms today 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 the a very limited set nodes, often one on each "end"; and visible to a very limited set of parties, often one on each "end";
unauthenticated public communication that is visible to all nodes on and unauthenticated public communication that is also visible to all
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 signaling, 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 be harmful to network management, debugging, or the ability
for networks to provide the most efficient services. There are many for networks to provide the most efficient services. There are many
cases where elements on the network path can provide beneficial cases where elements on the network path can provide beneficial
services, but only if they can coordinate with the endpoints. It services, but only if they can coordinate with the endpoints. It
also affects the ability of service providers and others to observe also affects the ability of service providers and others to observe
why problems occur [RFC9075]. why problems occur [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 reveal
network topology or the status of other users, and so on. 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 controling information access and Encryption provides tools for controlling information access and
protects again 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 The increased deployment of encryption provides an opportunity to
reconsider parts of Internet architecture that have used implicit reconsider parts of Internet architecture that have used implicit
derivation of input signals for on-path functions rather than derivation of input signals for on-path functions rather than
explicit signaling, as recommended by RFC 8558 [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 be 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
skipping to change at page 4, line 44 skipping to change at page 4, line 50
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 optimize behavior or gain access to specific resources.
Authentication and trust must be considered in multiple directions: Authentication and trust must be considered in multiple directions:
how endpoints trust and authenticate signals from network devices, how endpoints trust and authenticate signals from network devices,
and how network devices trust and authenticate signals from and how network devices 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 protocols to support these functions are achieved and design new ways to support explicit
explicit collaboration where it is seen as beneficial. As such our collaboration where it is seen as beneficial. As such our goals
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;
o to understand the privacy and other implications of any o to understand the privacy and other implications of any
distributed information; distributed information;
o to ensure that the information distribution is limited the o to 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 o to gate the distribution of information on the participation of
the relevant parties the 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 functions
should consider: should consider:
o What is the minimum set of entities that need to be involved? o Which entities must consent to the information exchange?
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 Which entities must consent to the information exchange?
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 right mechanism and needed level of trust to convey
this kind of information?
If we look at many of the ways network functions are achieved today, If we look at many of the ways network functions are achieved today,
we find that many if not most of them fall short the standard set up we find that many if not most of them fall short the standard set up
by the questions above. Too often, they send unnecessary information by the questions above. Too often, they send unnecessary information
or fail to limit the scope of distribution or providing any or fail to limit the scope of distribution or providing any
negotiation 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 other information is appropriately protected, and ensuring that all information is appropriately protected, enables
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. This improving the quality of experience and network management. The
kind of cleanly separated architecture is also more conducive to clean separation provided by explicit signals is also more conducive
protocol evolvability. to protocol evolvability.
This draft discusses different approaches for explicit collaboration
and provides guidance on architectural principles to design new
mechanisms. Section 2 discusses principles that good design can
follow. This section also provides some examples and explanation of
situations that not following the principles can lead to. Section 3
points to topics that need more to be looked at more carefully before
any guidance can be given.
Beyond the recommandation 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 recommended reading on this
same general topic. [RFC9049], an IRTF document, provides a same general topic. [RFC9049], an IRTF document, provides a
catalogue of past issues to avoid and discusses incentives for catalogue of past issues to avoid and discusses incentives for
adoption of path signals such as the need for outperforming end-to- adoption of path signals such as the need for outperforming end-to-
end mechanisms or considering per-connection state. end mechanisms or considering per-connection state.
This draft discusses different approaches for explicit collaboration
and provides guidance on architectural principles to design new
mechanisms. Section 2 discusses principles that good design can
follow. This section also provides some examples and explanation of
situations that not following the principles can lead to. Section 3
points to topics that need more to be looked at more carefully 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 signaling. and signalling.
While RFC 8558 [RFC8558] focused specifically on "on-path elements", While RFC 8558 [RFC8558] focused specifically on communication to
the principles described in this document can be applied both to on- "on-path elements", the principles described in this document apply
path signalling and signalling with other elements in the network potentially to
that are not directly on-path, but still influence end-to-end
connections. An example of on-path signalling is communication o on-path signalling, in either direction
between an endpoint and a router on a network path. An example of
signalling with another network element is communication between an o signalling with other elements in the network that are not
endpoint and a network-assigned DNS server, firewall controller, or directly on-path, but still influence end-to-end connections.
captive portal API server.
An example of on-path signalling is communication between an endpoint
and a router on a network path. An example of signalling with
another network element is communication between an endpoint and a
network-assigned DNS server, firewall controller, or captive portal
API server. Note that these communications are conceptually
independent of the base flow, even if they share a packet; they are
from and to other parties, rather than creating a multiparty
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. consent and trust need to be applied. Given the known threat of
pervasive monitoring, the application of these principles is critical
to ensuring that the use of path signals does not create a
disproportionate opportunity for observers to extract new data from
flows.
2.1. Intentional Distribution 2.1. Intentional Distribution
This guideline is best expressed in RFC 8558: This guideline is best expressed in RFC 8558:
"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."
This guideline applies in the other direction as well. For instance, The goal is that any information should be provided knowingly, for a
a network element should not unintentionally leak information that is specific purpose, sent in signals designed for that purpose, and that
not visible to endpoints. An explicit decision is needed for a any use of information should be done within that purpose. And that
specific information to be provided, along with analysis of the an analysis of the security and privacy implications of the specific
security and privacy implications of that information. purpose and associated information is needed.
2.2. Minimum Set of Entities
It is recommended that a design identifies the minimum number of
entities needed to share a specific signal required for an identified
function.
Often this will be a very limited set, such as when an application This guideline applies in the network element to application
only needs to provide a signal to its peer at the other end of the direction as well: a network element should not unintentionally leak
connection or a host needs to contact a specific VPN gateway. In information. While this document makes recommendations that are
other cases a broader set is neeeded, such as when explicit or applicable to many different situations, it is important to note that
implicit signals from a potentially unknown set of multiple routers the above call for careful analysis is key. Different types of
along the path inform the endpoints about congestion. information, different applications, and different directions of
communication influence the the analysis, and can lead to very
different conclusions about what information can be shared or with
whom. For instance, it is easy to find examples of information that
applications should not share with network elements (e.g., content of
communications) or network elements should not share with
applications (e.g., detailed user location in a wireless network).
But, equally, information about other things such as the onset of
congestion should be possible to share, and can be beneficial
information to all parties.
While it is tempting to consider removing these limitations in the Intentional distribution is a precondition for explicit collaboration
context of closed, private networks, each interaction is still best enabling each entity to have the highest posssible level of control
considered separately, rather than simply allowing all information about what information to share.
exchanges within the closed network. Even in a closed network with
carefully managed elements there may be compromised components, as
evidenced in the most extreme way by the Stuxnet worm that operated
in an airgapped network. Most "closed" networks have at least some
needs and means to access the rest of the Internet, and should not be
modeled as if they had an impenetrable security barrier.
2.3. Control of the Distribution of Information 2.2. Control of the Distribution of Information
Trust and mutual agreement between the involved entities must Explicit signals are not enough. The entities also need to agree to
determine the distribution of information, in order to give adequate exchange the information. Trust and mutual agreement between the
control to each entity over the collaboration or information sharing. involved entities must determine the distribution of information, in
order to give adequate control to each entity over the collaboration
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 agree to sending the information. Any passing of
information or request for an action needs to be explicit, and use information or request for an action needs to be explicit, and use
protocol mechanisms that are designed for the purpose. Merely signalling mechanisms that are designed for the purpose. Merely
sending a particular kind of packet to a destination should not be sending a particular kind of packet to a destination should not be
interpreted as an implicit agreement. 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 agree to receiving the information. It should not be
burdened with extra processing if it does not have willigness or a burdened with extra processing if it does not have willingness or a
need to do so. This happens naturally in most protocol designs, but need to do so. This happens naturally in most protocol designs, but
has been a problem for some cases where "slow path" packet processing has been a problem for some cases where "slow path" packet processing
is required or implied, and the recipient or router is not willing to is required or implied, and the recipient or router is not willing to
handle this. handle this. Performance impacts like this are best avoided,
however.
In both cases, all involved entities must be identified and In any case, all involved entities must be identified and potentially
potentially authenticated if trust is required as a prerequisite to authenticated if trust is required as a prerequisite to share certain
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 senstive 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
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. collect more information about the user than the user would like.
How to achieve a balance of control between the actual user and an How to achieve a balance of control between the actual user and an
application representing an user's interest is out of scope for this application representing an user's interest is out of scope for this
document. document.
2.3. Protecting Information and Authentication
Some simple forms of information often exist in cleartext form, e.g,
ECN bits from routers are generally not authenticated or integrity
protected. This is possible when the information exchanges do not
carry any significantly sensitive information from the parties.
Often these kind of interactions are also advisory in their nature
(see also section Section 2.5).
In other cases it may be necessary to establish a secure signalling
channel for communication with a specific other party, e.g., between
a network element and an application. This channel may need to be
authenticated, integrity protected and confidential. This is
necessary, for instance, if the particular information or request
needs to be shared in confidence only with a particular, trusted
network element or endpoint, or there's a danger of an attack where
someone else may forge messages that could endanger the
communication.
Authenticated integrity protections on signalled data can help ensure
that data received in a signal has not been modified by other
parties, but both network elements and endpoints need to be careful
in processing or responding to any signal. Whether through bugs or
attacks, the content of path signals can lead to unexpected behaviors
or security vulnerabilities if not properly handled. As a result,
the advice in Section 2.5 still applies even in situations where
there's a secure channel for sending information.
However, it is important to note that authentication does not equal
trust. Whether a communication is with an application server or
network element that can be shown to be associated with a particular
domain name, it does not follow that information about the user can
be safely sent to it.
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
valid flow may be more trustworthy than any ICMP error claiming to
come from an address.
Other cases may require more substantial assurances. For instance, a
specific trust arrangement may be established between a particular
network and application. Or technologies such as confidential
computing can be applied to provide an assurance that information
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.
An architecture can follow the guideline from RFC 8558 in using An architecture can follow the guideline from RFC 8558 in using
explicit signals, but still fail to differentiate properly between explicit signals, but still fail to differentiate properly between
skipping to change at page 9, line 13 skipping to change at page 10, line 31
applications can use to determine, for instance, optimal strategies applications can use to determine, for instance, optimal strategies
for changing codecs. However, information given by the network about for changing codecs. However, information given by the network about
load conditions and so on should not form a mechanism to provide a load conditions and so on should not form a mechanism to provide a
side-channel into what other users are doing. 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 than makes specific
requests for action. requests for action.
2.5. Carrying Information 2.5. Limiting Impact of Information
There is a distinction between what information is passed and how it
is carried. The actually sent information may be limited, while the
mechanisms for sending or requesting information can be capable of
sending much more.
There is a tradeoff here between flexibility and ensuring the
minimality of information in the future. The concern is that a fully
generic data sharing approach between different layers and parties
could potentially be misused, e.g., by making the availability of
some information a requirement for passing through a network. This
is undesirable.
This document recommends that the protocols that carry information
are specific to the type of information that is needed to carry the
minimal set of information (see Section 2.4) and can establish
sufficient trust to pass that information (see Section 2.6).
2.6. Protecting Information and Authentication
Some simple forms of information often exist in cleartext form, e.g,
ECN bits from routers are generally not authenticated or integrity
protected. This is possible when the information exchanges do not
carry any significantly sensitive information from the parties.
Often these kind of interations are also advisory in their nature
(see also section {#impact}).
In other cases it may be necessary to establish a secure channel for
communication with a specific other party, e.g., between a network
element and an application. This channel may need to be
authenticated, integrity protected and confidential. This is
necessary, for instance, if the particular information or request
needs to be share in confidence only with a particular, trusted node,
or there's a danger of an attack where someone else may forge
messages that could endanger the communication.
Authenticated integrity protections on signalled data can help ensure
that data received in a signal has not been modified by other
parties, but both network elements and endpoints need to be careful
in processing or responding to any signal. Whether through bugs or
attacks, the content of path signals can lead to unexpected behaviors
or security vulernabilities if not properly handled.
However, it is important to note that authentication does not equal
trust. Whether a communication is with an application server or
network element that can be shown to be associated with a particular
domain name, it does not follow that information about the user can
be safely sent to it.
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
valid flow may be more trustworthy than any ICMP error claiming to
come from an address.
Other cases may require more substantial assurances. For instance, a
specific trust arrangement may be established between a particular
network and application. Or technologies such as confidential
computing can be applied to provide an assurance that information
processed by a party is handled in an appropriate manner.
2.7. 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 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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 to be advisory
information, with the effect of optimizing or adjusting the behavior information, with the effect of optimizing or adjusting the behavior
of connections on a specific path. In the case of a firewall of connections on a specific path. In the case of a firewall
blocking connectivity to a given host, endpoints should only blocking connectivity to a given host, endpoints should only
interpret that as the host being unavailable on that particular path; interpret that as the host being unavailable on that particular path;
this is in contrast to an end-to-end authenticated signal, such as a this is in contrast to an end-to-end authenticated signal, such as a
DNSSEC-authenticated denial of existence [RFC7129]. DNSSEC-authenticated denial of existence [RFC7129].
2.6. Minimum Set of Entities
It is recommended that a design identifies the minimum number of
entities needed to share a specific signal required for an identified
function.
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
connection or a host needs to contact a specific VPN gateway. In
other cases a broader set is needed, such as when explicit or
implicit signals from a potentially unknown set of multiple routers
along the path inform the endpoints about congestion.
While it is tempting to consider removing these limitations in the
context of closed, private networks, each interaction is still best
considered separately, rather than simply allowing all information
exchanges within the closed network. Even in a closed network with
carefully managed elements there may be compromised components, as
evidenced in the most extreme way by the Stuxnet worm that operated
in an airgapped network. Most "closed" networks have at least some
needs and means to access the rest of the Internet, and should not be
modeled as if they had an impenetrable security barrier.
2.7. Carrying Information
There is a distinction between what information is sent and how it is
sent. The actually sent information may be limited, while the
mechanisms for sending or requesting information can be capable of
sharing much more.
There is a tradeoff here between flexibility and ensuring the
minimality of information in the future. The concern is that a fully
generic data sharing approach between different layers and parties
could potentially be misused, e.g., by making the availability of
some information a requirement for passing through a network, such as
making it mandatory to identify specific applications or users. This
is undesirable.
This document recommends that signalling mechanisms that send
information are built to specifically support sending the necessary,
minimal set of information (see Section 2.4) and no more. 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. Among the recent changes are much higher use will continue to grow. One recent change is much higher use of
of encryption at different protocol layers and the consolidation of encryption at different protocol layers. This obviously impacts the
more and more traffic to the same destinations; these have greatly field greatly, by removing the ability to use most implicit signals.
impacted the field. But it may also provide new tools for secure collaboration, and 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, clearly more work is needed. Many complex cases would mechanisms, the list of examples is not long. Clearly more work is
needed, if we wish to realize the potential benefits of collaboration
in further cases. This requires a mindset change, a migration away
from using implicit signals. And of course, we need to choose such
cases where the collaboration can be performed safely, is not a
privacy concern, and the incentives of the relevant parties are
aligned. It should also be noted that many complex cases would
require significant developments in order to become feasible. require significant developments in order to become feasible.
Some of the most difficult areas are listed below. Research on these Some of the most difficult areas are listed below. Research on
topics would be welcome. these topics would be welcome. Note that the topics include both
those dealing directly with on-path network element collaboration, as
well as some adjacent issues that would influence such collaboration.
o Business arrangements. Many designs - for instance those related o Some forms of collaboration may depend on business arrangements,
to quality-of-service - involve an expectation of paying for a which may or may not be easy to put in place. For instance, some
service. This is possible and has been successful within quality-of-service mechanisms involve an expectation of paying for
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. This has been a o Secure communications with path elements is needed as discussed in
difficult topic, both from the mechanics and scalability point Section 2.3. Finding practical ways for this has been difficult,
view, but also because there is no easy way to find out which however, both from the mechanics and scalability point view. And
parties to trust or what trust roots would be appropriate. Some also because there is no easy way to find out which parties to
application-network element interaction designs have focused on trust or what trust roots would be appropriate. Some application-
information (such as ECN bits) that is distributed openly within a network element interaction designs have focused on information
path, but there are limited examples of designs with secure (such as ECN bits) that is distributed openly within a path, but
information exchange with specific nodes. there are limited examples of designs with secure information
exchange with 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., in the form of modern "source quench" service attacks, e.g., perhaps modern forms of "source quench"
designs. designs could be developed. The difficulty is finding a solution
that would be both effective against attacks and would not enable
third parties from slowing down or censoring someone else's
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
applications commonly share sensitive information about the user's applications commonly share sensitive information about the user's
actions with other nodes, starting from basic data such as domain actions with other parties, starting from basic data such as
names learned by DNS infrastructure or source and destination domain names learned by DNS infrastructure or source and
addresses and protocol header information learned by all routers destination addresses and protocol header information learned by
on the path, to detailed end user identity and other information all routers on the path, to detailed end user identity and other
learned by the servers. Some solutions are starting to exist for information learned by the servers. Some solutions are starting
this but are not widely deployed, at least not today [Oblivious] to exist for this but are not widely deployed, at least not today
[PDoT] [I-D.arkko-dns-confidential] [I-D.thomson-http-oblivious]. [Oblivious] [PDoT] [I-D.arkko-dns-confidential]
These solutions address also very specific parts of the issue, and [I-D.thomson-http-oblivious]. These solutions address also very
more work remains. specific parts of the issue, and more work remains.
o Sharing information from networks to applications. There are some o Sharing information from networks to applications. There are some
working examples of this, e.g., ECN. A few other proposals have working examples of this, e.g., ECN. A few other proposals have
been made (see, e.g., [I-D.flinck-mobile-throughput-guidance]), been made (see, e.g., [I-D.flinck-mobile-throughput-guidance]),
but very few of those have seen deployment. but very few of those have seen deployment.
o Sharing information from applications to networks. There are a o Sharing information from applications to networks. There are a
few more working examples of this (see Section 1). However, few more working examples of this (see Section 1). However,
numerous proposals have been made in this space, but most of them numerous proposals have been made in this space, but most of them
have not progressed through standards or been deployed, for a have not progressed through standards or been deployed, for a
variety of reasons [RFC9049]. Several current or recent proposals variety of reasons [RFC9049]. Several current or recent proposals
exist, however, such as [I-D.yiakoumis-network-tokens]. exist, however, such as [I-D.yiakoumis-network-tokens].
o Data privacy regimes generally deal with more issues than merely o Data privacy regimes generally deal with more issues than merely
whether some information is shared with another party or not. For whether some information is shared with another party or not. 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 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
collabration safe and mutually beneficial, but of course,
deployments need to take into account various regulatory and other
policy matters. These include privacy regulation, competitive
issues & network neutrality aspects, and so on.
4. Acknowledgments 4. Acknowledgments
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, and Jeffrey Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, Mallory
Haas for useful feedback in the IABOPEN sessions and on the list. Knodel, Zhenbin Li, and Jeffrey Haas for useful feedback in the
IABOPEN sessions and on the list.
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]
skipping to change at page 13, line 18 skipping to change at page 14, line 38
information-00 (work in progress), February 2021. information-00 (work in progress), February 2021.
[I-D.flinck-mobile-throughput-guidance] [I-D.flinck-mobile-throughput-guidance]
, , , , , , , and , "Mobile Throughput Guidance Inband , , , , , , , and , "Mobile Throughput Guidance Inband
Signaling Protocol", draft-flinck-mobile-throughput- Signaling Protocol", draft-flinck-mobile-throughput-
guidance-04 (work in progress), March 2017. guidance-04 (work in progress), March 2017.
[I-D.ietf-quic-manageability] [I-D.ietf-quic-manageability]
Ericsson and Google Switzerland GmbH, "Manageability of Ericsson and Google Switzerland GmbH, "Manageability of
the QUIC Transport Protocol", draft-ietf-quic- the QUIC Transport Protocol", draft-ietf-quic-
manageability-14 (work in progress), January 2022. manageability-17 (work in progress), July 2022.
[I-D.per-app-networking-considerations] [I-D.per-app-networking-considerations]
Google and Apple Inc., "Per-Application Networking Google and Apple Inc., "Per-Application Networking
Considerations", draft-per-app-networking- Considerations", draft-per-app-networking-
considerations-00 (work in progress), November 2020. considerations-00 (work in progress), November 2020.
[I-D.thomson-http-oblivious] [I-D.thomson-http-oblivious]
Mozilla and Cloudflare, "Oblivious HTTP", draft-thomson- Mozilla and Cloudflare, "Oblivious HTTP", draft-thomson-
http-oblivious-02 (work in progress), August 2021. http-oblivious-02 (work in progress), August 2021.
 End of changes. 50 change blocks. 
200 lines changed or deleted 270 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/