draft-iab-path-signals-collaboration-beforejuly.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: Best Current Practice T. Hardie Intended status: Informational T. Hardie
Expires: 9 January 2022 Cisco Expires: 23 July 2022 Cisco
T. Pauly T. Pauly
Apple Apple
M. Kühlewind M. Kühlewind
Ericsson Ericsson
8 July 2021 19 January 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-00
Abstract Abstract
Encryption and other security mechanisms are on the rise on all Encryption and other security mechanisms are on the rise on all
layers of the stack, protecting user data and making network layers of the stack, protecting user data and making network
operations more secured. Further, encryption is also a tool to operations more secured. Further, encryption is also a tool to
address ossification that has been observed on various layers of the address ossification that has been observed over time. Separation of
stack over time. Separation of functions into layers and enforcement functions into layers and enforcement of layer boundaries based on
of layer boundaries based on encryption supports selected exposure to encryption supports selected exposure to those entities that are
those entities that are addressed by a function on a certain layer. addressed by a function on a certain layer. A clear separation
A clear separation supports innovation and also enables new supports innovation and also enables new opportunities for
opportunities for collaborative functions. RFC8558 describes path collaborative functions. RFC 8558 describes path signals as messages
signals as messages to or from on-path elements. This document to or from on-path elements. This document states principles for
states principles for designing mechanisms that use or provide path designing mechanisms that use or provide path signals and calls for
signals and calls for actions on specific valuable cases. 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 https://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 9 January 2022. This Internet-Draft will expire on 23 July 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Past Guidance . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems with existing implicit signals . . . . . . . . . . . 4 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Intentional Distribution . . . . . . . . . . . . . . . . 7
4.1. Parties Need to Consent . . . . . . . . . . . . . . . . . 6 3.2. Minimum Set of Entities . . . . . . . . . . . . . . . . . 7
4.2. Nature of Information . . . . . . . . . . . . . . . . . . 6 3.3. Consent of Parties . . . . . . . . . . . . . . . . . . . 7
4.3. Authenticating Discussion Partners . . . . . . . . . . . 8 3.4. Minimum Information . . . . . . . . . . . . . . . . . . . 8
4.4. Authentication does not equal Trust . . . . . . . . . . . 8 3.5. Carrying Information . . . . . . . . . . . . . . . . . . 9
4.5. Granularity . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Protecting Information and Authentication . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 4. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Informative References . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Encryption, besides its important role in security in general, Encryption, besides its important role in security in general,
provides a tool to control information access and protects again provides a tool to control information access and protects again
ossification by avoiding unintended dependencies and requiring active ossification by avoiding unintended dependencies and requiring active
maintenance. The increased deployment of encryption provides an maintenance. The increased deployment of encryption provides an
opportunity to reconsider parts of Internet architecture that have opportunity to reconsider parts of Internet architecture that have
rather used implicit derivation of input signals for on-path rather used implicit derivation of input signals for on-path
functions than explicit signaling, as recommended by RFC8558. functions than explicit signaling, as recommended by RFC 8558
[RFC8558].
[RFC8558] defines the term path signals as signals to or from on-path 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 elements. Today path signals are often implicit, e.g. derived from
in-clear end-to-end information by e.g. examining transport 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 As such, applications and networks have 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 or incorrect or often indirectly only derives the maybe incomplete, incorrect, or only indirectly representative of the
information that was actually desired. Further, 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 original intends. function limits the evolvability of the protocols in question.
The unplanned interaction ends up having several negative effects:
* Ossifying protocols by introducing unintended parties that may not
be updating
* Creating systemic incentives against deploying more secure or
otherwise updated versions of protocols
* Basing network behaviour on information that may be incomplete or
incorrect
* Creating a model where network entities expect to be able to use
rich information about sessions passing through
For instance, features such as DNS resolution or TLS setup have been
used beyond their original intent, such as in name-based filtering.
MAC addresses have been used for access control, captive portal
implementations that employ taking over cleartext HTTP sessions, and
so on.
Increased deployment of encryption can and will change this Increased deployment of encryption can and will change this
situation. E.g. QUIC replaces TCP for various application and situation. For instance, QUIC replaces TCP for various application
protects all end-to-end signals to only be accessible by the and protects all end-to-end signals to only be accessible by the
endpoint, ensuring evolvability [RFC9000]. QUIC does expose endpoint, ensuring evolvability [RFC9000]. QUIC does expose
information dedicated for on-path elements to consume by design information dedicated for on-path elements to consume by design
explicit signal for specific use cases, such as the Spin bit for explicit signal for specific use cases, such as the Spin bit for
latency measurements or connection ID that can be used by load latency measurements or connection ID that can be used by load
balancers [I-D.ietf-quic-manageability] but information is limited to balancers [I-D.ietf-quic-manageability] but information is limited to
only those use cases. Each new use cases requires additional action. only those use cases. Each new use cases requires additional action.
Such explicit signals that are specifically designed for the use of Explicit signals that are specifically designed for the use of on-
on-path function, while all other information is appropriately path function leave all other information is appropriately protected.
protected, enables an architecturally clean approach with the aims to This enables an architecturally clean approach and evolvability,
use and manage the existing network infrastructure most efficiently while allowing an information exchage that is important for improving
as well as improve the quality of experience for those this the quality of experience for users and efficient management of the
technology is build for - the user. network infrastructure built for them.
This draft then discusses different approaches for explicit This draft discusses different approaches for explicit collaboration
collaboration and provides guidance on architectural principles to and provides guidance on architectural principles to design new
design new mechanisms. 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 2. Past Guidance
Incentives are a well understood problem in general but perhaps not Incentives are a well understood problem in general but perhaps not
fully internalised for various designs attempting to establish fully internalised for various designs attempting to establish
collaboration between applications and path elements. The principle collaboration between applications and path elements. The principle
is that both receiver and sender of information must acquire tangible is that both receiver and sender of information must acquire tangible
and immediate benefits from the communication, such as improved and immediate benefits from the communication, such as improved
performance, performance.
A related issue is understanding whether a business model or A related issue is understanding whether a business model or
ecosystem change is needed. Some designs may work well without any ecosystem change is needed. For instance, relative prioritization
monetary or payment or cross-administrative domains agreements. For between different flows of a user or an application does not require
instance, I could ask my packets to be prioritised relative to each agreements or payments. But requesting prioritization over other
other and that shouldn't affect anything else. Some other designs people's traffic may imply that you have to pay for that which may
may require a matching business ecosystem change to support what is not be easy even for a single provider let alone across many.
being proposed, and may be much harder to achieve. For instance,
requesting prioritisation over other people's traffic may imply that
you have to pay for that which may not be easy even for a single
provider let alone across many.
But on to more technical aspects. But on to more technical aspects.
The main guidance in [RFC8558] is to be aware that implicit signals The main guidance in [RFC8558] is to be aware that implicit signals
will be used whether intended or not. Protocol designers should will be used whether intended or not. Protocol designers should
consider either hiding these signals when the information should not consider either hiding these signals when the information should not
be visible, or using explicit signals when it should be. be visible, or using explicit signals when it should be.
[I-D.irtf-panrg-what-not-to-do] discusses many past failure cases, a [RFC9049] discusses many past failure cases, a catalogue of past
catalogue of past issues to avoid. It also provides relevant issues to avoid. It also provides relevant guidelines for new work,
guidelines for new work, from discussion of incentives to more from discussion of incentives to more specific observations, such as
specific observations, such as the need for outperforming end-to-end the need for outperforming end-to-end mechanisms (Section 4.4),
mechanisms (Section 4.4), considering the need for per-connection considering the need for per-connection state (Section 4.6), taking
state (Section 4.6), and so on. into account the latency involved in reacting to distant signals, and
so on.
There are also more general guidance documents, e.g., [RFC5218] There are also more general guidance documents, e.g., [RFC5218]
discusses protocol successes and failures, and provides general discusses protocol successes and failures, and provides general
advice on incremental deployability etc. Internet Technology advice on incremental deployability etc. Internet Technology
Adoption and Transition (ITAT) workshop report [RFC7305] is also Adoption and Transition (ITAT) workshop report [RFC7305] is also
recommended reading on this same general topic. And [RFC6709] recommended reading on this same general topic. And [RFC6709]
discusses protocol extensibility, and provides general advice on the discusses protocol extensibility, and provides general advice on the
importance of global interoperability and so on. importance of global interoperability and so on.
3. Problems with existing implicit signals 3. Principles
This kind of interaction ends up having several negative effects:
* Ossifying protocols by introducing unintended parties that may not
be updating
* Creating systemic incentives against deploying more secure or
private versions of protocols
* Basing network behaviour on information that may be incomplete or
incorrect
* Creating a model where network entities expect to be able to use
rich information about sessions passing through
For instance, features such as DNS resolution or TLS setup have been
used beyond their original intent, such as name filtering, MAC
addresses used for access control, captive portal implementations
that employ taking over cleartext HTTP sessions, and so on.
4. Principles
This section attempts to provide some architecture-level principles This section attempts to provide some architecture-level principles
that would help future designers, explain past issues and recommend that would help future designers and recommend useful models to
useful models to apply. apply.
...
A large number of our protocol mechanisms today fall into one of two A large number of our protocol mechanisms today fall into one of two
categories: authenticated and private communication that is only categories: authenticated and private communication that is only
visible by the end-to-end nodes; and unauthenticated public visible to the end-to-end nodes; and unauthenticated public
communication that is visible to all nodes on a path. RFC 8558 communication that is visible to all nodes on a path. RFC 8558
explores the line between data that is protected and path signals. explores the line between data that is protected and path signals.
There is a danger in taking a position that is too extreme towards There is a danger in taking a position that is too extreme towards
either exposing all information to the path, or hiding all either exposing all information to the path, or hiding all
information from the path. Exposed information encourages pervasive information from the path.
monitoring, which is described in RFC 7258. But a lack of all path
signaling, on the other hand, may be harmful to network management
and the ability for networks to provide useful services. There are
many cases where elements on the network path can provide beneficial
services, but only if they can coordinate with the endpoints. This
tradeoff between privacy and network functions has in some cases led
to an adversarial stance between privacy and the ability for the
network path to provide intended functions.
One way to resolve this conflict is to add more explicit trust and Exposed information encourages pervasive monitoring, which is
coordination between endpoints and network devices. VPNs are a good described in RFC 7258 [RFC7258]. Exposed information may also be
example of a case where there is an explicit authentication and used for commercial purposes, or form a basis for filtering that the
negotiation with a network path element that's used to optimize applications or users do not desire.
behavior or gain access to specific resources.
But a lack of all path signaling, on the other hand, may be harmful
to network management, debugging, or the ability 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 observe why problems occur
[RFC9075].
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 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
design of what information is passed.
Another approach is to employ explicit trust and coordination between
endpoints and network devices. VPNs are a good example of a case
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 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. Our goals should be: - To ensure that these functions are achieved. Our goals should be:
information is distributed intentionally, not accidentally, as noted
in [RFC8558]; - To understand the privacy and other implications of * To ensure that information is distributed intentionally, not
any distributed information; and - To gate the distribution of accidentally;
information on the consent of the relevant parties
* to understand the privacy and other implications of any
distributed information;
* to ensure that the information distribution targets the intended
parties; and
* to gate the distribution of information on the consent of the
relevant parties
These goals for distribution apply equally to senders, receivers, and These goals for distribution apply equally to senders, receivers, and
path elements. path elements.
We can establish some basic questions that any new network path We can establish some basic questions that any new network path
functions should consider: - What is the minimum set of entities that functions should consider:
need to be involved in order to perform this function? - What is the
minimum information each entity in this set needs to perform its part
of the function correctly and reliably? - Which entities must consent
to each piece of information that is shared?
Consent and trust must determine the distribution of information. * What is the minimum set of entities that need to be involved?
The set of entities that need to consent is determined by the scope
and specificity of the information being shared. * What is the minimum information each entity in this set needs?
* Which entities must consent to the information exchange?
If we look at many of the ways network path functions are achieved If we look at many of the ways network path functions are achieved
today, we find that many if not most of them fall short the standard today, we find that many if not most of them fall short the standard
set up by the questions above. Too often, they rely on information set up by the questions above. Too often, they send unnecessary
being sent without limiting the scope of distribution or providing information or fail to limit the scope of distribution or providing
any negotiation or consent. any negotiation or consent.
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 providing path functions. Note that not all of these functions for building functions that require some collaboration between
can be achieved in a way that preserves a high level of user privacy endpoints and path elements.
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.
4.1. Parties Need to Consent Some types of information shared between endpoints and path elements
have inherent privacy concerns. Careful scrutiny and a high bar of
consent and trust needs to be applied.
... 3.1. Intentional Distribution
4.2. Nature of Information This guideline is best expressed in RFC 8558:
One common problem in finding a workable solution for network - "Fundamentally, this document recommends that implicit signals should
application collaboration is information leakage. All parties are be avoided and that an implicit signal should be replaced with an
afraid of either their own propietary information or the users' data explicit signal only when the signal's originator intends that it be
leaking to others. Oddly enough, no one is usually worried about used by the network elements on the path. For many flows, this may
users' data leaking to themselves, but we digress. :-) result in the signal being absent but allows it to be present when
needed."
[I-D.per-app-networking-considerations] discusses how applications This guideline applies also in the other direction as well. For
may be identified through collaboration mechanisms. This can be instance, a network element should not unintentionally leak
harmful, as in extreme cases it may lead to undesirable information that is visible to endpoints. An explicit decision is
prioritization decisions or even blocking certain applications. needed for a specific information to be provided, along with analysis
[I-D.per-app-networking-considerations] explains how to reduce the of the security and privacy implications of that information.
latter problem by categories or requested service rather than
specific application identity, such as providing the category "video 3.2. Minimum Set of Entities
call service" rather than the name of a particular application
performing conference call or video call services. This points to a It is recommended that a design identify the minimum number of
more general principle of information specificity, providing only the entities needed to share a specific signal required for an identified
information that is needed for the other party to perform the function. In some cases this will be a very limited set, e.g. when
collaboration task that is desired by this party, and not more. This the application needs to provide a signal to a specific gateway
applies to information sent by an application about itself, function. In other cases, such as congestion control, a signal might
information sent about users, or information sent by the network. be shared with every router along the path, since each should be
aware of the 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 components 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.
3.3. Consent of Parties
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
information sharing:
* A corollary of the intentional distribution is that the sender
needs to agree to sending the information. Or that the requester
for an action needs to agree to make a request; it should not be
an implicit decision by the receiver that information was sent or
a request was made, just because a packet happened to be formed in
a particular way.
* At the same time, the recipient of information or the target of a
request should agree to wishing to receive the information. It
should not be burdened with extra processing if it does not have
willigness or a need to do so. This happens naturally in most
protocol designs, but has been a problem for some cases where
"slow path" packet processing is required or implied, and the
recipient or router did not have willingness for this.
* Internet communications are not made for the applications, they
are ultimately made on behalf of users. Information relating to
the users is something that both networks and applications should
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
the user's consent.
3.4. Minimum Information
Parties should provide only the information that is needed for the
other party to perform the collaboration task that is desired by this
party, and not more. This applies to information sent by an
application about itself, information sent about users, or
information sent by 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 can
look at both information from the network to the application, and look at both information from the network to the application, and
from the application to the network. 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 that
application provider may not wish to happen. It may also have application 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's less directly For the network to application direction there is similarly sensitive
sensitive information. Various network conditions, predictive information, such as the precise location of the user. On the other
bandwidth and latency capabilities, and so on might be attractive hand, various generic network conditions, predictive bandwidth and
information that applications can use to determine, for instance, latency capabilities, and so on might be attractive information that
optimal strategies for changing codecs. applications can use to determine, for instance, optimal strategies
for changing codecs. However, information given by the network about
However, care needs to be take to ensure that neither private load conditions and so on should not form a mechanism to provide a
information about the individual user (such as user's physical
location) is not indirectly exposed through this information.
Similarly, this information 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 should also be declarative rather than specify some basis, it is often beneficial to provide declarative information
actions. The information should show what the application needs, for that, for instance, expresses application needs than makes specific
instance, rather than requiring the path elements to behave in some requests for action.
specific fashion.
One should also consider ways to verify the provided information, or 3.5. Carrying Information
understand the implications if the information provided from the
application may not be correct, or has been modified.
4.3. Authenticating Discussion Partners 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.
(even outside the client and server) 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, and our recommendation is to employ very
targeted, minimal information carriage mechanisms.
4.4. Authentication does not equal Trust 3.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 are
advisory in their nature, and do not carry any significantly
sensitive information from the parties.
4.5. Granularity 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 encrypted. This is necessary,
for instance, if the particular information or request needs to be
share in confidency 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.
In the IAB Covid-19 Network Impacts workshop Jana Iyengar brought up However, it is important to note that authentication does not equal
the granularity of operations [I-D.iab-covid19-workshop]. There are trust. Whether a communication is with an application server or
many reasons why per-flow designs are problematic: scalability, need network element that can be shown to be associated with a particular
to release information about individual user's individual activities, domain name, it does not follow that information about the user can
etc. Perhaps designs that work on aggregates would work better. 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.
4. Further Work
This is a developing field, and it is expected that our understanding
continues to grow. The recent changes with regards to much higher
use of encryption at different protocol layers, the consolidation or
more and more traffic to the same destinations, and so on have also
greatly impacted the field.
While there are some examples of modern, well-designed collaboration
mechanisms, clearly more work is needed. Many complex cases would
require significant developments in order to become feasible.
Some of the most difficult areas are listed below. Research on these
topics would be welcome.
* Business arrangements. Many designs - for instance those related
to quality-of-service - 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
data caps in their ISP networks. However, it is a business-wise
much harder proposition for end-to-end connections across multiple
administrative domains [Claffy2015] [RFC9049].
* Secure communications with path elements. This has been a
difficult topic, both from the mechanics and scalability point
view, but also because there is no easy way to find out which
parties to trust or what trust roots would be appropriate. Some
application-network element interaction designs have focused on
information (such as ECN bits) that is distributed openly within a
path, but there are limited examples of designs with secure
information exchange with specific nodes.
* The use of path signals for reducing the effects of denial-of-
service attacks, e.g., in the form of modern "source quench"
designs.
* Ways of protecting information when held by network elements or
servers, beyond communications security. For instance, host
applications commonly share sensitive information about the user's
actions with other nodes, starting from basic data such as domain
names learned by DNS infrastructure or source and destination
addresses and protocol header information learned by all routers
on the path, to detailed end user identity and other information
learned by the servers. Some solutions are starting to exist for
this but are not widely deployed, at least not today [Oblivious]
[PDoT] [I-D.arkko-dns-confidential] [I-D.thomson-http-oblivious].
These solutions address also very specific parts of the issue, and
more work remains.
* Sharing information from networks to applications. Some proposals
have been made in this space (see, e.g.,
[I-D.flinck-mobile-throughput-guidance]) but there are no
successful or deployed mechanisms today.
5. Acknowledgments 5. 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. [I-D.arkko-path-signals-information] that were published earlier. We
would also like to acknowledge [I-D.trammell-stackevo-explicit-coop]
for presenting similar thoughts. Finally, the authors would like to
thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, and Jeffrey
Haas for useful feedback in the IABOPEN sessions and on the list.
6. Informative References 6. Informative References
[Claffy2015]
kc Claffy, . and D. Clark, "Adding Enhanced Services to
the Internet: Lessons from History", TPRC 43: The 43rd
Research Conference on Communication, Information and
Internet Policy Paper , April 2015.
[I-D.arkko-dns-confidential]
Arkko, J. and J. Novotny, "Privacy Improvements for DNS
Resolution with Confidential Computing", Work in Progress,
Internet-Draft, draft-arkko-dns-confidential-02, 2 July
2021, <https://www.ietf.org/archive/id/draft-arkko-dns-
confidential-02.txt>.
[I-D.arkko-path-signals-information] [I-D.arkko-path-signals-information]
Arkko, J., "Considerations on Information Passed between Arkko, J., "Considerations on Information Passed between
Networks and Applications", Work in Progress, Internet- Networks and Applications", Work in Progress, Internet-
Draft, draft-arkko-path-signals-information-00, 22 Draft, draft-arkko-path-signals-information-00, 22
February 2021, <https://www.ietf.org/archive/id/draft- February 2021, <https://www.ietf.org/archive/id/draft-
arkko-path-signals-information-00.txt>. arkko-path-signals-information-00.txt>.
[I-D.iab-covid19-workshop] [I-D.flinck-mobile-throughput-guidance]
Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins, Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
"Report from the IAB COVID-19 Network Impacts Workshop Arunachalam, S., Smith, K., Devarapalli, V., and R. B.
2020", Work in Progress, Internet-Draft, draft-iab- Yanai, "Mobile Throughput Guidance Inband Signaling
covid19-workshop-03, 5 May 2021, Protocol", Work in Progress, Internet-Draft, draft-flinck-
<https://www.ietf.org/archive/id/draft-iab-covid19- mobile-throughput-guidance-04, 13 March 2017,
workshop-03.txt>. <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 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-12, 30 June 2021, draft-ietf-quic-manageability-13, 2 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://www.ietf.org/archive/id/draft-ietf-quic-
manageability-12.txt>. manageability-13.txt>.
[I-D.irtf-panrg-what-not-to-do]
Dawkins, S., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", Work in
Progress, Internet-Draft, draft-irtf-panrg-what-not-to-do-
19, 26 March 2021, <https://www.ietf.org/archive/id/draft-
irtf-panrg-what-not-to-do-19.txt>.
[I-D.per-app-networking-considerations] [I-D.per-app-networking-considerations]
Colitti, L. and T. Pauly, "Per-Application Networking Colitti, L. and T. Pauly, "Per-Application Networking
Considerations", Work in Progress, Internet-Draft, draft- Considerations", Work in Progress, Internet-Draft, draft-
per-app-networking-considerations-00, 15 November 2020, per-app-networking-considerations-00, 15 November 2020,
<https://www.ietf.org/archive/id/draft-per-app-networking- <https://www.ietf.org/archive/id/draft-per-app-networking-
considerations-00.txt>. considerations-00.txt>.
[I-D.thomson-http-oblivious]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-thomson-http-oblivious-02,
24 August 2021, <https://www.ietf.org/archive/id/draft-
thomson-http-oblivious-02.txt>.
[I-D.trammell-stackevo-explicit-coop]
Trammell, B., "Architectural Considerations for Transport
Evolution with Explicit Path Cooperation", Work in
Progress, Internet-Draft, draft-trammell-stackevo-
explicit-coop-00, 23 September 2015,
<https://www.ietf.org/archive/id/draft-trammell-stackevo-
explicit-coop-00.txt>.
[Oblivious]
Schmitt, P., "Oblivious DNS: Practical privacy for DNS
queries", Proceedings on Privacy Enhancing Technologies
2019.2: 228-244 , 2019.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digit. Threat.: Res.
Pract., Vol. 2, No. 1, Article 3,
https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February
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-editor.org/info/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
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-editor.org/info/rfc7305>. <https://www.rfc-editor.org/info/rfc7305>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[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-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
[RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
"Report from the IAB COVID-19 Network Impacts Workshop
2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
<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
Ted Hardie Ted Hardie
Cisco Cisco
 End of changes. 51 change blocks. 
193 lines changed or deleted 400 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/