draft-arkko-iab-path-signals-collaboration-01.txt   draft-iab-path-signals-collaboration.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Hardie Intended status: Informational T. Hardie
Expires: 28 April 2022 Cisco Expires: September 8, 2022 Cisco
T. Pauly T. Pauly
Apple Apple
M. Kühlewind M. Kuehlewind
Ericsson Ericsson
25 October 2021 March 07, 2022
Considerations on Application - Network Collaboration Using Path Signals Considerations on Application - Network Collaboration Using Path Signals
draft-arkko-iab-path-signals-collaboration-01 draft-iab-path-signals-collaboration-00
Abstract Abstract
Encryption and other security mechanisms are on the rise on all This document discusses principles for designing mechanisms that use
layers of the stack, protecting user data and making network or provide path signals, and calls for standards action in specific
operations more secured. Further, encryption is also a tool to valuable cases. RFC 8558 describes path signals as messages to or
address ossification that has been observed over time. Separation of from on-path elements, and points out that visible information will
functions into layers and enforcement of layer boundaries based on be used whether it is intended as a signal or not. The principles in
encryption supports selected exposure to those entities that are this document are intended as guidance for the design of explicit
addressed by a function on a certain layer. A clear separation path signals, which are encouraged to be authenticated and include a
supports innovation and also enables new opportunities for minimal set of parties and minimize information sharing. These
collaborative functions. RFC 8558 describes path signals as messages principles can be achieved through mechanisms like encryption of
to or from on-path elements. This document states principles for information and establishing trust relationships between entities on
designing mechanisms that use or provide path signals and calls for a path.
actions on specific valuable cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://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 28 April 2022. This Internet-Draft will expire on September 8, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. 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
2. Past Guidance . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Intentional Distribution . . . . . . . . . . . . . . . . 6
3.1. Intentional Distribution . . . . . . . . . . . . . . . . 6 2.2. Minimum Set of Entities . . . . . . . . . . . . . . . . . 7
3.2. Minimum Set of Entities . . . . . . . . . . . . . . . . . 7 2.3. Control of the Distribution of Information . . . . . . . 7
3.3. Consent of Parties . . . . . . . . . . . . . . . . . . . 7 2.4. Minimize Information . . . . . . . . . . . . . . . . . . 8
3.4. Minimum Information . . . . . . . . . . . . . . . . . . . 8 2.5. Carrying Information . . . . . . . . . . . . . . . . . . 9
3.5. Carrying Information . . . . . . . . . . . . . . . . . . 9 2.6. Protecting Information and Authentication . . . . . . . . 9
3.6. Protecting Information and Authentication . . . . . . . . 9 2.7. Limiting Impact of Information . . . . . . . . . . . . . 10
4. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
6. Informative References . . . . . . . . . . . . . . . . . . . 11 5. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Encryption, besides its important role in security in general, RFC 8558 defines the term "path signals" as signals to or from on-
provides a tool to control information access and protects again path elements. Today path signals are often implicit, e.g. derived
ossification by avoiding unintended dependencies and requiring active from cleartext end-to-end information by e.g. examining transport
maintenance. The increased deployment of encryption provides an
opportunity to reconsider parts of Internet architecture that have
rather used implicit derivation of input signals for on-path
functions than explicit signaling, as recommended by RFC 8558
[RFC8558].
RFC 8558 defines the term path signals as signals to or from on-path
elements. Today path signals are often implicit, e.g. derived from
in-clear 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 simply available and use of this information is information was available and its use required no coordination with
easier and therefore also cheaper than any explicit and potentially anyone. This made such techniques more easily deployed than
complex cooperative approach. alternative, potentially more explicit or cooperative approaches.
Such techniques had some drawbacks as well, such as having to
interpret information designed to be carried for another purpose.
As such, applications and networks have 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 desired for a certain function. This
has lead to a situation where sometimes information is used that has lead to a situation where sometimes information is used that
maybe incomplete, incorrect, or only indirectly representative of the maybe incomplete, incorrect, or only indirectly representative of the
information that was actually desired. In addition, dependencies on information that was actually desired. In addition, dependencies on
information and mechanisms that were designed for a different information and mechanisms that were designed for a different
function limits the evolvability of the protocols in question. 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:
* Ossifying protocols by introducing unintended parties that may not o Ossifying protocols by introducing unintended parties that may not
be updating be updating
* Creating systemic incentives against deploying more secure or o Creating systemic incentives against deploying more secure or
private versions of protocols otherwise updated versions of protocols
* Basing network behaviour on information that may be incomplete or o Basing network behaviour on information that may be incomplete or
incorrect incorrect
* 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 portal
implementations that employ taking over cleartext HTTP sessions, and implementations that employ taking over cleartext HTTP sessions, and
so on. so on.
Increased deployment of encryption can and will change this A large number of protocol mechanisms today fall into one of two
situation. For instance, QUIC replaces TCP for various application categories: authenticated and private communication that is only
and protects all end-to-end signals to only be accessible by the visible to the a very limited set nodes, often one on each "end"; and
endpoint, ensuring evolvability [RFC9000]. QUIC does expose unauthenticated public communication that is visible to all nodes on
information dedicated for on-path elements to consume by design a path.
explicit signal for specific use cases, such as the Spin bit for
latency measurements or connection ID that can be used by load
balancers [I-D.ietf-quic-manageability] but information is limited to
only those use cases. Each new use cases requires additional action.
Explicit signals that are specifically designed for the use of on-
path function leave all other information is appropriately protected.
This enables an architecturally clean approach and evolvability,
while allowing an information exchage that is important for improving
the quality of experience for users and efficient management of the
network infrastructure built for them.
This draft discusses different approaches for explicit collaboration
and provides guidance on architectural principles to design new
mechanisms. Section 2 discusses past guidance. Section 3 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 4 points to topics that need more to
be looked at more carefully before any guidance can be given.
2. Past Guidance
Incentives are a well understood problem in general but perhaps not
fully internalised for various designs attempting to establish
collaboration between applications and path elements. The principle
is that both receiver and sender of information must acquire tangible
and immediate benefits from the communication, such as improved
performance.
A related issue is understanding whether a business model or Exposed information encourages pervasive monitoring, which is
ecosystem change is needed. For instance, relative prioritization described in RFC 7258 [RFC7258], and may also be used for commercial
between different flows of a user or an application does not require purposes, or form a basis for filtering that the applications or
agreements or payments. But requesting prioritization over other users do not desire. But a lack of all path signaling, on the other
people's traffic may imply that you have to pay for that which may hand, may be harmful to network management, debugging, or the ability
not be easy even for a single provider let alone across many. for networks to provide the most efficient services. There are many
cases where elements on the network path can provide beneficial
services, but only if they can coordinate with the endpoints. It
also affects the ability of service providers and others to observe
why problems occur [RFC9075].
But on to more technical aspects. As such, this situation is sometimes cast as an adversarial tradeoff
between privacy and the ability for the network path to provide
intended functions. However, this is perhaps an unnecessarily
polarized characterization as a zero-sum situation. Not all
information passing implies loss of privacy. For instance,
performance information or preferences do not require disclosing the
content being accessed, the user identity, or the application in use.
Similarly, network congestion status information does not have reveal
network topology or the status of other users, and so on.
The main guidance in [RFC8558] is to be aware that implicit signals Increased deployment of encryption is changing this situation.
will be used whether intended or not. Protocol designers should Encryption provides tools for controling information access and
consider either hiding these signals when the information should not protects again ossification by avoiding unintended dependencies and
be visible, or using explicit signals when it should be. requiring active maintenance.
[RFC9049] discusses many past failure cases, a catalogue of past The increased deployment of encryption provides an opportunity to
issues to avoid. It also provides relevant guidelines for new work, reconsider parts of Internet architecture that have used implicit
from discussion of incentives to more specific observations, such as derivation of input signals for on-path functions rather than
the need for outperforming end-to-end mechanisms (Section 4.4), explicit signaling, as recommended by RFC 8558 [RFC8558].
considering the need for per-connection state (Section 4.6), taking
into account the latency involved in reacting to distant signals, and
so on.
There are also more general guidance documents, e.g., [RFC5218] For instance, QUIC replaces TCP for various applications and ensures
discusses protocol successes and failures, and provides general end-to-end signals are only be accessible by the endpoints, ensuring
advice on incremental deployability etc. Internet Technology evolvability [RFC9000]. QUIC does expose information dedicated for
Adoption and Transition (ITAT) workshop report [RFC7305] is also on-path elements to consume by using explicit signals for specific
recommended reading on this same general topic. And [RFC6709] use cases, such as the Spin bit for latency measurements or
discusses protocol extensibility, and provides general advice on the connection ID that can be used by load balancers
importance of global interoperability and so on. [I-D.ietf-quic-manageability]. This information is accessible by all
on-path devices but information is limited to only those use cases.
Each new use case requires additional action. This points to one way
to resolve the adversity: the careful design of what information is
passed.
3. Principles Another extreme is to employ explicit trust and coordination between
all involved entities, endpoints as well as network devices. VPNs
are a good example of a case where there is an explicit
authentication and negotiation with a network path element that is
used to optimize behavior or gain access to specific resources.
Authentication and trust must be considered in multiple directions:
how endpoints trust and authenticate signals from network devices,
and how network devices trust and authenticate signals from
endpoints.
This section attempts to provide some architecture-level principles The goal of improving privacy and trust on the Internet does not
that would help future designers and recommend useful models to necessarily need to remove the ability for network elements to
apply. perform beneficial functions. We should instead improve the way that
these functions are achieved and design new protocols to support
explicit collaboration where it is seen as beneficial. As such our
goals should be:
A large number of our protocol mechanisms today fall into one of two o To ensure that information is distributed intentionally, not
categories: authenticated and private communication that is only accidentally;
visible to the end-to-end nodes; and unauthenticated public
communication that is visible to all nodes on a path. RFC 8558
explores the line between data that is protected and path signals.
There is a danger in taking a position that is too extreme towards o to understand the privacy and other implications of any
either exposing all information to the path, or hiding all distributed information;
information from the path.
Exposed information encourages pervasive monitoring, which is o to ensure that the information distribution is limited the
described in RFC 7258 [RFC7258]. Exposed information may also be intended parties; and
used for commercial 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 hand, may be harmful o to gate the distribution of information on the participation of
to network management, debugging, or the ability for networks to the relevant parties
provide the most efficient services. There are many cases where
elements on the network path can provide beneficial services, but
only if they can coordinate with the endpoints. It also affects the
ability of service providers and others observe why problems occur
[RFC9075].
This situation is sometimes cast as an adversarial tradeoff between These goals for exposure and distribution apply equally to senders,
privacy and the ability for the network path to provide intended receivers, and path elements.
functions. However, this is perhaps an unnecessarily polarized
characterization as a zero-sum situation. Not all information
passing implies loss of privacy. For instance, performance
information or preferences do not require disclosing user or
application identity or what content is being accessed, network
congestion status information does not have reveal network topology
or the status of other users, and so on.
This points to one way to resolve the adversity: the careful of Going forward, new standards work in the IETF needs to focus on
design of what information is passed. addressing this gap by providing better alternatives and mechanisms
for building functions that require some collaboration between
endpoints and path elements.
Another approach is to employ explicit trust and coordination between We can establish some basic questions that any new network functions
endpoints and network devices. VPNs are a good example of a case should consider:
where there is an explicit authentication and negotiation with a
network path element that's used to optimize behavior or gain access
to specific resources.
The goal of improving privacy and trust on the Internet does not o What is the minimum set of entities that need to be involved?
necessarily need to remove the ability for network elements to
perform beneficial functions. We should instead improve the way that
these functions are achieved. Our goals should be:
* To ensure that information is distributed intentionally, not o What is the minimum information each entity in this set needs?
accidentally;
* to understand the privacy and other implications of any o Which entities must consent to the information exchange?
distributed information;
* to ensure that the information distribution targets the intended o What is the effect that new signals should have?
parties; and
* to gate the distribution of information on the consent of the If we look at many of the ways network functions are achieved today,
relevant parties 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
or fail to limit the scope of distribution or providing any
negotiation or consent.
These goals for distribution apply equally to senders, receivers, and Designing explicit signals between applications and network elements,
path elements. and ensuring that all other information is appropriately protected,
enables information exchange in both directions that is important for
improving the quality of experience and network management. This
kind of cleanly separated architecture is also more conducive to
protocol evolvability.
We can establish some basic questions that any new network path This draft discusses different approaches for explicit collaboration
functions should consider: 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.
* What is the minimum set of entities that need to be involved? Beyond the recommandation in [RFC8558], the IAB has provided further
guidance on protocol design. Among other documents, [RFC5218]
provides general advice on incremental deployability based on an
analysis of successes and failures and [RFC6709] discusses protocol
extensibility. The Internet Technology Adoption and Transition
(ITAT) workshop report [RFC7305] is also recommended reading on this
same general topic. [RFC9049], an IRTF document, provides a
catalogue of past issues to avoid and discusses incentives for
adoption of path signals such as the need for outperforming end-to-
end mechanisms or considering per-connection state.
* What is the minimum information each entity in this set needs? 2. Principles
* Which entities must consent to the information exchange? This section provides architecture-level principles for protocol
designers and recommends models to apply for network collaboration
and signaling.
If we look at many of the ways network path functions are achieved While RFC 8558 [RFC8558] focused specifically on "on-path elements",
today, we find that many if not most of them fall short the standard the principles described in this document can be applied both to on-
set up by the questions above. Too often, they send unnecessary path signalling and signalling with other elements in the network
information or fail to limit the scope of distribution or providing that are not directly on-path, but still influence end-to-end
any negotiation or consent. connections. 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.
Going forward, new standards work in the IETF needs to focus on Taken together, these principles focus on the inherent privacy and
addressing this gap by providing better alternatives and mechanisms security concerns of sharing information between endpoints and
for providing path functions. Note that not all of these functions network elements, emphasizing that careful scrutiny and a high bar of
can be achieved in a way that preserves a high level of user privacy consent and trust need to be applied.
from the network; in such cases, it is incumbent upon us to not
ignore the use case, but instead to define the high bar for consent
and trust, and thus define a limited applicability for those
functions.
3.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 also in the other direction as well. For This guideline applies in the other direction as well. For instance,
instance, a network element should not unintentionally leak a network element should not unintentionally leak information that is
information that is visible to endpoints. An explicit decision is not visible to endpoints. An explicit decision is needed for a
needed for a specific information to be provided, along with analysis specific information to be provided, along with analysis of the
of the security and privacy implications of that information. security and privacy implications of that information.
3.2. Minimum Set of Entities 2.2. Minimum Set of Entities
It is recommended that a design identify 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. In some cases this will be a very limited set, e.g. when function.
the application needs to provide a signal to a specific gateway
function. In other cases, such as congestion control, a signal might Often this will be a very limited set, such as when an application
be shared with every router along the path, since each should be only needs to provide a signal to its peer at the other end of the
aware of the congestion. connection or a host needs to contact a specific VPN gateway. In
other cases a broader set is neeeded, 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 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 components 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 airgapped 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.
3.3. Consent of Parties 2.3. Control of the Distribution of Information
Consent and trust must determine the distribution of information.
The set of entities that need to consent is determined by the scope
and specificity of the information being shared.
Three distinct types of consent are recommended for collaboration or Trust and mutual agreement between the involved entities must
information sharing: determine the distribution of information, in order to give adequate
control to each entity over the collaboration or information sharing.
* A corollary of the intentional distribution is that the sender The sender needs to agree to sending the information. Any passing of
needs to agree to sending the information. Or that the requester information or request for an action needs to be explicit, and use
for an action needs to agree to make a request; it should not be protocol mechanisms that are designed for the purpose. Merely
an implicit decision by the receiver that information was sent or sending a particular kind of packet to a destination should not be
a request was made, just because a packet happened to be formed in interpreted as an implicit agreement.
a particular way.
* 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 wishing to receive the information. It request should agree to receiving the information. It should not be
should not be burdened with extra processing if it does not have burdened with extra processing if it does not have willigness or a
willigness or a need to do so. This happens naturally in most need to do so. This happens naturally in most protocol designs, but
protocol designs, but has been a problem for some cases where has been a problem for some cases where "slow path" packet processing
"slow path" packet processing is required or implied, and the is required or implied, and the recipient or router is not willing to
recipient or router did not have willingness for this. handle this.
* Internet communications are not made for the applications, they In both cases, all involved entities must be identified and
are ultimately made on behalf of users. Information relating to potentially authenticated if trust is required as a prerequisite to
the users is something that both networks and applications should share certain information.
be careful with, and not be shared without the user's consent.
This is not always easy, as the interests of the user and (for
instance) application developer may not always coincide; some
applications may wish to collect more information about the user
than the user would like.
As a result, typically an application's consent is not the same as Many Internet communications are not performed on behalf of the
the user's consent. applications, but are ultimately made on behalf of users. However,
not all information that may be shared directly relates to user
actions or other senstive data. All information shared must be
evaluated carefully to identify potential privacy implications for
users. Information that directly relates to the user should not be
shared without the user's consent. It should be noted that the
interests of the user and other parties, such as the application
developer, may not always coincide; some applications may wish to
collect more information about the user than the user would like.
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
document.
3.4. Minimum Information 2.4. Minimize Information
Parties should provide only the information that is needed for the Each party should provide only the information that is needed for the
other party to perform the collaboration task that is desired by this other parties to perform the task for which collaboration is desired,
party, and not more. This applies to information sent by an and no more. This applies to information sent by an application
application about itself, information sent about users, or about itself, information sent about users, or information sent by
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
information that should be kept private and information that should information that should be kept private and information that should
be shared. be shared.
In looking at what information can or cannot easily be passed, we can In looking at what information can or cannot easily be passed, we
look at both information from the network to the application, and need to consider both, information from the network to the
from the application to the network. application and from the application to the network.
For the application to the network direction, user-identifying For the application to the network direction, user-identifying
information can be problematic for privacy and tracking reasons. information can be problematic for privacy and tracking reasons.
Similarly, application identity can be problematic, if it might form Similarly, application identity can be problematic, if it might form
the basis for prioritization or discrimination that the that the basis for prioritization or discrimination that the application
application provider may not wish to happen. It may also have provider may not wish to happen.
undesirable economic consequences, such as extra charges for the
consumer from a priority service where a regular service would have
worked.
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, if it enables prioritization that would improve service, providers, if it enables prioritization that would improve service,
e.g., differentiation between interactive and non-interactive e.g., 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 sensitive
information, such as the precise location of the user. On the other information, such as the precise location of the user. On the other
hand, various generic network conditions, predictive bandwidth and hand, various generic network conditions, predictive bandwidth and
skipping to change at page 9, line 22 skipping to change at page 9, line 13
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.
3.5. Carrying Information 2.5. Carrying Information
There is a distinction between what information is passed and how it There is a distinction between what information is passed and how it
is carried. The actually sent information may be limited, while the is carried. The actually sent information may be limited, while the
mechanisms for sending or requesting information can be capable of mechanisms for sending or requesting information can be capable of
sending much more. sending much more.
There is a tradeoff here between flexibility and ensuring the There is a tradeoff here between flexibility and ensuring the
minimality of information in the future. The concern is that a fully minimality of information in the future. The concern is that a fully
generic data sharing approach between different layers and parties generic data sharing approach between different layers and parties
could potentially be misused, e.g., by making the availability of could potentially be misused, e.g., by making the availability of
some information a requirement for passing through a network. some information a requirement for passing through a network. This
is undesirable.
This is undesirable, and our recommendation is to employ very This document recommends that the protocols that carry information
targeted, minimal information carriage mechanisms. 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).
3.6. Protecting Information and Authentication 2.6. 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 ECN bits from routers are generally not authenticated or integrity
protected. This is possible when the information exchanges are protected. This is possible when the information exchanges do not
advisory in their nature, and do not carry any significantly carry any significantly sensitive information from the parties.
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 In other cases it may be necessary to establish a secure channel for
communication with a specific other party, e.g., between a network communication with a specific other party, e.g., between a network
element and an application. This channel may need to be element and an application. This channel may need to be
authenticated, integrity protected and encrypted. This is necessary, authenticated, integrity protected and confidential. This is
for instance, if the particular information or request needs to be necessary, for instance, if the particular information or request
share in confidency only with a particular, trusted node, or there's needs to be share in confidence only with a particular, trusted node,
a danger of an attack where someone else may forge messages that or there's a danger of an attack where someone else may forge
could endanger the communication. 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 However, it is important to note that authentication does not equal
trust. Whether a communication is with an application server or trust. Whether a communication is with an application server or
network element that can be shown to be associated with a particular network element that can be shown to be associated with a particular
domain name, it does not follow that information about the user can domain name, it does not follow that information about the user can
be safely sent to it. be safely sent to it.
In some cases, the ability of a party to show that it is on the path In some cases, the ability of a party to show that it is on the path
can be beneficial. For instance, an ICMP error that refers to a can be beneficial. For instance, an ICMP error that refers to a
valid flow may be more trustworthy than any ICMP error claiming to valid flow may be more trustworthy than any ICMP error claiming to
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.
4. Further Work 2.7. Limiting Impact of Information
Information shared between a network element and an endpoint of a
connection needs to have a limited impact on the behavior of both
endpoints and network elements. Any action that an endpoint or
network element takes based on a path signal needs to be considered
appropriately based on the level of authentication and trust that has
been established, and be scoped to a specific network path.
For example, an ICMP signal from a network element to an endpoint can
be used to influence future behavior on that particular network path
(such as changing the effective packet size or closing a path-
specific connection), but should not be able to cause a multipath or
migration-capable transport connection to close.
In many cases, path signals can be considered to be advisory
information, with the effect of optimizing or adjusting the behavior
of connections on a specific path. In the case of a firewall
blocking connectivity to a given host, endpoints should only
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
DNSSEC-authenticated denial of existence [RFC7129].
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
continues to grow. The recent changes with regards to much higher will continue to grow. Among the recent changes are much higher use
use of encryption at different protocol layers, the consolidation or of encryption at different protocol layers and the consolidation of
more and more traffic to the same destinations, and so on have also more and more traffic to the same destinations; these have greatly
greatly impacted the field. impacted the field.
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, clearly more work is needed. 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 these
topics would be welcome. topics would be welcome.
* Business arrangements. Many designs - for instance those related o Business arrangements. Many designs - for instance those related
to quality-of-service - involve an expectation of paying for a to quality-of-service - involve an expectation of paying for a
service. This is possible and has been successful within 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].
* Secure communications with path elements. This has been a o Secure communications with path elements. This has been a
difficult topic, both from the mechanics and scalability point difficult topic, both from the mechanics and scalability point
view, but also because there is no easy way to find out which view, but also because there is no easy way to find out which
parties to trust or what trust roots would be appropriate. Some parties to trust or what trust roots would be appropriate. Some
application-network element interaction designs have focused on application-network element interaction designs have focused on
information (such as ECN bits) that is distributed openly within a information (such as ECN bits) that is distributed openly within a
path, but there are limited examples of designs with secure path, but there are limited examples of designs with secure
information exchange with specific nodes. information exchange with specific nodes.
* 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., in the form of modern "source quench"
designs. designs.
* 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 nodes, starting from basic data such as domain
names learned by DNS infrastructure or source and destination names learned by DNS infrastructure or source and destination
addresses and protocol header information learned by all routers addresses and protocol header information learned by all routers
on the path, to detailed end user identity and other information on the path, to detailed end user identity and other information
learned by the servers. Some solutions are starting to exist for learned by the servers. Some solutions are starting to exist for
this but are not widely deployed, at least not today [Oblivious] this but are not widely deployed, at least not today [Oblivious]
[PDoT] [I-D.arkko-dns-confidential] [I-D.thomson-http-oblivious]. [PDoT] [I-D.arkko-dns-confidential] [I-D.thomson-http-oblivious].
These solutions address also very specific parts of the issue, and These solutions address also very specific parts of the issue, and
more work remains. more work remains.
* Sharing information from networks to applications. Some proposals o Sharing information from networks to applications. There are some
have been made in this space (see, e.g., working examples of this, e.g., ECN. A few other proposals have
[I-D.flinck-mobile-throughput-guidance]) but there are no been made (see, e.g., [I-D.flinck-mobile-throughput-guidance]),
successful or deployed mechanisms today. but very few of those have seen deployment.
5. Acknowledgments o Sharing information from applications to networks. There are a
few more working examples of this (see Section 1). However,
numerous proposals have been made in this space, but most of them
have not progressed through standards or been deployed, for a
variety of reasons [RFC9049]. Several current or recent proposals
exist, however, such as [I-D.yiakoumis-network-tokens].
o Data privacy regimes generally deal with more issues than merely
whether some information is shared with another party or not. For
instance, there may be rules regarding how long information can be
stored or what purpose information may be used for. Similar
issues may also be applicable to the kind of information sharing
discussed in this document.
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, and Jeffrey Haas for useful thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
feedback in the IABOPEN session at IETF-111. Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, and Jeffrey
Haas for useful feedback in the IABOPEN sessions and on the list.
6. 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]
Arkko, J. and J. Novotny, "Privacy Improvements for DNS Ericsson and Ericsson, "Privacy Improvements for DNS
Resolution with Confidential Computing", Work in Progress, Resolution with Confidential Computing", draft-arkko-dns-
Internet-Draft, draft-arkko-dns-confidential-02, 2 July confidential-02 (work in progress), July 2021.
2021, <https://www.ietf.org/archive/id/draft-arkko-dns-
confidential-02.txt>.
[I-D.arkko-path-signals-information] [I-D.arkko-path-signals-information]
Arkko, J., "Considerations on Information Passed between Ericsson, "Considerations on Information Passed between
Networks and Applications", Work in Progress, Internet- Networks and Applications", draft-arkko-path-signals-
Draft, draft-arkko-path-signals-information-00, 22 information-00 (work in progress), February 2021.
February 2021, <https://www.ietf.org/archive/id/draft-
arkko-path-signals-information-00.txt>.
[I-D.flinck-mobile-throughput-guidance] [I-D.flinck-mobile-throughput-guidance]
Jain, A., Terzis, A., Flinck, H., Sprecher, N., , , , , , , , and , "Mobile Throughput Guidance Inband
Arunachalam, S., Smith, K., Devarapalli, V., and R. B. Signaling Protocol", draft-flinck-mobile-throughput-
Yanai, "Mobile Throughput Guidance Inband Signaling guidance-04 (work in progress), March 2017.
Protocol", Work in Progress, Internet-Draft, draft-flinck-
mobile-throughput-guidance-04, 13 March 2017,
<https://www.ietf.org/archive/id/draft-flinck-mobile-
throughput-guidance-04.txt>.
[I-D.ietf-quic-manageability] [I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Ericsson and Google Switzerland GmbH, "Manageability of
Transport Protocol", Work in Progress, Internet-Draft, the QUIC Transport Protocol", draft-ietf-quic-
draft-ietf-quic-manageability-13, 2 September 2021, manageability-14 (work in progress), January 2022.
<https://www.ietf.org/archive/id/draft-ietf-quic-
manageability-13.txt>.
[I-D.per-app-networking-considerations] [I-D.per-app-networking-considerations]
Colitti, L. and T. Pauly, "Per-Application Networking Google and Apple Inc., "Per-Application Networking
Considerations", Work in Progress, Internet-Draft, draft- Considerations", draft-per-app-networking-
per-app-networking-considerations-00, 15 November 2020, considerations-00 (work in progress), November 2020.
<https://www.ietf.org/archive/id/draft-per-app-networking-
considerations-00.txt>.
[I-D.thomson-http-oblivious] [I-D.thomson-http-oblivious]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in Mozilla and Cloudflare, "Oblivious HTTP", draft-thomson-
Progress, Internet-Draft, draft-thomson-http-oblivious-02, http-oblivious-02 (work in progress), August 2021.
24 August 2021, <https://www.ietf.org/archive/id/draft-
thomson-http-oblivious-02.txt>.
[I-D.trammell-stackevo-explicit-coop] [I-D.trammell-stackevo-explicit-coop]
Trammell, B., "Architectural Considerations for Transport "Architectural Considerations for Transport Evolution with
Evolution with Explicit Path Cooperation", Work in Explicit Path Cooperation", draft-trammell-stackevo-
Progress, Internet-Draft, draft-trammell-stackevo- explicit-coop-00 (work in progress), September 2015.
explicit-coop-00, 23 September 2015,
<https://www.ietf.org/archive/id/draft-trammell-stackevo- [I-D.yiakoumis-network-tokens]
explicit-coop-00.txt>. Selfie Networks, Stanford University, and Norwegian
Communications Authority, "Network Tokens", draft-
yiakoumis-network-tokens-02 (work in progress), December
2020.
[Oblivious] [Oblivious]
Schmitt, P., "Oblivious DNS: Practical privacy for DNS Schmitt, P., "Oblivious DNS: Practical privacy for DNS
queries", Proceedings on Privacy Enhancing Technologies queries", Proceedings on Privacy Enhancing Technologies
2019.2: 228-244 , 2019. 2019.2: 228-244 , 2019.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private [PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digit. Threat.: Res. DNS-over-TLS with TEE Support", Digit. Threat.: Res.
Pract., Vol. 2, No. 1, Article 3, Pract., Vol. 2, No. 1, Article 3, https://dl.acm.org/doi/
https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February fullHtml/10.1145/3431171 , February 2021.
2021.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6709>. editor.org/info/rfc6709>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/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, DOI 10.17487/RFC7305, July 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7305>. 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>.
[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, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc9000>. 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, DOI 10.17487/RFC9049, June 2021, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc9049>. editor.org/info/rfc9049>.
[RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins, [RFC9075] Arkko, J., Farrell, S., Kuehlewind, 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>.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
skipping to change at page 14, line 27 skipping to change at page 15, line 14
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 Kühlewind Mirja Kuehlewind
Ericsson Ericsson
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
 End of changes. 90 change blocks. 
325 lines changed or deleted 356 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/