rfc9419xml2.original.xml   rfc9419.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc sortrefs="yes"?> -iab-path-signals-collaboration-03" number="9419" submissionType="IAB" category=
<?rfc symrefs="yes"?> "info" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-iab-path-signals-collaboration-03" categor
y="info">
<front> <front>
<title abbrev="Path Signals Collab">Considerations on Application - Network <title abbrev="Path Signals Collaboration">Considerations on Application - N
Collaboration Using Path Signals</title> etwork Collaboration Using Path Signals</title>
<seriesInfo name="RFC" value="9419"/>
<author initials="J." surname="Arkko" fullname="Jari Arkko"> <author initials="J." surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization> <organization showOnFrontPage="true">Ericsson</organization>
<address> <address>
<email>jari.arkko@ericsson.com</email> <email>jari.arkko@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Hardie" fullname="Ted Hardie"> <author initials="T." surname="Hardie" fullname="Ted Hardie">
<organization>Cisco</organization> <organization showOnFrontPage="true">Cisco</organization>
<address> <address>
<email>ted.ietf@gmail.com</email> <email>ted.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple</organization> <organization showOnFrontPage="true">Apple</organization>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind"> <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind">
<organization>Ericsson</organization> <organization showOnFrontPage="true">Ericsson</organization>
<address> <address>
<email>mirja.kuehlewind@ericsson.com</email> <email>mirja.kuehlewind@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2023" month="June"/>
<date year="2023" month="February" day="23"/>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document discusses principles for designing mechanisms that use
<t>This document discusses principles for designing mechanisms that use or provi or provide path signals and calls for standards action in specific
de valuable cases. RFC 8558 describes path signals as messages to or from
path signals, and calls for standards action in specific valuable cases. on-path elements and points out that visible information will be used
RFC 8558 describes path signals as messages to or from on-path elements, whether or not it is intended as a signal. The principles in this
and points out that visible information will be used whether it is document are intended as guidance for the design of explicit path
intended as a signal or not. The principles in this document are intended as signals, which are encouraged to be authenticated and include a minimal
guidance for the design of explicit path signals, which are encouraged to be set of parties to minimize information sharing. These principles can be
authenticated and include achieved through mechanisms like encryption of information and
a minimal set of parties to minimize information sharing. These principles can establishing trust relationships between entities on a path.</t>
be achieved through mechanisms like encryption of information and
establishing trust relationships between entities on a path.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t><xref target="RFC8558" format="default"/> defines the term "path
signals" as signals to or from on-path elements. Today, path signals are
often implicit; for example, they are derived from cleartext end-to-end in
formation by,
e.g., examining transport protocols. For instance, on-path elements use
various fields of the TCP header <xref target="RFC9293"
format="default"/> to derive information about end-to-end latency as
well as congestion. These techniques have evolved because the
information was available and its use required no coordination with
anyone. This made such techniques more easily deployable than
alternative, potentially more explicit or cooperative, approaches.</t>
<t>However, this also means that applications and networks have often
evolved their interaction without comprehensive design for how this
interaction should happen or which (minimal) information would be needed
for a certain function. This has led to a situation where
information that happens to be easily available is used instead of the
information that is actually needed. As such, that information may
be incomplete, incorrect, or only indirectly representative of the
information that is actually needed. In addition, dependencies on
information and mechanisms that were designed for a different function
limit the evolvability of the protocols in question.</t>
<t>In summary, such unplanned interactions end up having several
negative effects:</t>
<ul spacing="normal">
<li>Ossifying protocols by introducing dependencies to unintended
parties that may not be updating, such as how middleboxes have limited
the use of TCP options</li>
<li>Creating systemic incentives against deploying more secure or
otherwise updated versions of protocols</li>
<li>Basing network behavior on information that may be incomplete or
incorrect</li>
<li>Creating a model where network entities expect to be able to use
rich information about sessions passing through</li>
</ul>
<t>For instance, features such as DNS resolution or TLS setup have been
used beyond their original intent, such as in name-based
filtering. Media Access Control (MAC) addresses have been used for
access control, captive portals have been used to take over cleartext
HTTP sessions, and so on. (This document is not about whether those
practices are good or bad; it is simply stating a fact that the features
were used beyond their original intent.)</t>
<section anchor="intro" title="Introduction"> <t>Many protocol mechanisms throughout the stack fall into one of two
categories: authenticated private communication that is only visible to a
<t><xref target="RFC8558"/> defines the term “path signals” as signals to or fro very limited set of parties, often one on each "end", and
m on-path unauthenticated public communication that is visible to all
elements. Today path signals are often implicit, e.g. derived from network elements on a path.</t>
cleartext end-to-end information by e.g. examining transport <t>Exposed information encourages pervasive monitoring, which is
protocols. For instance, on-path elements use various fields of the described in <xref target="RFC7258" format="default"/>. It may also be
TCP header <xref target="RFC0793"/> to derive information about end-to-end laten used for commercial purposes or to form a basis for filtering that the
cy applications or users do not desire. However, a lack of all path signalin
as well as congestion. These techniques have evolved because the g,
information was available and its use required no coordination with on the other hand, may limit network management, debugging, or the
anyone. This made such techniques more easily deployable than ability for networks to optimize their services. There are many cases
alternative, potentially more explicit or cooperative, approaches.</t> where elements on the network path can provide beneficial services, but
only if they can coordinate with the endpoints. It also affects the
<t>However, this also means that applications and networks have often evolved th ability of service providers and others to observe why problems occur
eir interaction <xref target="RFC9075" format="default"/>.</t>
without comprehensive design for how this interaction should <t>As such, this situation is sometimes cast as an adversarial trade-off
happen or which (minimal) information would be needed for a certain function. between privacy and the ability for the network path to provide intended
This has led to a situation where simply information that happens functions. However, this is perhaps an unnecessarily polarized
to be easily available is used instead the information that would be actually ne characterization as a zero-sum situation. Not all information passing
eded. implies loss of privacy. For instance, performance information or
As such that information preferences do not require disclosing the content being accessed, the
may be incomplete, incorrect, or only indirectly representative of the user identity, or the application in use. Similarly, network congestion
information that is actually needed. In addition, dependencies on status information does not have to reveal network topology, the
information and mechanisms that were designed for a different function status of other users, and so on.</t>
limits the evolvability of the protocols in question.</t> <t>Increased deployment of encryption is changing this situation.
Encryption provides tools for controlling information access and
<t>In summary, such unplanned interactions end up having several negative effect protects against ossification by avoiding unintended dependencies and
s:</t> requiring active maintenance. The increased deployment of encryption
provides an opportunity to reconsider parts of Internet architecture
<t><list style="symbols"> that have used implicit derivation of input signals for on-path
<t>Ossifying protocols by introducing dependencies to unintended parties functions rather than explicit signaling, as recommended by <xref
that may not be updating, such as how middleboxes have limited the use of TCP op target="RFC8558" format="default"/>.</t>
tions</t>
<t>Creating systemic incentives against deploying more secure or otherwise upd
ated versions of protocols</t>
<t>Basing network behaviour on information that may be incomplete or incorrect
</t>
<t>Creating a model where network entities expect to be able to use
rich information about sessions passing through</t>
</list></t>
<t>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
portals have been used to take over cleartext HTTP
sessions, and so on. (This document is not about whether those
practices are good or bad, it is simply stating a fact that the
features were used beyond their original intent.)</t>
<t>Many protocol mechanisms throughout the stack fall into one of two
categories: authenticated and private communication that is only visible
to a very limited set of parties, often one on each “end”; and unauthenticated
public communication that is also visible to all network elements on a path.</t>
<t>Exposed information encourages pervasive monitoring, which is
described in RFC 7258 <xref target="RFC7258"/>, and may also be
used for commercial purposes, or form a basis for filtering that the
applications or users do not desire.
But a lack of all path signalling, on the other hand, may limit network
management, debugging, or the ability for networks to optimize their 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 <xref target="RFC9075"/>.</t>
<t>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 to reveal network topology or
the status of other users, and so on.</t>
<t>Increased deployment of encryption is changing this situation.
Encryption provides tools for controlling information access
and protects against ossification by avoiding
unintended dependencies and requiring active maintenance.
The increased
deployment of encryption provides an opportunity to reconsider parts of
Internet architecture that have used implicit derivation of input
signals for on-path functions rather than explicit signalling, as recommended
by RFC 8558 <xref target="RFC8558"/>.</t>
<t>For instance, QUIC replaces TCP for various applications and ensures end-to-e
nd
signals are only accessible by the endpoints, ensuring evolvability <xref target
="RFC9000"/>.
QUIC does expose information dedicated for on-path elements to consume
by using explicit signals for specific use cases, such as the Spin bit
for latency measurements or connection ID that can be used by
load balancers <xref target="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.</t>
<t>Another extreme is to employ explicit trust and coordination between
specific entities, endpoints as well as network path elements.
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 gain access to
specific resources. Authentication and trust must be considered in
both directions: how endpoints trust and authenticate signals
from network path elements, and how network path elements trust and authenticate
signals from endpoints.</t>
<t>The goal of improving privacy and trust on the Internet does not necessarily
need to remove the ability for network elements to perform beneficial
functions. We should instead improve the way that these functions are
achieved and design new ways to support explicit collaboration where it
is seen as beneficial. As such our goals should be:</t>
<t><list style="symbols">
<t>To ensure that information is distributed intentionally, not accidentally;<
/t>
<t>to understand the privacy and other implications of any distributed informa
tion;</t>
<t>to ensure that the information distribution is limited to the intended part
ies; and</t>
<t>to gate the distribution of information on the participation of the relevan
t parties.</t>
</list></t>
<t>These goals for exposure and distribution apply equally to senders, receivers <t>For instance, QUIC replaces TCP for various applications and protects
, end-to-end signals so that they are only accessible by the endpoints, ensu
ring
evolvability <xref target="RFC9000" format="default"/>. QUIC
does expose information dedicated for on-path elements to consume by
using explicit signals for specific use cases, such as the Spin Bit for
latency measurements or connection ID that can be used by load balancers
<xref target="RFC9312" format="default"/>. 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.</t>
<t>Another extreme is to employ explicit trust and coordination between
specific entities, endpoints, and network path elements. 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 gain access to
specific resources. Authentication and trust must be considered in both
directions: how endpoints trust and authenticate signals from network path
elements and how network path elements trust and authenticate signals fro
m
endpoints.</t>
<t>The goal of improving privacy and trust on the Internet does not
necessarily need to remove the ability for network elements to perform
beneficial functions. We should instead improve the way that these
functions are achieved and design new ways to support explicit
collaboration where it is seen as beneficial. As such, our goals should
be to:</t>
<ul spacing="normal">
<li>ensure that information is distributed intentionally, not
accidentally;</li>
<li>understand the privacy and other implications of any
distributed information;</li>
<li>ensure that the information distribution is limited to the
intended parties; and</li>
<li>gate the distribution of information on the participation of
the relevant parties.</li>
</ul>
<t>These goals for exposure and distribution apply equally to senders, rec
eivers,
and path elements.</t> and path elements.</t>
<t>Going forward, new standards work in the IETF needs to focus on
<t>Going forward, new standards work in the IETF needs to focus on
addressing this gap by providing better alternatives and mechanisms addressing this gap by providing better alternatives and mechanisms
for building functions that require some collaboration between for building functions that require some collaboration between
endpoints and path elements.</t> endpoints and path elements.</t>
<t>We can establish some basic questions that any new network function
<t>We can establish some basic questions that any new network functions
should consider:</t> should consider:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Which entities must consent to the information exchange?</li>
<t>Which entities must consent to the information exchange?</t> <li>What is the minimum information each entity in this set needs?</li>
<t>What is the minimum information each entity in this set needs?</t> <li>What is the effect that new signals should have?</li>
<t>What is the effect that new signals should have?</t> <li>What is the minimum set of entities that need to be involved?</li>
<t>What is the minimum set of entities that need to be involved?</t> <li>What are the right mechanism and needed level of trust to convey
<t>What is the right mechanism and needed level of trust to convey this kind o this kind of information?</li>
f information?</t> </ul>
</list></t> <t>If we look at ways network functions are achieved today, we find that
many, if not most of them, fall short of the standard set up by the questi
<t>If we look ways network functions are achieved today, we ons
find that many if not most of them fall short the standard set up by the above. Too often, they send unnecessary information, fail to limit the
questions above. Too often, they send unnecessary information or fail to scope of distribution, or fail to provide any negotiation or consent.</t>
limit the scope of distribution or providing any negotiation or consent.</t> <t>Designing explicit signals between applications and network elements,
and ensuring that all information is appropriately protected, enables
<t>Designing explicit signals between applications and network elements, information exchange in both directions that is important for improving
and ensuring that all information is appropriately protected, the quality of experience and network management. The clean separation
enables information exchange in both directions that is important provided by explicit signals is also more conducive to protocol evolvabili
for improving the quality of experience and network management. ty.</t>
The clean separation provided by explicit signals is also more conducive <t>Beyond the recommendation in <xref target="RFC8558"
to protocol evolvability.</t> format="default"/>, the IAB has provided further guidance on protocol
design. Among other documents, <xref target="RFC5218"
<t>Beyond the recommendation in <xref target="RFC8558"/>, the IAB has provided f format="default"/> provides general advice on incremental deployability
urther based on an analysis of successes and failures, and <xref
guidance on protocol design. Among other documents, <xref target="RFC5218"/> pr target="RFC6709" format="default"/> discusses protocol
ovides general advice extensibility. The Internet Technology Adoption and Transition (ITAT)
on incremental deployability based on an analysis of successes and failures workshop report <xref target="RFC7305" format="default"/> is also a
and <xref target="RFC6709"/> discusses protocol extensibility. The Internet Tech recommended reading on this same general topic. <xref target="RFC9049"
nology format="default"/>, an IRTF document, provides a catalog of past
Adoption and Transition (ITAT) workshop report <xref target="RFC7305"/> is also issues to avoid and discusses incentives for adoption of path signals
recommended such as the need for outperforming end-to-end mechanisms or considering
reading on this same general topic. <xref target="RFC9049"/>, an IRTF document, per-connection state.</t>
provides <t>This document discusses different approaches for explicit collaboration
a catalogue of past issues to avoid and discusses incentives for adoption of and provides guidance on architectural principles to design new
path signals such as the need for outperforming end-to-end mechanisms or mechanisms. <xref target="principles" format="default"/> discusses
considering per-connection state.</t> principles that good design can follow. This section also provides example
s and explores the consequences of not following these
<t>This draft discusses different approaches for explicit collaboration principles in those examples. <xref target="research" format="default"/>
and provides guidance on architectural principles to design new points to topics
mechanisms. <xref target="principles"/> discusses that need to be looked at more carefully before any guidance can be
principles that good design can follow. This section also provides given.</t>
some examples and explanation of situations that not following the </section>
principles can lead to. <xref target="research"/> points to topics that need mor <section anchor="principles" numbered="true" toc="default">
e <name>Principles</name>
to be looked at more carefully before any guidance can be given.</t> <t>This section provides architecture-level principles for protocol
designers and recommends models to apply for network collaboration and
</section> signaling.</t>
<section anchor="principles" title="Principles"> <t>While <xref target="RFC8558" format="default"/> focuses specifically
on communication to "on-path elements", the principles described in this
<t>This section provides architecture-level principles for protocol designers document apply potentially to:</t>
and recommends models to apply for network collaboration and signalling.</t> <ul spacing="normal">
<li>on-path signaling (in either direction) and</li>
<t>While RFC 8558 <xref target="RFC8558"/> focused specifically on communication <li>signaling with other elements in the network that are not
to “on-path elements”, directly on-path but still influence end-to-end connections.</li>
the principles described in this document apply potentially to</t> </ul>
<t>An example of on-path signaling is communication between an endpoint
<t><list style="symbols"> and a router on a network path. An example of signaling with another
<t>on-path signalling, in either direction</t>
<t>signalling with other elements in the network
that are not directly on-path, but still influence end-to-end connections.</t>
</list></t>
<t>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 network element is communication between an endpoint and a network-assigned
DNS server, firewall controller, or captive portal API server. Note that DNS server, firewall controller, or captive portal API server. Note that
these communications are conceptually independent of the base flow, even if these communications are conceptually independent of the base flow, even if
they share a packet; they are from and to other parties, rather than they share a packet; they are coming from and going to other parties, rather tha n
creating a multiparty communication.</t> creating a multiparty communication.</t>
<t>Taken together, these principles focus on the inherent privacy and secu
<t>Taken together, these principles focus on the inherent privacy and security rity
concerns of sharing information between endpoints and network elements, concerns of sharing information between endpoints and network elements,
emphasizing that careful scrutiny and a high bar of consent and trust emphasizing that careful scrutiny and a high bar of consent and trust
need to be applied. Given the known threat of pervasive monitoring, the need to be applied. Given the known threat of pervasive monitoring, the
application of these principles is critical to ensuring that the use application of these principles is critical to ensuring that the use
of path signals does not create a disproportionate opportunity for observers of path signals does not create a disproportionate opportunity for observers
to extract new data from flows.</t> to extract new data from flows.</t>
<section anchor="intent" numbered="true" toc="default">
<name>Intentional Distribution</name>
<t>The following guideline is best expressed in <xref target="RFC8558" f
ormat="default"/>:</t>
<blockquote>Fundamentally, this document recommends that implicit
signals should be avoided and that an implicit signal should be
replaced with an 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 result in the signal being absent but allows it to be
present when needed.</blockquote>
<section anchor="intent" title="Intentional Distribution"> <!-- [rfced] We would like to rephrase this information as follows for
clarity and to reduce redundancy. Please let us know if the
<t>This guideline is best expressed in <xref target="RFC8558"/>:</t> preferred text is agreeable or if you prefer otherwise.
<t>“Fundamentally, this document recommends that implicit signals
should be avoided and that an implicit signal should be replaced
with an 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 result in the signal being absent but allows it to
be present when needed.”</t>
<t>The goal is that any information should be provided knowingly, for a
specific purpose, sent in signals designed for that purpose, and that
any use of information should be done within that purpose. And that
an analysis of the security and privacy implications of the specific
purpose and associated information is needed.</t>
<t>This guideline applies in the network element to application direction as wel
l: a
network element should not unintentionally leak information. While this document
makes recommendations that are applicable to many different situations,
it is important to note that the above call
for careful analysis is key. Different types of information,
different applications, and different directions of communication influence the
the analysis, and can lead to very different conclusions about what information
can be
shared or with whom. For instance, it is easy to find examples of information
that applications should not share with network elements (e.g., content of commu
nications)
or network elements should not share with applications (e.g., detailed user loca
tion in
a wireless network). But, equally, information about other things such as the on
set
of congestion should be possible to share, and can be beneficial information to
all parties.</t>
<t>Intentional distribution is a precondition for explicit collaboration enablin
g
each entity to have the highest posssible level of control about what informatio
n
to share.</t>
</section>
<section anchor="control-distr" title="Control of the Distribution of Informatio
n">
<t>Explicit signals are not enough. The entities
also need to agree to exchange the information.
Trust and mutual agreement between the involved entities must determine
the distribution of information, in order to give adequate control to
each entity over the collaboration or information sharing. This can
be achieved as discussed below.</t>
<t>The sender needs to decide that it is willing to send information to a specif
ic entity or
set of entities.
Any passing of information or request for an action needs to be explicit,
and use signalling mechanisms that are designed for the purpose.
Merely sending a particular kind of packet to a destination should not
be interpreted as an implicit agreement.</t>
<t>At the same time, the recipient of information or the target of a
request should have the option to agree or deny to receiving the information. It
should not be burdened with extra processing if it does not have
willingness or a need to do so. This happens naturally in most
protocol designs, but has been a problem for some cases where
“slow path” packet processing is required or implied, and the
recipient or router is not willing to handle this. Performance
impacts like this are best avoided, however.</t>
<t>In any case, all involved entities must be identified and
potentially authenticated if trust is required as a prerequisite
to share certain information.</t>
<t>Many Internet communications are not performed on behalf of the applications,
but are
ultimately made on behalf of users. However, not all information
that may be shared directly relates to user actions or other
sensitive 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.
As discussed in <xref target="RFC8890"/>, from an IETF point view, the interests
of the user should be
prioritized over those of the application developer. The general issue
of how to achieve a balance of control between the actual user and an applicatio
n
representing an user’s interest is out of scope for this document.</t>
</section>
<section anchor="auth" title="Protecting Information and Authentication">
<t>Some simple forms of information often exist in cleartext
form, e.g, ECN bits from routers are generally not authenticated
or integrity protected. This is possible when the information
exchanges do not carry any significantly sensitive information
from the parties. Often these kind of interactions are also advisory
in their nature (see also section <xref target="impact"/>).</t>
<t>In other cases it may be necessary to establish a secure
signalling channel for communication with a specific other party, e.g.,
between a network element and an application. This channel
may need to be authenticated, integrity protected and confidential.
This is necessary, for instance, if the particular information or
request needs to be shared in confidence only with a particular,
trusted network element or endpoint, or there’s a danger of an attack where some
one else
may forge messages that could endanger the communication.</t>
<t>Authenticated integrity protections on signalled data can help
ensure that data received in a signal has not been modified by
other parties. Still, both network elements and endpoints need to
be careful in processing or responding to any signal. Whether
through bugs or attacks, the content of path signals can lead
to unexpected behaviors or security vulnerabilities if not
properly handled. As a result, the advice in <xref target="impact"/> still
applies even in situations where there’s a secure channel for
sending information.</t>
<t>However, it is important to note that authentication does not equal
trust. Whether a communication is with an application server or
network element that can be shown to be associated with a particular
domain name, it does not follow that information about the user can be
safely sent to it.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="minimize-info" title="Minimize Information">
<t>Each party should provide only the information that is needed for the
other parties to perform the task for which collaboration is desired,
and no more. This applies to information sent by an
application about itself, information sent about users, or information
sent by the network. This also applies to any information
related to flow identification.</t>
<t>An architecture can follow the guideline from <xref target="RFC8558"/> in usi
ng
explicit signals, but still fail to differentiate properly between
information that should be kept private and information that should be
shared. <xref target="RFC6973"/> also outlines this principle of data minimizati
on
as mitigation technique to protect privacy and provides further guidance.</t>
<t>In looking at what information can or cannot easily be passed, we
need to consider both, information from the network to the application
and from the application to the network.</t>
<t>For the application to the network direction, user-identifying
information can be problematic for privacy and tracking reasons.
Similarly, application identity can be problematic, if it might form
the basis for prioritization or discrimination that the
application provider may not wish to happen.</t>
<t>On the other hand, as noted above, information about general classes
of applications may be desirable to be given by application providers,
if it enables prioritization that would improve service, e.g.,
differentiation between interactive and non-interactive services.</t>
<t>For the network to application direction there is similarly sensitive
information, such as the precise location of the user. On the other
hand, various generic network conditions, predictive bandwidth and
latency capabilities, and so on might be attractive information that
applications can use to determine, for instance, optimal strategies
for changing codecs. However, information given by the network about
load conditions and so on should not form a mechanism to provide a
side-channel into what other users are doing.</t>
<t>While information needs to be specific and provided on a per-need
basis, it is often beneficial to provide declarative information that,
for instance, expresses application needs than makes specific requests
for action.</t>
</section>
<section anchor="impact" title="Limiting Impact of Information">
<t>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.</t>
<t>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.</t>
<t>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
<xref target="RFC7129"/>.</t>
</section>
<section anchor="min-ents" title="Minimum Set of Entities">
<t>It is recommended that a design identifies the minimum number of
entities needed to share a specific signal required for an identified
function.</t>
<t>Often this will be a very limited set, such as when an application Original:
only needs to provide a signal to its peer at the other end of the The goal is that any information should be provided knowingly, for a
connection or a host needs to contact a specific VPN gateway. In specific purpose, sent in signals designed for that purpose, and that
other cases a broader set is needed, such as when explicit or any use of information should be done within that purpose. And that
implicit signals from a potentially unknown set of multiple routers an analysis of the security and privacy implications of the specific
along the path inform the endpoints about congestion.</t> purpose and associated information is needed.
<t>While it is tempting to consider removing these limitations in the Perhaps:
context of closed, private networks, each interaction is still best The goal is that any information should be provided knowingly for a
considered separately, rather than simply allowing all information specific purpose, sent in signals designed for that purpose, and used
exchanges within the closed network. Even in a closed network with within that purpose. In addition, an analysis of the security and privacy
carefully managed elements there may be compromised components, as implications of the specific purpose and associated information is needed.
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.</t>
</section> <t>The goal is that any information should be provided knowingly, for
<section anchor="info-carry" title="Carrying Information"> a specific purpose, sent in signals designed for that purpose, and that
any use of information should be done within that purpose. In
addition, an analysis of the security and privacy implications of the
specific purpose and associated information is needed.</t>
<t>This guideline applies in the network element to application
direction as well: a network element should not unintentionally leak
information. While this document makes recommendations that are
applicable to many different situations, it is important to note that
the above call for careful analysis is key. Different types of
information, applications, and directions of
communication influence the analysis and can lead to very
different conclusions about what information can be shared and with
whom. For instance, it is easy to find examples of information that
applications should not share with network elements (e.g., content of
communications) or that network elements should not share with
applications (e.g., detailed user location in a wireless
network). But, equally, information about other things, such as the
onset of congestion, should be possible to share and can be beneficial
information to all parties.</t>
<t>Intentional distribution is a precondition for explicit
collaboration that enables each entity to have the highest possible leve
l
of control about what information to share.</t>
</section>
<section anchor="control-distr" numbered="true" toc="default">
<name>Control of the Distribution of Information</name>
<t>Explicit signals are not enough. The entities also need to agree to
exchange the information. Trust and mutual agreement between the
involved entities must determine the distribution of information in
order to give each entity adequate control over the collaboration
or information sharing. This can be achieved as discussed
below.</t>
<t>The sender needs to decide that it is willing to send information
to a specific entity or set of entities. Any passing of information
or request for an action needs to be explicit and use signaling
mechanisms that are designed for the purpose. Merely sending a
particular kind of packet to a destination should not be interpreted
as an implicit agreement.</t>
<t>At the same time, the recipient of information or the target of a
request should have the option to agree or deny to receiving the
information. It should not be burdened with extra processing if it
does not have willingness or a need to do so. This happens naturally
in most protocol designs, but it has been a problem for some cases where
"slow path" packet processing is required or implied, and the
recipient or router is not willing to handle it. Performance impacts
like this are best avoided, however.</t>
<t>In any case, all involved entities must be identified and
potentially authenticated if trust is required as a prerequisite to
share certain information.</t>
<t>Many Internet communications are not performed on behalf of the
applications but are ultimately made on behalf of users. However, not
all information that may be shared directly relates to user actions or
other sensitive data. All shared information 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. As
discussed in <xref target="RFC8890" format="default"/>, from an IETF
point of view, the interests of the user should be prioritized over thos
e
of the application developer. The general issue of how to achieve a
balance of control between the actual user and an application
representing a user's interest is out of scope for this document.</t>
</section>
<section anchor="auth" numbered="true" toc="default">
<name>Protecting Information and Authentication</name>
<t>Some simple forms of information often exist in cleartext form,
e.g., Explicit Congestion Notification (ECN) bits from routers are
generally not authenticated or integrity protected. This is possible
when the information exchanges do not carry any significantly
sensitive information from the parties. Often, these kinds of
interactions are also advisory in their nature (see <xref
target="impact" format="default"/>).</t>
<t>In other cases, it may be necessary to establish a secure
signaling channel for communication with a specific other party,
e.g., between a network element and an application. This channel may
need to be authenticated, integrity protected, and confidential. This
is necessary, for instance, if the particular information or request
needs to be shared in confidence only with a particular, trusted
network element or endpoint or if there is danger of an attack where
someone else may forge messages that could endanger the
communication.</t>
<t>Authenticated integrity protections on signaled data can help
ensure that data received in a signal has not been modified by other
parties. Still, both network elements and endpoints need to be careful
in processing or responding to any signal. Whether through bugs or
attacks, the content of path signals can lead to unexpected behaviors
or security vulnerabilities if not properly handled. As a result, the
advice in <xref target="impact" format="default"/> still applies even
in situations where there's a secure channel for sending
information.</t>
<t>However, it is important to note that authentication does not equal
trust.
<t>There is a distinction between what information is sent and how it Whether a communication is with an application server or
is sent. The actually sent information may be limited, while the network element that can be shown to be associated with a particular
domain name, it does not follow that information about the user can be
safely sent to it.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="minimize-info" numbered="true" toc="default">
<name>Minimize Information</name>
<t>Each party should provide only the information that is needed for
the other parties to perform the task for which collaboration is
desired and no more. This applies to information sent by an
application about itself, sent about users, or
sent by the network. This also applies to any information related to
flow identification.</t>
<t>An architecture can follow the guideline from <xref
target="RFC8558" format="default"/> in using explicit signals but
still fail to differentiate properly between information that should
be kept private and information that should be shared. <xref
target="RFC6973" format="default"/> also outlines this principle of
data minimization as a mitigation technique to protect privacy and
provides further guidance.</t>
<t>In looking at what information can or cannot be easily passed, we
need to consider both information from the network to the application
and from the application to the network.</t>
<t>For the application-to-network direction, user-identifying
information can be problematic for privacy and tracking reasons.
Similarly, application identity can be problematic if it might form
the basis for prioritization or discrimination that the application
provider may not wish to happen.</t>
<t>On the other hand, as noted above, information about general
classes of applications may be desirable to be given by application
providers if it enables prioritization that would improve service,
e.g., differentiation between interactive and non-interactive
services.</t>
<t>For the network-to-application direction, there is similarly
sensitive information, such as the precise location of the user. On
the other hand, various generic network conditions, predictive
bandwidth and latency capabilities, and so on might be attractive
information that applications can use to determine, for instance,
optimal strategies for changing codecs. However, information given by
the network about load conditions and so on should not form a
mechanism to provide a side channel into what other users are
doing.</t>
<t>While information needs to be specific and provided on a per-need
basis, it is often beneficial to provide declarative information that,
for instance, expresses application needs and then makes specific reques
ts
for action.</t>
</section>
<section anchor="impact" numbered="true" toc="default">
<name>Limiting Impact of Information</name>
<t>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 it needs to be scoped to a specific network path.<
/t>
<t>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.</t>
<t>In many cases, path signals can be considered 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 <xref target="RFC7129"
format="default"/>.</t>
</section>
<section anchor="min-ents" numbered="true" toc="default">
<name>Minimum Set of Entities</name>
<t>It is recommended that a design identifies the minimum number of
entities needed to share a specific signal required for an identified
function.</t>
<t>Often, this will be a very limited set, such as when an application
only needs to provide a signal to its peer at the other end of the
connection or a host needs to contact a specific VPN gateway. In other
cases, a broader set is needed, such as when explicit or implicit
signals from a potentially unknown set of multiple routers along the
path inform the endpoints about congestion.</t>
<t>While it is tempting to consider removing these limitations in the
context of closed, private networks, each interaction is still best
considered separately, rather than simply allowing all information
exchanges within the closed network. Even in a closed network with
carefully managed elements, there may be compromised components, as
evidenced in the most extreme way by the Stuxnet worm that operated in
an air-gapped 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.</t>
</section>
<section anchor="info-carry" numbered="true" toc="default">
<name>Carrying Information</name>
<t>There is a distinction between what information is sent and how it
is sent. The information that is actually sent 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
sharing much more.</t> sharing much more.</t>
<t>There is a trade-off here between flexibility and ensuring that
<t>There is a tradeoff here between flexibility and ensuring the the information is minimal 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 some could potentially be misused, e.g., by making the availability of some
information a requirement for passing through a network, such as information a requirement for passing through a network, such as
making it mandatory to identify specific applications or users. This is making it mandatory to identify specific applications or users. This is
undesirable.</t> undesirable.</t>
<t>This document recommends that signaling mechanisms that send
<t>This document recommends that signalling mechanisms that send information information be built to specifically support sending the necessary,
are built to specifically support sending the necessary, minimal set of informat minimal set of information (see <xref target="minimize-info"
ion (see <xref target="minimize-info"/>) format="default"/>) and no more. As previously noted, flow-identifying
and no more. As previously noted, flow-identifying information is a path signal information is a path signal in itself, and as such, provisioning of
in itself, flow identifiers also requires protocol-specific analysis.</t>
and as such provisioning of flow identifiers also requires protocol specific ana <t>Further, such mechanisms also need to have the ability to
lysis.</t> establish an agreement (see <xref target="control-distr"
format="default"/>) and sufficient trust to pass the
<t>Further, such mechanisms also need have an ability for establishing an agreem information (see <xref target="auth" format="default"/>).</t>
ent (see <xref target="control-distr"/>) and to establish </section>
sufficient trust to pass the information (see <xref target="auth"/>).</t> </section>
<section anchor="research" numbered="true" toc="default">
</section> <name>Further Work</name>
</section> <t>This is a developing field, and it is expected that our understanding
<section anchor="research" title="Further Work"> of it will continue to grow. One recent change is much higher use of
encryption at different protocol layers. This obviously impacts the
<t>This is a developing field, and it is expected that our understanding field greatly, by removing the ability to use most implicit signals.
will continue to grow. One recent change is much higher use However, it may also provide new tools for secure collaboration and
of encryption at different protocol layers. This obviously impacts force a rethinking of how collaboration should be performed.</t>
the field greatly, by removing the ability to use most implicit signals. <t>While there are some examples of modern, well-designed collaboration
But it may also provide new tools for secure collaboration, and force mechanisms, the list of examples is not long. Clearly, more work is
a rethinking of how collaboration should be performed.</t> needed if we wish to realize the potential benefits of collaboration in
further cases. This requires a mindset change, a migration away from
<t>While there are some examples of modern, well-designed collaboration using implicit signals. And of course we need to choose such cases where
mechanisms, the list of examples is not long. Clearly more work is needed, if the collaboration
we wish to realize the potential benefits of collaboration in further cases. can be performed safely, where it is not a privacy concern, and where the
This requires a mindset change, a migration away from using implicit signals. incentives of the relevant parties are aligned. It
And of course, we need to choose such cases where the collaboration can should also be noted that many complex cases would require significant
be performed safely, is not a privacy concern, and the incentives of developments in order to become feasible.</t>
the relevant parties are aligned. It should also be noted that many complex case <t>Some of the most difficult areas are listed below. Research on
s would
require significant developments in order to become feasible.</t>
<t>Some of the most difficult areas are listed below. Research on<vspace />
these topics would be welcome. Note that the topics include these topics would be welcome. Note that the topics include
both those dealing directly with on-path network element collaboration, both those dealing directly with on-path network element collaboration
as well as some adjacent issues that would influence such collaboration.</t> and some adjacent issues that would influence such collaboration.</t>
<t><list style="symbols">
<t>Some forms of collaboration may depend on business arrangements, which may
or
may not be easy to put in place. For instance, some
quality-of-service mechanisms involve an expectation of paying for a
service. This is possible and has been successful within individual
domains, e.g., users can pay for higher data rates or data caps in
their ISP networks. However, it is a business-wise much harder
proposition for end-to-end connections across multiple
administrative domains <xref target="Claffy2015"/>
<xref target="RFC9049"/>.</t>
<t>Secure communications with path elements is needed as discussed in <xref ta
rget="auth"/>. Finding practical
ways for this has been difficult, both from the mechanics and scalability point
view. And 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 network eleme
nts or endpoints.</t>
<t>The use of path signals for reducing the effects of
denial-of-service attacks, e.g., perhaps modern forms of “source
quench” designs could be developed. The difficulty is finding a solution
that would be both effective against attacks and would not enable third
parties from slowing down or censoring someone else’s commmunication.</t>
<t>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 parties, 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 <xref target="Oblivious"/> <xref target="PDoT"/>
<xref target="I-D.arkko-dns-confidential"/> <xref target="I-D.thomson-http-obliv
ious"/>.
These solutions address also very specific parts of the issue,
and more work remains.</t>
<t>Sharing information from networks to applications. There are some
working examples of this, e.g., ECN. A few other proposals have been
made (see, e.g., <xref target="I-D.flinck-mobile-throughput-guidance"/>), but
very few of those have seen deployment.</t>
<t>Sharing information from applications to networks. There are a few more
working examples of this (see <xref target="intro"/>). 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 <xref target="RFC9049"/>. Several current or recent proposals exist,
however, such as <xref target="I-D.yiakoumis-network-tokens"/>.</t>
<t>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.</t>
<t>The present work has
focused on the technical aspects of making collabration safe and
mutually beneficial, but of course, deployments need to take into account variou
s
regulatory and other policy matters. These include privacy regulation,
competitive issues &amp; network neutrality aspects, and so on.</t>
</list></t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors would like to thank everyone at the IETF, the IAB, and our <!--[rfced] Some of the bullet points in this list begin with a
day jobs for interesting thoughts and proposals in this space. complete sentence and some begin with a fragmented sentence (see
Fragments of this document were also in #4, #5, and #6). Please let us know if/how we may make the list
<xref target="I-D.per-app-networking-considerations"/> and parallel.
<xref target="I-D.arkko-path-signals-information"/> that were published earlier.
We
would also like to acknowledge <xref target="I-D.trammell-stackevo-explicit-coop
"/>
for presenting similar thoughts. Finally, the authors would like to
thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark
Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew
Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David
Schinazi, Cullen Jennings, Mallory
Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for useful feedback on this topi
c
and this draft.</t>
</section> Original:
* Some forms of collaboration may depend on business arrangements,
which may or may not be easy to put in place.
</middle> * Secure communications with path elements is needed as discussed in
Section 2.3.
<back> * The use of path signals for reducing the effects of denial-of-
service attacks, e.g., perhaps modern forms of "source quench"
designs could be developed.
<references title='Informative References'> * Ways of protecting information when held by network elements or
servers, beyond communications security.
<reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793"> * Sharing information from networks to applications.
<front>
<title>Transmission Control Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>
<reference anchor="RFC5218" target="https://www.rfc-editor.org/info/rfc5218"> * Sharing information from applications to networks.
<front>
<title>What Makes for a Successful Protocol?</title>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<date month="July" year="2008"/>
<abstract>
<t>The Internet community has specified a large number of protocols to dat
e, and these protocols have achieved varying degrees of success. Based on case
studies, this document attempts to ascertain factors that contribute to or hinde
r a protocol's success. It is hoped that these observations can serve as guidan
ce for future protocol work. This memo provides information for the Internet co
mmunity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5218"/>
<seriesInfo name="DOI" value="10.17487/RFC5218"/>
</reference>
<reference anchor="RFC6709" target="https://www.rfc-editor.org/info/rfc6709"> * Data privacy regimes generally deal with more issues than merely
<front> whether some information is shared with another party or not.
<title>Design Considerations for Protocol Extensions</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="B. Aboba" initials="B." role="editor" surname="Aboba"/>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<date month="September" year="2012"/>
<abstract>
<t>This document discusses architectural issues related to the extensibili
ty of Internet protocols, with a focus on design considerations. It is intended
to assist designers of both base protocols and extensions. Case studies are in
cluded. A companion document, RFC 4775 (BCP 125), discusses procedures relating
to the extensibility of IETF protocols. This document is not an Internet Stand
ards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6709"/>
<seriesInfo name="DOI" value="10.17487/RFC6709"/>
</reference>
<reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973"> * The present work has focused on the technical aspects of making
<front> collaboration safe and mutually beneficial, but of course,
<title>Privacy Considerations for Internet Protocols</title> deployments need to take into account various regulatory and other
<author fullname="A. Cooper" initials="A." surname="Cooper"/> policy matters.
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> -->
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="J. Morris" initials="J." surname="Morris"/>
<author fullname="M. Hansen" initials="M." surname="Hansen"/>
<author fullname="R. Smith" initials="R." surname="Smith"/>
<date month="July" year="2013"/>
<abstract>
<t>This document offers guidance for developing privacy considerations for
inclusion in protocol specifications. It aims to make designers, implementers,
and users of Internet protocols aware of privacy-related design choices. It su
ggests that whether any individual RFC warrants a specific privacy consideration
s section will depend on the document's content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6973"/>
<seriesInfo name="DOI" value="10.17487/RFC6973"/>
</reference>
<reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258"> <ul spacing="normal">
<front> <li>Some forms of collaboration may depend on business arrangements,
<title>Pervasive Monitoring Is an Attack</title> which may or may not be easy to put in place. For instance, some
<author fullname="S. Farrell" initials="S." surname="Farrell"/> quality-of-service mechanisms involve an expectation of paying for a
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> service. This is possible and has been successful within individual
<date month="May" year="2014"/> domains, e.g., users can pay for higher data rates or data caps in
<abstract> their ISP networks. However, it is a business-wise
<t>Pervasive monitoring is a technical attack that should be mitigated in proposition that is much harder for end-to-end connections across multip
the design of IETF protocols, where possible.</t> le administrative
</abstract> domains <xref target="Claffy2015" format="default"/> <xref
</front> target="RFC9049" format="default"/>.</li>
<seriesInfo name="BCP" value="188"/> <li>Secure communication with path elements is needed as discussed
<seriesInfo name="RFC" value="7258"/> in <xref target="auth" format="default"/>.
<seriesInfo name="DOI" value="10.17487/RFC7258"/> Finding practical ways for
</reference> this has been difficult, both from the mechanics and scalability point
of view, partially because there is no easy way to find out which partie
s
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 network elements or endpoints.</li>
<li>The use of path signals to reduce the effects of
denial-of-service attacks, e.g., perhaps modern forms of "source
quench" designs, could be developed. The difficulty is finding a
solution that would be both effective against attacks and would not
enable third parties from slowing down or censoring someone else's
communication.</li>
<reference anchor="RFC7305" target="https://www.rfc-editor.org/info/rfc7305"> <li>Work has begun on mechanisms that dissociate the information held by servers
<front> from knowledge of the user's network location and behavior. Among the solutions
<title>Report from the IAB Workshop on Internet Technology Adoption and Tran that exist for this but are not widely deployed are <xref target="Oblivious" fo
sition (ITAT)</title> rmat="default"/> <xref target="PDoT" format="default"/> <xref target="I-D.arkko-
<author fullname="E. Lear" initials="E." role="editor" surname="Lear"/> dns-confidential" format="default"/> <xref target="I-D.thomson-http-oblivious" f
<date month="July" year="2014"/> ormat="default"/>. These solutions address specific parts of the issue, and more
<abstract> work remains to find ways to limit the spread of information about the user's a
<t>This document provides an overview of a workshop held by the Internet A ctions. Host applications currently share sensitive information about the user'
rchitecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). T s action with a variety of infrastructure and path elements, starting from basic
he workshop was hosted by the University of Cambridge on December 4th and 5th of data, such as domain names, source and destination addresses, and protocol head
2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of I er information. This can expand to detailed end-user identity and other informa
nternet protocols, through examination of a variety of economic models, with par tion learned by the servers. Work to protect all of this information is needed.
ticular emphasis at the waist of the hourglass (e.g., the middle of the protocol </li>
stack). This report summarizes contributions and discussions. As the topics wer
e wide ranging, there is no single set of recommendations for IETF participants
to pursue at this time. Instead, in the classic sense of early research, the wor
kshop noted areas that deserve further exploration.</t>
<t>Note that this document is a report on the proceedings of the workshop.
The views and positions documented in this report are those of the workshop par
ticipants and do not necessarily reflect IAB views and positions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7305"/>
<seriesInfo name="DOI" value="10.17487/RFC7305"/>
</reference>
<reference anchor="RFC8558" target="https://www.rfc-editor.org/info/rfc8558"> <li>Work is needed to explore how to increase the deployment of mechanisms for s
<front> haring information from networks to applications. There are some working example
<title>Transport Protocol Path Signals</title> s of this, e.g., ECN. A few other proposals have been made (see, e.g., <xref ta
<author fullname="T. Hardie" initials="T." role="editor" surname="Hardie"/> rget="I-D.flinck-mobile-throughput-guidance" format="default"/>), but very few o
<date month="April" year="2019"/> f those have seen deployment.</li>
<abstract>
<t>This document discusses the nature of signals seen by on-path elements
examining transport protocols, contrasting implicit and explicit signals. For e
xample, TCP's state machine uses a series of well-known messages that are exchan
ged in the clear. Because these are visible to network elements on the path bet
ween the two nodes setting up the transport connection, they are often used as s
ignals by those network elements. In transports that do not exchange these mess
ages in the clear, on-path network elements lack those signals. Often, the remo
val of those signals is intended by those moving the messages to confidential ch
annels. Where the endpoints desire that network elements along the path receive
these signals, this document recommends explicit signals be used.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8558"/>
<seriesInfo name="DOI" value="10.17487/RFC8558"/>
</reference>
<reference anchor="RFC8890" target="https://www.rfc-editor.org/info/rfc8890"> <li>Additional work on sharing information from applications to networks would a
<front> lso be valuable. There are a few working examples of this (see Section 1). Numer
<title>The Internet is for End Users</title> ous proposals have been made in this space, but most of them have not progressed
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/> through standards or been deployed for a variety of reasons <xref target="RFC90
<date month="August" year="2020"/> 49" format="default"/>. However, several current or recent proposals exist, such
<abstract> as <xref target="I-D.yiakoumis-network-tokens" format="default"/>.</li>
<t>This document explains why the IAB believes that, when there is a confl
ict between the interests of end users of the Internet and other parties, IETF d
ecisions should favor end users. It also explores how the IETF can more effecti
vely achieve this.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8890"/>
<seriesInfo name="DOI" value="10.17487/RFC8890"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000"> <!--
<front> <li>Ways of protecting information when held by network elements or
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> servers, beyond communications security. For instance, host
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/ applications commonly share sensitive information about the user's
> actions with other parties, starting from basic data, such as domain
<author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/ names learned by DNS infrastructure or source and destination
> addresses and protocol header information learned by all routers on
<date month="May" year="2021"/> the path, to detailed end-user identity and other information learned
<abstract> by the servers. Some solutions are starting to exist for this but are
<t>This document defines the core of the QUIC transport protocol. QUIC pr not widely deployed, at least not today <xref target="Oblivious"
ovides applications with flow-controlled streams for structured communication, l format="default"/> <xref target="PDoT" format="default"/> <xref
ow-latency connection establishment, and network path migration. QUIC includes target="I-D.arkko-dns-confidential" format="default"/> <xref
security measures that ensure confidentiality, integrity, and availability in a target="I-D.thomson-http-oblivious" format="default"/>. These
range of deployment circumstances. Accompanying documents describe the integrat solutions address also very specific parts of the issue, and more work
ion of TLS for key negotiation, loss detection, and an exemplary congestion cont remains.</li>
rol algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9049" target="https://www.rfc-editor.org/info/rfc9049"> <li>Sharing information from networks to applications. There are some
<front> working examples of this, e.g., ECN. A few other proposals have been
<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads N made (see, e.g., <xref target="I-D.flinck-mobile-throughput-guidance"
ot Taken)</title> format="default"/>), but very few of those have seen deployment.</li>
<author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins"/
>
<date month="June" year="2021"/>
<abstract>
<t>This document is a product of the Path Aware Networking Research Group
(PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog
and analyze past efforts to develop and deploy Path Aware techniques, most of w
hich were unsuccessful or at most partially successful, in order to extract insi
ghts and lessons for Path Aware networking researchers.</t>
<t>This document contains that catalog and analysis.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9049"/>
<seriesInfo name="DOI" value="10.17487/RFC9049"/>
</reference>
<reference anchor="RFC9075" target="https://www.rfc-editor.org/info/rfc9075"> <li>Sharing information from applications to networks. There are a few
<front> working examples of this (see <xref target="intro"
<title>Report from the IAB COVID-19 Network Impacts Workshop 2020</title> format="default"/>). Numerous proposals have been made in
<author fullname="J. Arkko" initials="J." surname="Arkko"/> this space, but most of them have not progressed through standards or
<author fullname="S. Farrell" initials="S." surname="Farrell"/> been deployed for a variety of reasons <xref target="RFC9049"
<author fullname="M. Kühlewind" initials="M." surname="Kühlewind"/> format="default"/>. However, several current or recent proposals exist,
<author fullname="C. Perkins" initials="C." surname="Perkins"/> such as <xref target="I-D.yiakoumis-network-tokens"
<date month="July" year="2021"/> format="default"/>.</li>
<abstract> -->
<t>The Coronavirus disease (COVID-19) pandemic caused changes in Internet <li>Data privacy regimes generally deal with multiple issues, not just
user behavior, particularly during the introduction of initial quarantine and wo whether or not some information is shared with another party. For
rk-from-home arrangements. These behavior changes drove changes in Internet traf instance, there may be rules regarding how long information can be
fic.</t> stored or what purpose that information may be used for. Similar
<t>The Internet Architecture Board (IAB) held a workshop to discuss networ issues may also be applicable to the kind of information sharing
k impacts of the pandemic on November 9-13, 2020. The workshop was held to conve discussed in this document.</li>
ne interested researchers, network operators, network management experts, and In <li>The present work has focused on the technical aspects of making
ternet technologists to share their experiences. The meeting was held online giv collaboration safe and mutually beneficial, but of course, deployments
en the ongoing travel and contact restrictions at that time.</t> need to take into account various regulatory and other policy
<t>Note that this document is a report on the proceedings of the workshop. matters. These include privacy regulation, competitive issues, network
The views and positions documented in this report are those of the workshop par neutrality aspects, and so on.</li>
ticipants and do not necessarily reflect IAB views and positions.</t> </ul>
</abstract> </section>
</front> <section anchor="iana-considerations" numbered="true" toc="include">
<seriesInfo name="RFC" value="9075"/> <name>IANA Considerations</name>
<seriesInfo name="DOI" value="10.17487/RFC9075"/> <t>This document has no IANA actions.</t>
</reference> </section>
<section anchor="security-considerations" numbered="true" toc="include">
<name>Security Considerations</name>
<t>This document has no security considerations.</t>
</section>
</middle>
<back>
<displayreference target="I-D.per-app-networking-considerations" to="PER-APP-NET
WORKING"/>
<displayreference target="I-D.arkko-path-signals-information" to="PATH-SIGNALS-I
NFO"/>
<displayreference target="I-D.trammell-stackevo-explicit-coop" to="EXPLICIT-COOP
"/>
<displayreference target="I-D.flinck-mobile-throughput-guidance" to="MOBILE-THRO
UGHPUT-GUIDANCE"/>
<displayreference target="I-D.arkko-dns-confidential" to="DNS-CONFIDENTIAL"/>
<displayreference target="I-D.thomson-http-oblivious" to="HTTP-OBLIVIOUS"/>
<displayreference target="I-D.yiakoumis-network-tokens" to="NETWORK-TOKENS"/>
<reference anchor="I-D.ietf-quic-manageability" target="https://datatracker.ietf <references>
.org/doc/html/draft-ietf-quic-manageability-18"> <name>Informative References</name>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.521
<title>Manageability of the QUIC Transport Protocol</title> 8.xml"/>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.670
<organization>Ericsson</organization> 9.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.697
<author fullname="Brian Trammell" initials="B." surname="Trammell"> 3.xml"/>
<organization>Google Switzerland GmbH</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.725
</author> 8.xml"/>
<date day="15" month="July" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.730
<abstract> 5.xml"/>
<t>This document discusses manageability of the QUIC transport protocol an <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.855
d focuses on the implications of QUIC's design and wire image on network operati 8.xml"/>
ons involving QUIC traffic. It is intended as a "user's manual" for the wire ima <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889
ge to provide guidance for network operators and equipment vendors who rely on t 0.xml"/>
he use of transport-aware network functions.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.900
</abstract> 0.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-manageability-18"/> 3.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.904
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.907
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.931
2.xml"/>
<reference anchor="I-D.per-app-networking-considerations" target="https://datatr <!-- [I-D.per-app-networking-considerations] IESG state Expired -->
acker.ietf.org/doc/html/draft-per-app-networking-considerations-00"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.p
<front> er-app-networking-considerations.xml"/>
<title>Per-Application Networking Considerations</title>
<author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
<organization>Google</organization>
</author>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<date day="15" month="November" year="2020"/>
<abstract>
<t>This document describes considerations for and implications of using ap
plication identifiers as a method of differentiating traffic on networks. Specif
ically, it discusses privacy considerations, possible mitigations, and considera
tions for user experience and API design. Discussion Venues This note is to be r
emoved before publishing as an RFC. Source for this draft and an issue tracker c
an be found at https://github.com/tfpauly/per-app-networking-considerations.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-per-app-networking-consideratio
ns-00"/>
</reference>
<reference anchor="I-D.arkko-path-signals-information" target="https://datatrack <!-- [I-D.arkko-path-signals-information] IESG state Expired -->
er.ietf.org/doc/html/draft-arkko-path-signals-information-00"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.a
<front> rkko-path-signals-information.xml"/>
<title>Considerations on Information Passed between Networks and Application
s</title>
<author fullname="Jari Arkko" initials="J." surname="Arkko">
<organization>Ericsson</organization>
</author>
<date day="22" month="February" year="2021"/>
<abstract>
<t>Path signals are messages seen by on-path elements examining transport
protocols. Current preference for good protocol design indicates desire for cons
tructing explict rather than implicit signals to carry information. For instance
, the ability of various middleboxes to read TCP messaging was an implicit signa
l that lead to difficulties in evolving the TCP protocol without breaking connec
tivity through some of those middleboxes. This document discusses the types of i
nformation that could be passed in these path signals, and provides some advice
on what types of information might be provided in a beneficial manner, and which
information might be less likely to be revealed or used by applications or netw
orks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-arkko-path-signals-information-
00"/>
</reference>
<!-- [I-D.trammell-stackevo-explicit-coop] IESG state Expired. Updated to long v ersion because output is not showing editor role-->
<reference anchor="I-D.trammell-stackevo-explicit-coop" target="https://datatrac ker.ietf.org/doc/html/draft-trammell-stackevo-explicit-coop-00"> <reference anchor="I-D.trammell-stackevo-explicit-coop" target="https://datatrac ker.ietf.org/doc/html/draft-trammell-stackevo-explicit-coop-00">
<front> <front>
<title>Architectural Considerations for Transport Evolution with Explicit Pa <title>
th Cooperation</title> Architectural Considerations for Transport Evolution with Explicit Path Cooperat
<author fullname="Brian Trammell" initials="B." surname="Trammell"> ion
<organization>ETH Zurich</organization> </title>
</author> <author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor"
<date day="23" month="September" year="2015"/> >
<abstract> <organization>ETH Zurich</organization>
<t>The IAB Stack Evolution in a Middlebox Internet (SEMI) workshop in Zuri </author>
ch in January 2015 and the follow-up Substrate Protocol for User Datagrams (SPUD <date month="September" day="23" year="2015"/>
) BoF session at the IETF 92 meeting in Dallas in March 2015 identified the pote </front>
ntial need for a UDP-based encapsulation to allow explicit cooperation with midd <seriesInfo name="Internet-Draft" value="draft-trammell-stackevo-explicit-coop-0
leboxes while using encryption at the transport layer and above to protect user 0"/>
payload and metadata from inspection and interference. This document proposes a
set of architectural considerations for such approaches.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-stackevo-explicit-coop
-00"/>
</reference> </reference>
<!-- [I-D.flinck-mobile-throughput-guidance] IESG state Expired. Updated to
long version because Yanai's name is showing as "R.B Yanai" instead of
"R. Bar Yanai".
-->
<reference anchor="I-D.flinck-mobile-throughput-guidance" target="https://datatr acker.ietf.org/doc/html/draft-flinck-mobile-throughput-guidance-04"> <reference anchor="I-D.flinck-mobile-throughput-guidance" target="https://datatr acker.ietf.org/doc/html/draft-flinck-mobile-throughput-guidance-04">
<front> <front>
<title>Mobile Throughput Guidance Inband Signaling Protocol</title> <title>
<author fullname="Ankur Jain" initials="A." surname="Jain"> Mobile Throughput Guidance Inband Signaling Protocol
<organization>Google</organization> </title>
</author> <author initials="A." surname="Jain" fullname="Ankur Jain">
<author fullname="Andreas Terzis" initials="A." surname="Terzis"> <organization>Google</organization>
<organization>Google</organization> </author>
</author> <author initials="A." surname="Terzis" fullname="Andreas Terzis">
<author fullname="Hannu Flinck" initials="H." surname="Flinck"> <organization>Google</organization>
<organization>Nokia Networks</organization> </author>
</author> <author initials="H." surname="Flinck" fullname="Hannu Flinck">
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher"> <organization>Nokia Networks</organization>
<organization>Nokia Networks</organization> </author>
</author> <author initials="N." surname="Sprecher" fullname="Nurit Sprecher">
<author fullname="Swaminathan Arunachalam" initials="S." surname="Arunachala <organization>Nokia Networks</organization>
m"> </author>
<organization>Nokia Networks</organization> <author initials="S." surname="Arunachalam" fullname="Swaminathan Arunachalam">
</author> <organization>Nokia Networks</organization>
<author fullname="Kevin Smith" initials="K." surname="Smith"> </author>
<organization>Vodafone</organization> <author initials="K." surname="Smith" fullname="Kevin Smith">
</author> <organization>Vodafone</organization>
<author fullname="Vijay Devarapalli" initials="V." surname="Devarapalli"> </author>
<organization>Vasona Networks</organization> <author initials="V." surname="Devarapalli" fullname="Vijay Devarapalli">
</author> <organization>Vasona Networks</organization>
<author fullname="Roni Bar Yanai" initials="R. B." surname="Yanai"> </author>
<organization>Vasona Networks</organization> <author initials="R." surname="Bar Yanai" fullname="Roni Bar Yanai">
</author> <organization>Vasona Networks</organization>
<date day="13" month="March" year="2017"/> </author>
<abstract> <date month="March" day="13" year="2017"/>
<t>The bandwidth available for end user devices in cellular networks can v </front>
ary by an order of magnitude over a few seconds due to changes in the underlying <seriesInfo name="Internet-Draft" value="draft-flinck-mobile-throughput-guidance
radio channel conditions, as device mobility and changes in system load as othe -04"/>
r devices enter and leave the network. Furthermore, packets losses are not alway
s signs of congestion. The Transmission Control Protocol (TCP) can have difficul
ties adapting to these rapidly varying conditions leading to inefficient use of
a cellular network's resources and degraded application performance. Problem sta
tement, requirements and the architecture for a solution is documented in [Req_A
rch_MTG_Exposure]. This document proposes a mechanism and protocol elements that
allow the cellular network to provide near real-time information on capacity av
ailable to the TCP server. This "Throughput Guidance" (TG) information would ind
icate the throughput estimated to be available at the radio downlink interface (
between the Radio Access Network (RAN) and the mobile device (UE)). TCP server c
an use this TG information to ensure high network utilization and high service d
elivery performance. The document describes the applicability of the proposed me
chanism for video delivery over cellular networks; it also presents test results
from live operator's environment.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-flinck-mobile-throughput-guidan
ce-04"/>
</reference> </reference>
<reference anchor="I-D.arkko-dns-confidential" target="https://datatracker.ietf. <!-- [I-D.arkko-dns-confidential] IESG state Expired -->
org/doc/html/draft-arkko-dns-confidential-02"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.a
<front> rkko-dns-confidential.xml"/>
<title>Privacy Improvements for DNS Resolution with Confidential Computing</
title>
<author fullname="Jari Arkko" initials="J." surname="Arkko">
<organization>Ericsson</organization>
</author>
<author fullname="Jiri Novotny" initials="J." surname="Novotny">
<organization>Ericsson</organization>
</author>
<date day="2" month="July" year="2021"/>
<abstract>
<t>Data leaks are a serious privacy problem for Internet users. Data in fl
ight and at rest can be protected with traditional communications security and d
ata encryption. Protecting data in use is more difficult. In addition, failure t
o protect data in use can lead to disclosing session or encryption keys needed f
or protecting data in flight or at rest. This document discusses the use of Conf
idential Computing, to reduce the risk of leaks from data in use. Our example us
e case is in the context of DNS resolution services. The document looks at the o
perational implications of running services in a way that even the owner of the
service or compute platform cannot access user-specific information produced by
the resolution process.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-arkko-dns-confidential-02"/>
</reference>
<reference anchor="I-D.thomson-http-oblivious" target="https://datatracker.ietf. <!-- [I-D.thomson-http-oblivious] IESG state Expired -->
org/doc/html/draft-thomson-http-oblivious-02"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.t
<front> homson-http-oblivious.xml"/>
<title>Oblivious HTTP</title>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
<organization>Cloudflare</organization>
</author>
<date day="24" month="August" year="2021"/>
<abstract>
<t>This document describes a system for the forwarding of encrypted HTTP m
essages. This allows a client to make multiple requests of a server without the
server being able to link those requests to the client or to identify the reques
ts as having come from the same client.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-thomson-http-oblivious-02"/>
</reference>
<!-- [I-D.yiakoumis-network-tokens] IESG state Expired. Updated to long version because date is showing as "December 22" instead of "December 21" -->
<reference anchor="I-D.yiakoumis-network-tokens" target="https://datatracker.iet f.org/doc/html/draft-yiakoumis-network-tokens-02"> <reference anchor="I-D.yiakoumis-network-tokens" target="https://datatracker.iet f.org/doc/html/draft-yiakoumis-network-tokens-02">
<front> <front>
<title>Network Tokens</title> <title>Network Tokens</title>
<author fullname="Yiannis Yiakoumis" initials="Y." surname="Yiakoumis"> <author initials="Y." surname="Yiakoumis" fullname="Yiannis Yiakoumis">
<organization>Selfie Networks</organization> <organization>Selfie Networks</organization>
</author> </author>
<author fullname="Nick McKeown" initials="N." surname="McKeown"> <author initials="N." surname="McKeown" fullname="Nick McKeown">
<organization>Stanford University</organization> <organization>Stanford University</organization>
</author> </author>
<author fullname="Frode Sorensen" initials="F." surname="Sorensen"> <author initials="F." surname="Sorensen" fullname="Frode Sorensen">
<organization>Norwegian Communications Authority</organization> <organization>Norwegian Communications Authority</organization>
</author> </author>
<date day="22" month="December" year="2020"/> <date month="December" day="21" year="2020"/>
<abstract> </front>
<t>Network tokens is a method for endpoints to explicitly and securely coo <seriesInfo name="Internet-Draft" value="draft-yiakoumis-network-tokens-02"/>
rdinate with networks about how their traffic is treated. They are inserted by e
ndpoints in existing protocols, interpreted by trusted networks, and may be sign
ed or encrypted to meet security and privacy requirements. Network tokens provid
e a means for network operators to expose datapath services (such as a zero-rati
ng service, a user-driven QoS service, or a firewall whitelist), and for end use
rs and application providers to access such services. Network tokens are inspire
d and derived by existing security tokens (like JWT and CWT), and borrow several
of their core ideas along with security and privacy properties.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-yiakoumis-network-tokens-02"/>
</reference>
<reference anchor="Claffy2015" >
<front>
<title>Adding Enhanced Services to the Internet: Lessons from History</title
>
<author initials="." surname="kc Claffy">
<organization></organization>
</author>
<author initials="D." surname="Clark">
<organization></organization>
</author>
<date year="2015" month="April"/>
</front>
<seriesInfo name="TPRC 43: The 43rd Research Conference on Communication, Info
rmation and Internet Policy Paper" value=""/>
</reference>
<reference anchor="Oblivious" >
<front>
<title>Oblivious DNS: Practical privacy for DNS queries</title>
<author initials="P." surname="Schmitt">
<organization></organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="Proceedings on Privacy Enhancing Technologies 2019.2: 228-24
4" value=""/>
</reference>
<reference anchor="PDoT" >
<front>
<title>PDoT: Private DNS-over-TLS with TEE Support</title>
<author initials="Y." surname="Nakatsuka">
<organization></organization>
</author>
<author initials="A." surname="Paverd">
<organization></organization>
</author>
<author initials="G." surname="Tsudik">
<organization></organization>
</author>
<date year="2021" month="February"/>
</front>
<seriesInfo name="Digit. Threat.: Res. Pract., Vol. 2, No. 1, Article 3, https
://dl.acm.org/doi/fullHtml/10.1145/3431171" value=""/>
</reference> </reference>
<reference anchor="RFC7129" target="https://www.rfc-editor.org/info/rfc7129"> <reference anchor="Claffy2015" target="https://papers.ssrn.com/sol3/papers
<front> .cfm?abstract_id=2587262">
<title>Authenticated Denial of Existence in the DNS</title> <front>
<author fullname="R. Gieben" initials="R." surname="Gieben"/> <title>Adding Enhanced Services to the Internet: Lessons from History<
<author fullname="W. Mekking" initials="W." surname="Mekking"/> /title>
<date month="February" year="2014"/> <author initials="kc" surname="claffy" fullname="kc claffy" >
<abstract> <organization/>
<t>Authenticated denial of existence allows a resolver to validate that a </author>
certain domain name does not exist. It is also used to signal that a domain name <author initials="D." surname="Clark" fullname="David Clark">
exists but does not have the specific resource record (RR) type you were asking <organization/>
for. When returning a negative DNS Security Extensions (DNSSEC) response, a nam </author>
e server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), t <date year="2015" month="November"/>
his amount is three.</t> </front>
<t>This document provides additional background commentary and some contex <refcontent>TPRC 43: The 43rd Research Conference on Communication,
t for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated deni Information and Internet Policy Paper</refcontent>
al-of-existence responses.</t> <seriesInfo name="DOI" value="10.2139/ssrn.2587262"/>
</abstract> </reference>
</front>
<seriesInfo name="RFC" value="7129"/>
<seriesInfo name="DOI" value="10.17487/RFC7129"/>
</reference>
</references> <reference anchor="Oblivious">
<front>
<title>Oblivious DNS: Practical Privacy for DNS Queries</title>
<author initials="P." surname="Schmitt" fullname="Paul Schmitt">
<organization/>
</author>
<author initials="A." surname="Edmundson" fullname="Anne Edmundson">
<organization/>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization/>
</author>
<author initials="N." surname="Feamster" fullname="Nick Feamster">
<organization/>
</author>
<date year="2018" month="December"/>
</front>
<refcontent>Proceedings on Privacy Enhancing Technologies, Volume 2019,
Issue 2, pp. 228-244</refcontent>
<seriesInfo name="DOI" value="10.2478/popets-2019-0028"/>
</reference>
</back> <reference anchor="PDoT">
<front>
<title>PDoT: Private DNS-over-TLS with TEE Support</title>
<author initials="Y." surname="Nakatsuka" fullname="Yoshimichi Nakatsu
ka">
<organization/>
</author>
<author initials="A." surname="Paverd" fullname="Andrew Paverd">
<organization/>
</author>
<author initials="G." surname="Tsudik" fullname="Gene Tsudik">
<organization/>
</author>
<date year="2021" month="February"/>
</front>
<refcontent>Digital Threats: Research and Practice, Volume 2, Issue 1,
Article No. 3, pp. 1-22</refcontent>
<seriesInfo name="DOI" value="10.1145/3431171"/>
</reference>
<!-- ##markdown-source: <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.712
H4sIAA1h92MAA419XZMbx7Hle/2KCjLiSnQAEElJV+LowaZIyqKvSPGac63Y 9.xml"/>
3djYaKALQGsa3XB/zBBizD+7b/vHNk9+VFU3QHodtmM406iuysrKPHkys7Bc </references>
Lt1QDXW48i/apq/K0BVDRT/5tvHPj8e62vC//dK/DcNd293Qc3VdrFt5zv9X
XzU7/64Y9v59tWuKunfFet2F26vJL/VTrmw3TXGgt5VdsR2WVbFeHumxZS+P
LTf54MvHX7uyGMKVo0mEXdudrnzVbFvnqmN35Ydu7Ienjx8/e/zU3YQTTa68
8q+bIXRNGJYv8QLn+qFoyv9T1G1DLz2F3h2rK/+/hnaz8H3bDV3Y9vTT6YAf
/rdzxTjs2+7Keb+k/3l6XX/l/7byz7ubm5Z/I9P/W9FV2S/bbnflX3XVpu/b
hn8TDkVVX/nf6blVgef+EvTPq017cNMXXK/8z0VXViF7w3Uo81/yG15U/abN
hx9CuarCsP3LDv++PPK7YqxP+cDt4XDKfssjY6vDZOQjHvhLgd9fGPfNyv/H
//3vfR3uqqbMBn9Tdb8X8z99UjoHPL26GYM+PZORa9ruQJpwSxpAe047H//p
/d9/evH4u2df64/fPn3y/ZWXn//9u8fP9Nf//uw7e+K7p9/GJ777+vG39vP3
39Lv9cfvnz3WH589fpx+/OZZ/PE7+dzr5UuW+/KfY7VZHoqm2IViXdXVcLrS
Px9DtyTpLRs5NnRKSLnzE2YPsnZMT0FcatvYU0NXHA6hrpek0JubcNsuwwec
zmqgYdujPbatq2Zzszy0NJmwHPZdO+72x3FY7saqLJpNmL61bHDkmi3Nqhmq
oo5v27cH2oblfhiOy3ZdV7dVO8YZn6riph0PVW+LWw7tTZAVvaiL7fb09PGT
b694p71alwfPyxKW4lWzxzRK/z50t9Um9H5o/bAP8eBe+V8CVKD32649+J+r
fqCD/0AG60lBQg/x0IjX7/7+wn/zNWk0ffybr7vS/z30oeg2e9iybegCvQh2
7AVp/NioJVvQm6J0PRmH+Gb/riWB4mjQ3ukL2fzQ6eiq2mNR8ttkJeg/SzkR
Nxtd++S3L1f4bXdDv/w1F2MUS/ytf/n2PdnMrtgMNNPa0ytvC5oNzRV/8v8c
ee0PoH46LZrQMzebjr733cq/3+wP1TC4udjede0mBGwGG/l3+h7ZGGzRddjs
m7Zud/QZfsfqKb3r6ffLp998A7G8e9leT9bAv5CBhoDJLttb0v7rX977u4p8
wPWrV/79eDySvX3wifn+j5V/W9wUQz/eFPnvn8N+0WBl/su/rvx1P5bVTRLF
T2HdjUV3ovk+fXK25JfVrhroQ/suFMPqCnqyElGvFv4fbb3yTxf+bbvyTxZk
1En+dfBfLzy0v7/66quyXhWbw4rM2FdlW321Hev65+FQf/Xk8erJk2++/err
b75+8uS7J7w2t1wufbHuB4zu3PW+6j05vfFAB8yXZL/Hviex0u6SsMm29rzB
ZcDRh/APJPyiqfoDHYx9MfixJxXu6Pn2lg6pg5nwaiYWrL2kK7UMwq6OPEbv
oUO0tVXj+2PYVNtq42+LeizWtK5NQe9fObJmHqYPr9501Rpzysb2RU9T6Xuy
a3xCaXg+jmQT+LFQB6yoXzjM4dhW9LNvx0EmfVv1Fd6V2THShLr264AFlf5u
H+jMd74afNWTZR9CU9Kv6aWFzgBvbFretJBLi9Y0TGRadHhPHMCZoWORwLCI
bH279WYx/VSKd/uKTAbGIYPRjh2tucSaabKMB2AaAUBKljfNpB5pJwryXk11
oJn2ZDpo9GNBmiPS4r9Uf0wF0O8JCzQ7XlE/WdOmaBy9rNjsq3CLd4vZznWh
rm54et3pyIPR+6qpGXOB9p+MSb+HGjE28l2oxdfsq2NP6xnuQmg81sMzxQdZ
FivHanuoypJQgHsIk9i15Shq9PFhhX/ekw/++FE95v09yXVbNVgvyZgM6ME/
yMX6AJtpynSuQM4UiMTRlsVppny0F+2W9tRXB9myhQ8rEh05zwoSwlCOTimJ
PHwYaEUluaBl4O1JUlmf5FPhQ4EdYbEUTQ875OhAEQhsa5rATzQ3sisDtGZx
puF8Am9p62Cjt1Wo6XyR9GnV7vrFO78PBU3Ks2CAR0gwtFqZ53SL1jge2Uxp
a2hDT47kdEeOHfIiV0znDY+vvKrJAGNckfHv/Z4MoSfPX0MC67ApMDPMY3LM
cIZuCV3xYWeF1TV0gcBKRx9tWnoRgeWqsZNJ+1E0J4LIUE46XAdak+9HOhXZ
6w8tTkjRV/WJ1nes2xO/gg5844oaLpSx2YKswSBogh6UD9m5I0EDrDACwpOE
j7qW1B7m2Lmf2ztS/24hB5z0gA5SoP0Sm1KkYKTndSn2ULmIuph0SCpVx2ah
E1vosEhsAAHLYxfoTPfYILUNMBX79k5enH2Kzmw71qXb08tpdHpKbMWXevQf
TS0cnoXVaMi9Qknp+cJvQjcUZLW2Y8NjrsQn7GmfarEzMHnDqGOQVSTRQ+1P
k8FZBjKP3juxTroZaburXswrtJn0ko/m2SBxmrTGkTdJ5rtyz3vddDyWfc4d
6ICuMRSkV4eBtg4/d13Y0MmkZbYNT7es8Bv6sQsk5J60gDdaz4t3Z3Op+rNZ
kO3xBWFFwWqkaLDsZCnZXrmZ0Ttzl3cQn+xq3IGy2jIYHOIeuJrM8yCmi1VG
sbtNNBoHuBsov2yco6n14+FAOGMhkhqbY100DYs8ak2PU+7HIxQTRqeHVpOf
aMJOxBFoPpuBcKD7k/+176vtCY+ll64hSzHA+MNEBrTzBGXN36nPIeDBq8c+
kdNkN3skYESf1omStkHBxcKv2w9mTlgQcmAEamw9rFrLXqan+b0AZOJVnEin
DoQkaOdxvG9piGJXQNXUHDB8wXnvw2bsGLa08PJ3Va/zoReRKHrhF7ZpxfSe
HwsmEvRQ0wogPHLGnnHMTG3O9NGzCVeNzGdNXrotQ63nykaPHpAsE31Anb2Y
sxZyIIF2OOjnBpzAk8z/WPQ8Y3XWzk3dyJYmQELoo/iB4enfbT2KA+888DFh
B1GUQDMIjePjuw5ki82ItR2BVwAi3vQh7SepJmLu5ZoAXem2FUww44s3z1/g
BNHLettmjC2mgY/EhuIu9jakZPWC8McR++ngGOF+Zx9BgFYQ/ACo98np/nx9
/c6ZOASLksWG6/pyinrpZyilyM+QH1ljEvNRwp0gLn/XtiUEsy7KhUBDs4T9
YNu5LTYKMuH5opT53P9L4a0eOfeGPF3UvKn94I0UEBs8x9n0upo/jIWJHbtr
jY0iBbry5wDxqHHQJo86o7ljS6n42LHxJ6me4jmcYsmFujV+N3k3cpX+AZ38
Bz/wm8Zm8nZ3HAn/bT7xYvanBszx4rpO58GwTo4IX304tuJM0hmIAJn0n+L3
gp3ooW0qitHZ2Ih/JExvYQU+D+rEg38RmISf7u9FY3CSeWbr4KJ+YgGh21SI
gscOs+jZy2AeND9S+Eoinqj0SSMmMIEeoUE76CKrIBxDF1buR9rjggAYbTAJ
G5LI4GfNC2HJBTFgdCAa0kjMlffJ5OaE+DnwsSzDetzt5LMSeJhTwUwjWIEm
0Wnj6EB0tFciBMAAWoyTcICScqSmlivbIYexbed43hQ/WIBIcmwIl7PsbOCF
X9N6xUWzfztxxBExYJAonZ1hU0osR254kI0pxFlNVkRC08HtvV3PgSCLSxa5
xhM09J5PGykdHbF2Q45BlABU2v09qZmCDkV9CQnhH+0hkKg4QiIvA2QLbAAX
QnicVkhwvgztdusstDHSpBALMNmCM7HRLC2sjg7VEAIJYApHK9Z4AmA8iZF8
PmwoTaM+kd2s6Yc/6ONkTGDRSCf/UKeBiPaP0LVLAg5pdSv/FhaxrieAxlwK
Bz206rrt1U/yquaRCs2HP0v/mAzDdEFQ/ivqvsJ/5iBoYDk0gZ0AjPQ6sH1l
zxDKhVNAQO9janA4JbXOsgIVu4iVf08KTTKo6Sk7GymWYes99hNDUrZBvAL7
GtqJjmRdJIs0tEcwUKRqnVNrjCFIGHIi+VjnTgfgbENeHzZE4Aj7HkT9KWqm
TYS538nic3VbuVfpMdUK6HGr3Ir6ypq3JwcF4kqFBSGnwkfFYFELbGeiWgOo
txV4N5chuAm4wyiyT7IZjBYPBT+MbaYo6Zohva7UfXKlcQmkrC0zb/ROOggs
aeOh2c1AqC5SoGBPK6wCAE5jjlv1rBaLS3RbJB7iOA7OQvctRwMSQsfD5Cng
E6dP04nRYG5u6ZxgXmT3IRVHwooEVcY5rOYo6z//6/ULBBtkymmtQK54v0Xr
ZyEjxU6MFlIU7iaUA0yk7Ch7SZrFxCguZADszSRqUIP2+DHN0DueE+t3YA86
1ftQKlTIBRWt+4DQnN5xCBDByKd0Ji/l+ozXA2hnR5GAIeb8/khHc10NDg8r
04BoGutXR8JKTWaM5/X6pew2XImRdDQDV7cURq6LGuImw/7x42cyH1j9tUTQ
KXTkCC+XKLytrbsMkgKAf8qlVPUGiBwjr/okeDGtduVfAQw14S7+zixcH8NH
sidFHnMrTalg7q7Q49CDMxDTxr4FSRyxjaQU27HWeNKRrt/NImN2CwUsJjxZ
I7aJwDGEjL/R+OGAI5p2UZg5Zm5zEkY9mIsbazHKIumfz6iiiSeLZJr7x7u3
osuFoGlQXxQhMcwRKTGegE3teIb5gczQpMXXFLO2Q5V4IhrFDHz+5ogyLWCA
BTTjOLRpVZD22AHt+OfnbxPZHPB/a3ZNbKYYQ7p1C4VhgoGzZxzPJtEkseaY
2M6MY+7xoszEiWCwi3/+xMDJ3mHgBJscG+hdCwJ7C4sJO8zBfQZMeEQFmNHy
Ro+YIwtwIqKkh9Z09BxVTuyHooIMCLoM1PwWlNOKHJHMUcbmI6FImlQl2W/S
KBfpaaxBiTOcP/oQv7iXDE9Sp0kuX3EsWSS4XWC1os/mSOqgoTJifsivt4mu
AxMl162a7zN6CnpHqGagcGMclIpp5PwzIAHS2mwYx+A3P9BgzKIAtQ6GFPMN
kmMs7s4iCTo/BMmnr4kz0CHz+c2pt/jJqX2z7Oec0eEAT0bdQY85kZEPMUsA
qDbxpzfVMTpn/LIj9bgtmsHGFiXtg4oZisSeCnPnvc3fAx9K1uufwtFhmwML
bgF/HSrYS80BTQ2R+2sLvafB74quXLCmpAQVa22lJ+DV9U9M/rEWbdvNyFGO
MhgRqu2KI9yHABv8liwmHR2fUc/9jBJk57ceq5qfT9rMG2R4GEHGTFXNFmeG
98ICfwvsLWPaRUZCcLqJnKFx182JBWDnNU7FqY6bqWNN/41j6MhRsTnEA2xn
2zPNCh8Y04Y/e/6s2GE8xCQ1RR2Thwsb+hRTaeAcWP5/ng0gPKUsgfdPbZ5O
Gshw/hF7p/IYcRE6RkysVY0w9WeT7qrdfkh7qE6I+XTS4sBmVQyoYKXbcJJV
3FQ4uZNTQYO71+S0A0VS7Y0YqrMtEG8ZU29IRi3oI25bsWVgtrHhyBmG5ND2
g56rg5BDJIwuMkas3rz48ajw0SVdIA27RYqlbYXXWUgw3jNdHCPKKe8PlqOo
ajhR4R74TZv2yD59ahK67HSIyiXnLXAPOkSq+zKmm8/ApUXSn0q3zDK/ERCL
njNZNjHMnOIh40pGrD5ZiIQAkyKatSR0z1UZqjnz9xFhkFkGTdkItE0eFnKB
lVJ+AsxuV3EFSD77xNgw3cJ0JgWogUxjkQdOjH7PhBPTUmC5SZwg6G+ZxouE
Yh4YkKR/jGxkim9i6JxFNgsxhc9/5MRQnMR27OCLUlJbZiivEh+88v75gWJt
9VrGupKB5uFRGHV/n+LBHblcJCMI6hL0djyRjcQERR3zegIxmFlmThD/LeoT
eDdwP6PQBKIYUE9EVawP/E4UYCFBnFU7mHQ+DMi8qXg4tx8BUCw7ObnnpSQg
ePxr5GwZz/svX18/v37E3oOO3RGRHw6fsIpfP/6WXmpblEeTFCzzmWjN4BVk
qE0QQ3usNiuL4b55Jsykf/138komzEWUnwOKJkm1uzEIUdtDK/tRUjMc4ZsT
1cVn+RIm321tFHZPkt55+MaWkiPEcVBAx6c1ZY8z4rrtnPkPhpqhW2aRHZiT
sLJKFBRFZnNLqbGUijVAcAHEGc2hqpQpZcYbSO2S1TZwMtywokuzhsTTY7m2
uPzTOPQcyOgg8LhbmlJ7p7Fmr8vkTY+7xK5YYx8N/T8gUxdxUSR+zDWRbZdx
1Za4aX0GOR/kU1tMu9MqMxyrGFGyGuV+DjZC87TwPsDNgxoOCStr5LC2LYOu
UxKmRuA7UhiwWg9RV2UT+fgwE5luqQkgMT4ZhbMUnzmrNppZECNv45HpJWkm
Gs34Lw82pliJGbhI5AAW7SuKNy+xN4LtkOTQaJAhJY0xS1i0/sGcGHkghGS2
jkl+YVYRxFPOqxDIeaI260+ReMipJ/p8qMR2mreRh9NDEvpqdG+xlsJXC4e9
VDuyG0SqEekGS4fra4WIJzAgbrIe2T1lhzod2575hDx8P58605kT0UXn3cSQ
lHe28B0ZktBJfiePcynumrxlvuZCOA038/7/X6+WoNletwS5jay8QyaUkwPd
wm9JRHeADUaw4pfAKpKS9JKS9M/fvdaPkLt72w4SZDkJUycTETxHo23CUQsL
CMgpyWrQjT2b39JpX5DDRpnR1gkU2wt3ckSN7fCD4DP8isN8jhVb1YOYosu5
TbfJEs9jPVR46jSdIWxxcROg6DvOhS403J6cUomCFOzvxUbnMSrn2MmJOl5q
JyGqlphNi6Bi1VcezJyjuXA4EvSo/ohgztgvOmeEL5uTbueeADrJr8P7LCqJ
rIbLID4jSBR0+L/ClvFSbpr2Dj9BSuw+LyYRZ3k83bSphKCAtH4ulbXQO08E
chafHXTmYiPHwtsUuDakBz4lLQNfgEKCjCxnByx5rE6KbkDtIQGNaIhwXCF6
AUXCgX3IhXPGPfiXOTjnIjr6k5lt2PtA54xJuDVFCPBQnLIvZ9Dwim3Xg59G
Qo4H5TAWM5OXmW7ByYcpcuWK2H0s/AFKUSJH49P5J7KnlV7nCly1CXNkLBTt
3V53WX75RW/p96HtlODgicgMh5xnznNzeTJaOA2YKc59IRLDCCxwlQGysiQ3
OmxmkXVOmtFas4bC8BZw7z3ePHATxRoKxVVKMnUtQHqQcXhVFsBPazlNOhGq
Q7XphdgbKTtKpKcmsRee34WqXNPHvFCJXxQfjXuDyjwrzbk8hZLZbNqZqpkM
Atsug7gZgGcpqQFJNQtkWeacFz+oy3A6rNiBvm83VTHjwbjUQ4vJ5mou5mDu
NhOB3E4Si9EVG+d9BYnOP6QywInWlJrRfsBrN/nUVl6AyeTcuAMZ4n4WmfXJ
ieuMtGLiIAygIeYEIReumoameLoxL6WsLThWIB4OW822xk0BgREoInoZhx9O
x9DPNn3hJoA9btVCQw77WxY2s5XOHXUCHjCzPDedhNWTR7ArpSlpWLiaeuyN
y+BqnhkVq+jVsSPlYh42GXf79jBPX4vMQtEzrch0S0Ts02W78wLQbOfFZ/Nr
zkzIl6j/XcQk91wY/SN3iUW/PPjk/TpwGQaKfmmhnCqv2yhjihPvKhCvfaSc
Hq38jyMKmYVLXVwoLmsVSXBvRh4Pws+SKRCXG9PqyQi1fazr4RmnrVxPSkIm
lXStVr4YKZz7rjldXcBUgvGQQPzTIaJnXgdJ7pxqpHdJop/WAgABf4dJy6wj
sacg8BPK5Wx14mpf6MNqpl7O2PG8y+fjQx15yeu65+KmKbVjmD00KAITasLY
S8fBpUGbYtcFlnRkq2aM7Mpdx5zRYQQIlc8cpM5C4Jh8RsuVp1wvKVVAvC+n
8zOsP8cubYdMPvIEgFFFCfUaQhQl/WGyE1zEJ4Uf+a7xybzYq1Cd9ycUfYzW
oX4IxsVnSm4gkfllQNolOnwaCl0gDNMkkXCmkH6a/+T6jxmXvKLA6BRrZeZ5
kI6JfegXe+HGemHinNapHl0oTPjWLOyZVxQX84JixiTqYd0bsoy1ULiC+iUD
M9YEkI2RlmBCllfi7DYTD05a59aSAerokA3aB5NBsqg9CAqVAQaFhdqohXGL
1bFSEzeTB/dnFN1OpFg4k0/G4ouNOcZdYA3ntqTGSkZCFVnWiVd9PbjMXMLa
jKSQkBUbTQbMAEkbzeVUW2jCpPzHqVI0MJYMneyolaQlrSqh1b43BXNMHNcx
He9mdIbWu+05vxi4oFHqz6RwgtM9qbLOPehJfxlkPrCdyqfbp76JVnOCoTR4
Flwm+M6CbK13zVQd9YOKPVb+XSrb8o4GLFAyxP090vfQBYkHFKUvkJtGIZrU
n1th4ELJ9osWBOrEZVvbSmC+y9mQaclqZfmUfKmFWnz+BQGdEG1v7GeYGDyp
qo1U7oWIHBJRJlM4ZVR411uz3lM0w2id9gYR9EEyB9ySMvkYl4BlZXpNe5aA
cHm1uEKSrEcBdTG9Vnx33or3rWyd7A7zzmgToVCP0PQsu6EDmsQDt9hBpJHg
g9R0IzJC6jLa3lqx6mriuhi+X5pzLNCbHj+dlLW72FNf9M7SP6jsTNABMLXM
U9a0haR9Ef2LaEiDZqxHjk4mwB2+HC0+i9iNUNScedu0CN7L8IOwsxM4hUfv
kEPlpF5dI+3IXOkZRkqFiUy4xH9JVwuO0cqjpjQ5qBhNf//sMch9pXIk7yxE
1W0V7hafWX8UF1jhFrQDij3VlbZ9uKDFSRCCJSzdwLkCADnuN2rNqXJZcy1s
esJBOViQPpm4H+za0utc7LiR5J9uelwPl56P7AEkeSieLIuFBFS9kwQdBpm3
Sc/qdT4+hB0hKPUeu8l1+jzqYY7erTXrQ9Vz8Bs7CBAJHbixb+FfvXiLcjWt
pxFDqk0BIrhadWlS8K68wo7j2JhbtCq0PuHiSE3kxsHwWyyRpXPbndjCcnoU
DHUziHdXQ5B/nGcaiy5Q0fQrL1SoqpSOzvqCOKbkouryturb7uQkGq46cWvB
f9kHfcR4/Y8fxUfc3z8SDyAHUVxYFa1byh4DmcaahEKbcVyGcLDqhgC3ldqn
2FArvCIGS2f+JA2Yi1hpXZxF8OdKafBR3sddZDk/mG/l4tJGapVcup5A6/iY
ZdDlCtuSRZXbrBCGYdgUDkX4kwNCNZpQTn3bRqtBVSJpuIVjbxnOKFT4DeNY
rVa6C1/AkZbQsk5qiHwxcGOJNvrR2QF7E+o+sHxoqhRQpM5rJmLZ+ICe4GEE
vE8J5edTlz4XZaUXuqgSwAuCvER8uA/10eWFS/wXre1hkcSObCAq8TIByKsU
dLE+TV3Dyr9HgmMhCfyz2FqKBoyKVnUA/jVKpGpy/MV4vj+2Aq9hL/V0omTs
N+klctYvvR53AiBZxP3C5wXucy7YeA7HtWDSCMbhDDeedTxQ5MhuxxpWiPPW
TGJxNQiQJxl4UhMBeCVXsRVKRy6spBRtElV+kDUF5IwSkxREkyclRT2SCmlL
XX50nQUdUyQW8dBnOalZqWfE40xOiIpH+aJydEoh9ZEIzj2eEOU4Y2fkXlZa
TL70rjETkFjEs4PmyhaV79zjtpjEDJKnPS8DFNYgOm15n+uLrUZoLIJq0D7O
GAfoPqXWFpmFFLvt44u0eytS0u6MXZkTXMAYL96886HrjN7ltgzJq+JGhqp0
oLLNhjPiYdmT9Ib9SSAOI+s0zqYuqoMehg0Wwb3w3BjDBXO0vF8zDyH0uJS6
SXPmuMYEGYiS/CmWargcdzJ3lzkBLYDtOpgf3k6dbvQyfGzMLWQ7aGrAniF3
C7920lhul4wYmMxtvUNv58hIRCWtCaWsb4c10NZwphBO7YikGGxXOZTk08rG
rckrlEDxNhxpERR6Y5c4TJkku9uBL+kBkwRyRYZWmGiT07r1Cy3YkSY3QmFq
QvMyXone+xt+UrrrpsxN1WtbWyl0RiPlSep7zcRA8/PQhakoYJ1Jok1OEMGw
UG8X5x+QP2vrzZQxcjZixu3bFBjwpHnMcilOYhreVj4MFrkm59ZM21JSDQi/
LaUYGJHlBQfcnsRc5IzuyzPxWl6XeG7WhGjarRj0bBNTDHUTjkNs+yzmrNbk
WSXGtd4I11PRNFlCJNpa79OosvthuMoPLln1Tutw6GCTJ9rpK+ySBj0aENQk
WRxrQ7SeLFabiC1EfQqHDZ8g9Dlh0bB7kBsHQDlz1wNXShqmi21F8PxT9YlY
OfV3zQMmVt74XK6V+qxplfQAff6hlAFZsL4uLQqHMlzIVyhDRL/baIVMXq5P
YALiQc8VV2Zk3W6TZjjtlLsw6EJ5rwNXt+L1TssQKivJ0bgy0nYIYDtY+kyN
5olxa76MobbF0EKWwRWct7EKigO6Rk7qUhrCYlVyNVyQBZ84j9bXwop2lhyz
kiW2KhemiCQZi8DqPmcrzq6msI4EbTG1yCM/n3lhQ4ywbrXUs22W+e9Sf21U
nEwLLycdB2uP6W2rUxDoJgx8zoMgRYK7DmIeKOMQVt7ne+FkL6xTjSVOupdq
rDTT0qP0ED1jvJQ1feiuKhl6lc7aujbFMSLTrCVSlQ2OcxhMGHPLNO2X3ghx
INS9JiHmARZ3L6NAgMakMAPpEQ4kra9y05Zhk/Ny+SujiuS7ILwOd5qldWfr
yAgu7QBP5eE5FnCwPkuDyNy0z+Ys6xgVNr/NK9Xy6U1iQsM/mQEttUGeDAoe
dXx+DWkLzZEl27K5kUjqQm69OduChZsK2OpAJv2LNjUAQklaZy1VHNDKNli/
GwDML6gXZyaH447zpJjGI/ABZ6zmv4zzY5UXJxWygtMoRM4sFLHTpdJZyCmw
OAsfh79wn69PQi3DyXI5VrOSpnAh5GAhpQrmPPib7HPqMnPTWvX4WUw3pigv
9MhpOwJOU0w6ZNhYjuRaq/btxh/bvUkxnlgozYKnAEJnLcTlxcqJTBaarLNG
vJTu346MnpLgrVokUSWTDrgv1bS5rGXaekK4NE+SJT0gMscl0lQukl7GBSbN
eLRwjLomfLX5D7nNKlbNodyygwXTm2DZxuHJeIFXpnH4eM3pOKCZdHfC4jzi
n7YVahSqZNy00iLdiSBdMCjBlIsblJcoyt/HfjC55PqclXE61r1UCcS1TK9F
p7gdk+PNWAW5JtdxI1ZUhrhFiR9rjJjOfdsPeUeoClPvX9IMoh4QcUr4hNRC
ubFJV0Vd2H1M7gdvtx0IGUby7jMVs67paQpJBJx8YYHLbt6/erGcPkbwqJK+
SOaCoZTu48c/o3b/ydNn3N1tYdd48O8lX/nKElsceS1hC2CwNF0Va/x1yVYm
HrNf066kZjysmYhzMV+mcVhMb2WbpccuJsU0oZwyay7d6eWM+9UcN+vV2dUu
SURMSM8ofN7EaJqiW7N5MHmBWyjAyAwZrAvCNAMcZoeCE6m8+XFI7CdMcLbG
f7x7yw2Gd8UJeulycrnw667l2+2QgY8x62wR2eVubl52aCYrzz6OjRSBalZf
zjsppHL+Dlc17yLLomdSDmLyEGu5yi3elhedufSRhcNxiBSJBiXcQquntdeL
rxT2CAnvmCn8IFVCMCflIgZ1dn3LQhro8iviABIH2fF+cJlx0aaigDAhrxHW
K40KazaY5yxTWiLW9AWdUIqs/SvlDIvZn+Q2v9RiIA1PZdYizNBWITzfhtce
KgyAn9tGW6J7F26FBy+tYo9b36y3HZ3CCuPeD+MHJH3vZJ8AuPiGP2nbho5X
3Q7xSD79NxjsgUz9wewqPxqhDjA7zNGx9jpp7OTLANvYV86FD7EfL6afFQPn
bsZxQ4Mktu0OnH1RapUFQbZBAplI+K6LrquMCXqBvNA8JYaC3m275JwRF/Va
Qz1X7FRiGCKMunRxQCydBslojdGNXnkar8XTmtH0Sd06NSt85VItxXxZ6QqX
Oig/nGpi5rXh5hHVuZJdtAryA44480iTpdmFO55/ZYvb1mTQlT+dNQXSpOSq
ROVWJyIQvRJcIqvWYvZUd+slj27xETMhNkdrWYrzSJWKdXFitN+kK/Iki5Jb
IjCuVT/yQZdyvjXOy425dHWW6cojUsfpBYTmGxiHcRg/vRQuobVkNJ2+gVN3
KDltJWcX6wRS4HHpKquY3HRoYNcAHLdnXn+2IPwzBU7zOizHFShjVbPfn/Tq
WIu/aZZEcTETN7sQNxcV5zU/fpySp/ePpozlc7ACgW/DlnQvdgacYE7fnDWY
TpA9ClOEvpTGF+WW2ZmicFVLxiZEI2uK9AzqBSKxoigLAqVGFhBdODTd0Uya
qUpQzFgzuathcj0v/hZLAlU20xLF+0fWbhI/6Ppxi9CSQb+1QEPjzkhmHZET
9Jw2fuh11v43+IiPD2MPm4sp1cJKFrhZHhfdLvT+WK7TtQSZWPixyy5QALZk
0IMlVI3wkLsOPXq/NlycxtXD2trbi3HhMtDO2jSyq4uQg4wHOe6EnGjV/nZt
SqL1U8ym8ZzpvaEY4HPXp4nPj5sh9T7izuaARa6G06x63lLIHR/pOihLx+VM
vEiL/rrB5dAEw2mnb1TfYOGntH1WvGtVURHFDPEeuGkfI+AS+bGuWXBJ/DKW
JU6bNJNKSmqrrsRHxnG0QA1AC9fTB+a3ODkk9zIkpFdt3V2IrCJJttZ767Jq
JmE8Bi01n6Qmmkg4663jvHvpnh5YjBLWQnRjwb/ZWWchMAYDyDHdijbZq+cC
fHElIQri7kIsL9jsW5Tl8AnNr9E7L3zVcDmVpkm+cBFvrYxcsPqmWPuXN/bS
LNxw4aoNrfjgXcoLr/TKw7z6SsJWvs/0g82ZLx+OF1WkmhQ7qbERMRYBr4Pk
BEHUwzFoeY4iJNZ5HC5EfFxiV8gUoSKxljd9jQLJx2uTnfa3xsuDSQHxplXq
xpNUlTxml6RzDYCUSJVQHtxma7Vs0lOpXY1zUmN6svI7sqV4rPy92EgforRe
Z+xxJDxk9/OBVrhegwUSC5Wm2oBjL82CXGsIxQPSzJKf8b54PEohj88v3bVm
hiPfZ+W5b2qeFWYU4e2qgmW7XdpVipkr0bpObbUieUU++Vic9F4Vjy9K0M/y
deGzmidGlsZHacs+Ciw0qsBtzWTZkO73XnLtveEg4Ur5WkmpSTFrLcUhXILY
dlZEcsR8+QpiFDK9fv8u4vmcBZZLSKNMl3wrsHiCAtpLA3AnXp91GFzsjCVo
3OFiRIsc6YNFCWDBjDSXa8pqyAOmbyO5v6fnsiZ/UQUz45NyVVbM6SVQKWFb
nJUWipelba4EFB3tKzzohVz4GEvt4m7EI6hVMjHtpSqwUfqbBjGvlQoVpa0L
FsT5/Bp4wegEplgL9XYzbquRZopK89SahtVbqCB3Dk70GwPadshOecaIruTg
ZKDUvv2FRohtwVlgrNXYAoas9bttZkBFUfGrF2+xGnIjj2KKPL9siUJKK8eq
jM2VJG5ylnZlnJ94TJsG76r67Yt3jsgDc142dSOm8q6eled6H6/MntCMW463
9O7uRCDyPYteSbD82MdqJTl7dsuoePpkqB7IxWlsOsi87R/ElW1iI6CWnJYS
TEUt46KHbWUtCnYHtd0aHnebdTERvHaNpU6QVfIuBtWSx4Ni85ezmGaxKvdK
bZQgesANU0TIvb2TgrcvpId8Usj2J/8bjoxeDq6VqJNL9sE57QH01qdLm6Q2
kUsU9Cro2fG2GH9umMGVwZZMEmL0UablhBy8WAg6qzv6Aj2uVvCZ3RuQKqcH
/AQbDlHJfVES1+pZEPPl5Cu18C0BRddIDQs65+nN4GS7UYohuKUBimHXsll7
CZtFuwTcridlKK1fWZEvIXsH6Cirv1UdCXrcJC0oDW+hKaf3w+Y3p2XBpM/H
HvbBdkfNiemiwJAoGu6uqrSJB7YTxmFMNyvcoeTDvoYClS8+sUb4O1/jRLY5
frvS/T39C99TpH7g01+BxU9++juw4DnsuzmyyYuk9ZJtsL4Z5d+lanKGKzzb
pswQdxfYYYlPutDDn99eGG/lMCXlw57FCzDo8oVjEzsIKZqNIWtLXoRQ4p0p
J3veyd3vjGxKqUi2z4lg/uV3jFHMybaZhmBZ8Hu2igP5BXwBYLq89vMLn5xI
VDFGdJEWXvBL+M4V/+n1W2As32dDkXHWPTIeQodUPD5/QRwijHhlGkWdQfzP
5EYwfhyVoTLIThv6jQ5KF+DhYrokA+Y5mLBHQUBguglDaMXJBLcQaJGvkyAr
1lnjkUTYadp8eKBn1jyU+CfZw099hZsCo5ewRxb4dGHHl3CnSnxgebFt0qQR
QTiJiRviGFRI8Sjj9TnzmZpU7IYRLaGzb336iS15Ms4T1roba+7a3uHrEWmb
EV1z1uCc24Q7GFprRc6a4y9RqnYBPaFpLfHRpSnKt6ht2haOc33h8rlIU0a4
yAuaN114r1AiXkUAg0BIkf6SgSaOrbjMa8N1m0dFFMZXShhj3AKFsFwh4rX/
lMlOq0vQ6+BT3JzOYSzIli984BKKYkPPAXpKqQq+GSPsxlp4y2Tzj/LdebT2
QXmawELmODBXpbHWmM5ztBsGdaiiQ/8WfXoTRsLzwinLcqfXfT/0zzfIJJEz
2vHcpQVVvluuz/qBZI+K5gZ11h2+5cjSZ+gAihevyegkEgfX8Xu77rXwRRpo
BMzhFA/RnephmxiFlfupK3aKRrbT3ZZvqWAtIv8uB/Fffk0k6gNpK3OX9anv
isR3T8UvweEvg+DaXPA7yGX434K7S/SDyaaIYgzm+T7/XZPkQqVkLfYbaZVU
FBAHQ3ZPySf2xMmePC8pumj8TxRiB3QNXLeh4675V/TmjgKkNwwJSJ/YG/O/
b9zbdsCL98Vh4X8ZScRvVtIPTlIjPfmtGOhZ/wu55YX/RzXgYpnW/0jjtXWx
QPzUhTv3As6BL5x5VVcEGn4hQS38+yPIg45M4N0Nh8Qv9h0SOjTJn0eKLw40
wMuCImf3fkOxSPFHRY+MdU3G/G+hAcHcY5J1jfae/2iQd1r4/0modU2r+KXS
8fyP7QfRuL8R4O7Cyf9cFLEJEGH6lk7imr+hQtWLqRUn5JNd5bZy/w/wHLO+
wXcAAA==
<section anchor="iab-members-at-the-time-of-approval" numbered="false">
<name>IAB Members at the Time of Approval</name>
<t>Internet Architecture Board members at the time this document was
approved for publication were:</t>
<ul empty="true" spacing="compact" bare="false" indent="3">
<li>
<t><contact fullname="Jari Arkko"/></t>
</li>
<li>
<t><contact fullname="Deborah Brungard"/></t>
</li>
<li>
<t><contact fullname="Lars Eggert"/></t>
</li>
<li>
<t><contact fullname="Wes Hardaker"/></t>
</li>
<li>
<t><contact fullname="Cullen Jennings"/></t>
</li>
<li>
<t><contact fullname="Mallory Knodel"/></t>
</li>
<li>
<t><contact fullname="Mirja Kühlewind"/></t>
</li>
<li>
<t><contact fullname="Zhenbin Li"/></t>
</li>
<li>
<t><contact fullname="Tommy Pauly"/></t>
</li>
<li>
<t><contact fullname="David Schinazi"/></t>
</li>
<li>
<t><contact fullname="Russ White"/></t>
</li>
<li>
<t><contact fullname="Qin Wu"/></t>
</li>
<li>
<t><contact fullname="Jiankang Yao"/></t>
</li>
</ul>
</section>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank everyone at the IETF, the IAB, and
our day jobs for interesting thoughts and proposals in this space.
Fragments of this document were also in <xref
target="I-D.per-app-networking-considerations" format="default"/> and
<xref target="I-D.arkko-path-signals-information" format="default"/>.
We would also like to acknowledge that similar thoughts are presented in <
xref
target="I-D.trammell-stackevo-explicit-coop" format="default"/>. Finally,
the authors would like to thank
<contact fullname="Adrian Farrell"/>, <contact fullname="Toerless
Eckert"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Mark
Nottingham"/>, <contact fullname="Luis M. Contreras"/>, <contact
fullname="Watson Ladd"/>, <contact fullname="Vittorio Bertola"/>,
<contact fullname="Andrew Campling"/>, <contact fullname="Eliot Lear"/>,
<contact fullname="Spencer Dawkins"/>, <contact fullname="Christian
Huitema"/>, <contact fullname="David Schinazi"/>, <contact
fullname="Cullen Jennings"/>, <contact fullname="Mallory Knodel"/>,
<contact fullname="Zhenbin Li"/>, <contact fullname="Chris Box"/>, and
<contact fullname="Jeffrey Haas"/> for useful feedback on this topic and
document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 62 change blocks. 
1336 lines changed or deleted 837 lines changed or added

This html diff was produced by rfcdiff 1.48.