draft-ietf-tsvwg-transport-encrypt-14.txt   draft-ietf-tsvwg-transport-encrypt-15.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: October 5, 2020 University of Glasgow Expires: November 2, 2020 University of Glasgow
April 03, 2020 May 01, 2020
Considerations around Transport Header Confidentiality, Network Considerations around Transport Header Confidentiality, Network
Operations, and the Evolution of Internet Transport Protocols Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-14 draft-ietf-tsvwg-transport-encrypt-15
Abstract Abstract
To protect user data and privacy, Internet transport protocols have To protect user data and privacy, Internet transport protocols have
supported payload encryption and authentication for some time. Such supported payload encryption and authentication for some time. Such
encryption and authentication is now also starting to be applied to encryption and authentication is now also starting to be applied to
the transport protocol headers. This helps avoid transport protocol the transport protocol headers. This helps avoid transport protocol
ossification by middleboxes, while also protecting metadata about the ossification by middleboxes, while also protecting metadata about the
communication. Current operational practice in some networks inspect communication. Current operational practice in some networks inspect
transport header information within the network, but this is no transport header information within the network, but this is no
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2020. This Internet-Draft will expire on November 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 5 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4
2.1. Use of Transport Header Information in the Network . . . 6 2.1. Use of Transport Header Information in the Network . . . 6
2.2. Authentication of Transport Header Information . . . . . 8 2.2. Authentication of Transport Header Information . . . . . 8
2.3. Perspectives on Observable Transport Header Fields . . . 8 2.3. Perspectives on Observable Transport Header Fields . . . 8
3. Current uses of Transport Headers within the Network . . . . 12 3. Current uses of Transport Headers within the Network . . . . 12
3.1. Observing Transport Information in the Network . . . . . 12 3.1. Observing Transport Information in the Network . . . . . 12
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 20 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 20
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 23 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 24
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 25 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 25
4. Encryption and Authentication of Transport Headers . . . . . 25 4. Encryption and Authentication of Transport Headers . . . . . 25
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Approaches to Transport Header Protection . . . . . . . . 26 4.2. Approaches to Transport Header Protection . . . . . . . . 26
5. Addition of Transport OAM Information to Network-Layer 5. Addition of Transport OAM Information to Network-Layer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29
6. Intentionally Exposing Transport Information to the Network . 29 6. Intentionally Exposing Transport Information to the Network . 29
6.1. Exposing Transport Information in Extension Headers . . . 29 6.1. Exposing Transport Information in Extension Headers . . . 30
6.2. Common Exposed Transport Information . . . . . . . . . . 30 6.2. Common Exposed Transport Information . . . . . . . . . . 30
6.3. Considerations for Exposing Transport Information . . . . 30 6.3. Considerations for Exposing Transport Information . . . . 30
7. Implications of Protecting the Transport Headers . . . . . . 31 7. Implications of Protecting the Transport Headers . . . . . . 31
7.1. Independent Measurement . . . . . . . . . . . . . . . . . 31 7.1. Independent Measurement . . . . . . . . . . . . . . . . . 31
7.2. Characterising "Unknown" Network Traffic . . . . . . . . 33 7.2. Characterising "Unknown" Network Traffic . . . . . . . . 33
7.3. Accountability and Internet Transport Protocols . . . . . 33 7.3. Accountability and Internet Transport Protocols . . . . . 34
7.4. Impact on Network Operations . . . . . . . . . . . . . . 34 7.4. Impact on Network Operations . . . . . . . . . . . . . . 34
7.5. Impact on Research, Development and Deployment . . . . . 35 7.5. Impact on Research, Development and Deployment . . . . . 35
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
12. Informative References . . . . . . . . . . . . . . . . . . . 41 12. Informative References . . . . . . . . . . . . . . . . . . . 42
Appendix A. Revision information . . . . . . . . . . . . . . . . 49 Appendix A. Revision information . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Transport protocols have supported end-to-end encryption of payload Transport protocols have supported end-to-end encryption of payload
data for many years. Examples include Transport Layer Security (TLS) data for many years. Examples include Transport Layer Security (TLS)
over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure
RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic RTP [RFC3711], and TCPcrypt [RFC8548]. Some of these also provide
encryption of the TCP transport payload. Some of these also provide integrity protection of all, or part, of the transport header.
integrity protection of all or part of the transport header.
This end-to-end transport payload encryption brings many benefits in This end-to-end transport payload encryption brings many benefits in
terms of providing confidentiality and protecting user privacy. The terms of providing confidentiality and protecting user privacy. The
benefits have been widely discussed, for example in [RFC7624]. This benefits have been widely discussed, for example in [RFC7624]. This
document supports and encourages increased use of end-to-end payload document supports and encourages increased use of end-to-end payload
encryption in transport protocols. The implications of protecting encryption in transport protocols. The implications of protecting
the transport payload data are therefore not further discussed in the transport payload data are therefore not further discussed in
this document. this document.
A further level of protection can be achieved by encrypting the A further level of protection can be achieved by encrypting the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
network devices, reducing the risk of protocol ossification. It also network devices, reducing the risk of protocol ossification. It also
reduces the amount of metadata about the progress of the transport reduces the amount of metadata about the progress of the transport
connection that is visible to the network [RFC8558]. In this connection that is visible to the network [RFC8558]. In this
document, the term "transport header information" is used to describe document, the term "transport header information" is used to describe
transport layer information concerning the operation of the transport transport layer information concerning the operation of the transport
protocol (i.e., information used by the transport protocol that might protocol (i.e., information used by the transport protocol that might
be carried in a protocol header). This does not refer to transport be carried in a protocol header). This does not refer to transport
payload data (i.e., information transferred by the transport payload data (i.e., information transferred by the transport
service), which itself could be encrypted. service), which itself could be encrypted.
There is also, however, some impact, in that the widespread use of
transport header encryption requires changes to network operations
and other practises. Operators could choose to do nothing special
with encrypted traffic. In some cases, encryption could drive
changes to the design of network measurement for research,
operational, and standardisation purposes.
The direction in which the use of transport header encryption evolves The direction in which the use of transport header encryption evolves
could have significant implications on the way the Internet could have significant implications on the way the Internet
architecture develops, and therefore needs to be considered as a part architecture develops, and therefore needs to be considered as a part
of protocol design and evolution. This include considering whether of protocol design and evolution. This includes considering whether
the endpoints permit (or are able to permit) network devices to the endpoints permit (or are able to permit) network devices to
observe a specific information by explicitly exposing a transport observe specific information by explicitly exposing a transport
header field (or a field derived from transport header information) header field (or a field derived from transport header information)
to the network; whether it is intended that a network device can to the network; whether it is intended that a network device can
modify the field, whether the devices are able to modify that field; modify a transport header field; and whether any modification along
and whether any modification along the network path can be detected the network path can be detected by the receiving endpoint. This can
by the receiving endpoint. require changes to network operations and other practises and could
drive changes to the design of network measurement for research,
operational, and standardisation purposes.
As discussed in [RFC7258], the IETF has concluded that Pervasive As discussed in [RFC7258], the IETF has concluded that Pervasive
Monitoring (PM) is a technical attack that needs to be mitigated in Monitoring (PM) is a technical attack that needs to be mitigated in
the design of IETF protocols, but RFC7528 also notes that "Making the design of IETF protocols, but RFC7528 also notes that "Making
networks unmanageable to mitigate PM is not an acceptable outcome, networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here. An but ignoring PM would go against the consensus documented here. An
appropriate balance will emerge over time as real instances of this appropriate balance will emerge over time as real instances of this
tension are considered". In support of achieving that balance, this tension are considered". In support of achieving that balance, this
document discusses design and deployment considerations for use of document discusses design and deployment considerations for use of
transport header encryption to protect against pervasive monitoring. transport header encryption to protect against pervasive monitoring.
skipping to change at page 5, line 51 skipping to change at page 5, line 42
majority of their transport headers to prevent observation and majority of their transport headers to prevent observation and
protect against modification by the network, and to make explicit protect against modification by the network, and to make explicit
their invariants and what is intended to be visible to the network. their invariants and what is intended to be visible to the network.
Transport header encryption is expected to form a core part of future Transport header encryption is expected to form a core part of future
transport protocol designs. It can help to protect against pervasive transport protocol designs. It can help to protect against pervasive
monitoring, improve privacy, and reduce protocol ossification. monitoring, improve privacy, and reduce protocol ossification.
Transport protocols that use header encryption with secure key Transport protocols that use header encryption with secure key
distribution can provide confidentiality and protection for some, or distribution can provide confidentiality and protection for some, or
all, of the transport header, controlling what is visible to, and can all, of the transport header, controlling what is visible to, and can
be modified by, the network. be modified by the network.
The increased use of transport header encryption has benefits, but The increased use of transport header encryption has benefits, but
also has implications for the broader ecosystem. The transport also has implications for the broader ecosystem. The transport
community has, to date, relied heavily on measurements and insights community has, to date, relied on measurements and insights from the
from the network operations community to understand protocol network operations community to understand protocol behaviour, and to
behaviour, and to inform the selection of appropriate mechanisms to inform the selection of appropriate mechanisms to ensure a safe,
ensure a safe, reliable, and robust Internet. In turn, network reliable, and robust Internet. In turn, network operators and access
operators and access providers have relied upon being able to observe providers have relied upon being able to observe traffic patterns and
traffic patterns and requirements, both in aggregate and at the flow requirements, both in aggregate and at the flow level, to help
level, to help understand and optimise the behaviour of their understand and optimise the behaviour of their networks.
networks. Transport header encryption can be used to intentionally
limit the information available to network observers. The widespread Transport header encryption can be used to intentionally limit the
use of transport header encryption would therefore limit such information available to network observers. The widespread use would
observations, unless transport protocols are modified to selectively therefore limit such observations, unless transport protocols are
expose transport header information outside of the encrypted modified to selectively expose transport header information outside
transport header. It is important to understand how transport header of the encrypted transport header. It is important to understand how
information is used by networks, to allow future protocol designs to transport header information is used by networks, to allow future
make an informed choice on what, if any, transport layer information protocol designs to make an informed choice on what, if any,
to expose to the network. transport layer information to expose to the network.
2.1. Use of Transport Header Information in the Network 2.1. Use of Transport Header Information in the Network
In-network measurement of transport flow characteristics can be used In-network measurement of transport flow characteristics can be used
to enhance performance, control cost and improve service reliability. to enhance performance, control cost and improve service reliability.
To support network operations and enhance performance, some operators To support network operations and enhance performance, some operators
have deployed functionality that utilises on-path observations of the have deployed functionality that utilises on-path observations of the
transport headers of packets passing through their network. transport headers of packets passing through their network ([RFC8517]
gives an operator perspective on such use).
When network devices rely on the presence of a header field or the When network devices rely on the presence of a header field or the
semantics of specific header information, this can lead to semantics of specific header information, this can lead to
ossification where an endpoint has to supply a specific header to ossification where an endpoint has to supply a specific header to
receive the network service that it desires. receive the network service that it desires.
In some cases, network-layer use of transport layer information can In some cases, network-layer use of transport layer information can
be benign or advantageous to the protocol (e.g., recognising the be benign or advantageous to the protocol (e.g., recognising the
start of a TCP connection, providing header compression for a Secure start of a TCP connection, providing header compression for a Secure
RTP flow, or explicitly using exposed protocol information to provide RTP (SRTP) flow [RFC3711], or explicitly using exposed protocol
consistent decisions by on-path devices). Header compression (e.g., information to provide consistent decisions by on-path devices).
[RFC5795]) depends understanding of transport header and the way Header compression (e.g., [RFC5795]) depends on understanding of
fields change packet-by-packet; as also do techniques to improve TCP transport header and the way fields change packet-by-packet; as also
performance by transparent modification of acknowledgement traffic do techniques to improve TCP performance by transparent modification
[RFC3449]. Introducing a new transport protocol or changes to of acknowledgement traffic [RFC3449]. Introducing a new transport
existing transport header information prevent these methods being protocol or changes to existing transport header information prevent
used or require the network devices to be updated. these methods being used or require the network devices to be
updated.
However, in other cases, ossification can have unwanted outcomes. However, in other cases, ossification can have unwanted outcomes.
Ossification can frustrate the evolution of a transport protocol. A Ossification can frustrate the evolution of a transport protocol. A
mechanism implemented in a network device, such as a firewall, that mechanism implemented in a network device, such as a firewall, that
requires a header field to have only a specific known set of values requires a header field to have only a specific known set of values
can prevent the device from forwarding packets using a different can prevent the device from forwarding packets using a different
version of the protocol that introduces a feature that changes to a version of the protocol that introduces a feature that changes to a
new value for the observed field. new value for the observed field.
An example of this type ossification was observed in the development An example of this type ossification was observed in the development
skipping to change at page 7, line 12 skipping to change at page 7, line 4
mechanism implemented in a network device, such as a firewall, that mechanism implemented in a network device, such as a firewall, that
requires a header field to have only a specific known set of values requires a header field to have only a specific known set of values
can prevent the device from forwarding packets using a different can prevent the device from forwarding packets using a different
version of the protocol that introduces a feature that changes to a version of the protocol that introduces a feature that changes to a
new value for the observed field. new value for the observed field.
An example of this type ossification was observed in the development An example of this type ossification was observed in the development
of Transport Layer Security (TLS) 1.3 [RFC8446], where the design of Transport Layer Security (TLS) 1.3 [RFC8446], where the design
needed to function in the presence of deployed middleboxes that needed to function in the presence of deployed middleboxes that
relied on the presence of certain header fields exposed in TLS 1.2. relied on the presence of certain header fields exposed in TLS 1.2.
The design of MPTCP also had to be revised to account for middleboxes The design of MPTCP also had to be revised to account for middleboxes
(known as "TCP Normalizers") that monitor the evolution of the window (known as "TCP Normalizers") that monitor the evolution of the window
advertised in the TCP header and then reset connections when the advertised in the TCP header and then reset connections when the
window did not grow as expected. Similarly, issues have been window did not grow as expected. Similarly, issues have been
reported using TCP. For example, TCP Fast Open can experience reported using TCP. For example, TCP Fast Open [RFC7413] can
middleboxes that modify the transport header of packets by removing experience middleboxes that modify the transport header of packets by
"unknown" TCP options, segments with unrecognised TCP options can be removing "unknown" TCP options, segments with unrecognised TCP
dropped, segments that contain data and set the SYN bit can be options can be dropped, segments that contain data and set the SYN
dropped, or middleboxes that disrupt connections that send data bit can be dropped, or middleboxes that disrupt connections that send
before completion of the three-way handshake. data before completion of the three-way handshake.
Other examples of ossification have included middleboxes that modify Other examples of ossification have included middleboxes that modify
transport headers by rewriting TCP sequence and acknowledgement transport headers by rewriting TCP sequence and acknowledgement
numbers, but are unaware of the (newer) TCP selective acknowledgement numbers, but are unaware of the (newer) TCP selective acknowledgement
(SACK) Option and therefore fail to correctly rewrite the selective (SACK) option and therefore fail to correctly rewrite the SACK
acknowledgement header information to match the changes that were information to match the changes that were made to the fixed TCP
made to the fixed TCP header, preventing SACK from operating header, preventing SACK from operating correctly.
correctly.
In all these cases, middleboxes with a hard-coded, but incomplete, In all these cases, middleboxes with a hard-coded, but incomplete,
understanding of transport behaviour, interacted poorly with understanding of transport behaviour, interacted poorly with
transport protocols after the transport behaviour was changed. transport protocols after the transport behaviour was changed. In
some case, the middleboxes modified or replaced information in the
transport protocol header.
In contrast, transport header encryption prevents an on-path device Transport header encryption prevents an on-path device from observing
from observing the transport headers, and therefore stops mechanisms the transport headers, and therefore stops mechanisms being built
being built that directly rely on or infer semantics of the transport that directly rely on or infer semantics of the transport header
header information. Encryption is normally combined with information. Encryption is normally combined with authentication of
authentication of the protected information. RFC 8546 summarises the protected information. RFC 8546 summarises this approach,
this approach, stating that it is "The wire image, not the protocol's stating that it is "The wire image, not the protocol's specification,
specification, determines how third parties on the network paths determines how third parties on the network paths among protocol
among protocol participants will interact with that protocol" participants will interact with that protocol" [RFC8546], and it can
[RFC8546], and it can be expected that header information that is not be expected that header information that is not encrypted will become
encrypted will become ossified. ossified.
While encryption can reduce ossification of the transport protocol, While encryption can reduce ossification of the transport protocol,
it does not itself prevent ossification of the network service. it does not itself prevent ossification of the network service.
People seeking to understand network traffic could still come to rely People seeking to understand network traffic could still come to rely
on pattern inferences and other heuristics or machine learning to on pattern inferences and other heuristics or machine learning to
derive measurement data and as the basis for network forwarding derive measurement data and as the basis for network forwarding
decisions [RFC8546]. This can also create dependencies on the decisions [RFC8546]. This can also create dependencies on the
transport protocol, or the patterns of traffic it can generate, also transport protocol, or the patterns of traffic it can generate, also
in time resulting in ossification of the service. in time resulting in ossification of the service.
2.2. Authentication of Transport Header Information 2.2. Authentication of Transport Header Information
The designers of a transport protocol decide whether to encrypt all, The designers of a transport protocol decide whether to encrypt all,
or a part of, the transport layer information. Section 4 of RFC8558 or a part of, the transport layer information. Section 4 of RFC8558
states: "Anything exposed to the path should be done with the intent states: "Anything exposed to the path should be done with the intent
that it be used by the network elements on the path" [RFC8558]. that it be used by the network elements on the path" [RFC8558].
Protocol designs can decide not to encrypt certain transport header Protocol designs can decide not to encrypt certain transport header
fields, making those fields observable in the network, or can choose fields, making those fields observable in the network, or can define
to expose new fields designed to explicitly expose observable new fields designed to explicitly expose observable transport layer
transport layer information to the network. Where exposed fields are information to the network. Where exposed fields are intended to be
intended to be immutable (i.e., can be observed, but not modified by immutable (i.e., can be observed, but not modified by a network
a network device), the endpoints are encouraged to use authentication device), the endpoints are encouraged to use authentication to
to provide a cryptographic integrity check that includes these provide a cryptographic integrity check that can detect if these
immutable fields to detect any manipulation by network devices. immutable fields have been modified by network devices.
Authentication can also help to prevent attacks that rely on sending
packets that fake exposed control signals in transport headers (e.g.,
TCP RST spoofing).
Making part of a transport header observable, or exposing new header Making part of a transport header observable, or exposing new header
fields, can lead to ossification of that part of a header as network fields, can lead to ossification of that part of a header as network
devices come to rely on observations of the exposed fields. A devices come to rely on observations of the exposed fields. A
protocol design that provides an observable field might want to protocol design that provides an observable field might want to
restrict the choice of usable values in a field by intentionally restrict the choice of usable values in a field by intentionally
varying the format and/or value of the field to reduce the chance of varying the format and/or value of the field to reduce the chance of
ossification (see Section 4). ossification (see Section 4).
2.3. Perspectives on Observable Transport Header Fields 2.3. Perspectives on Observable Transport Header Fields
Transport headers fields have been observed within the network for a Transport header fields have been observed within the network for a
variety of purposes. Some of these are related to network management variety of purposes. Some purposes are related to network management
and operations. The lists below, and in the following section, seek and operations. Use cases where the network devices intentionally
to identify some of these uses and the implications of the increased modify mutable transport layer information are out of scope and are
use of transport header encryption. This analysis does not judge not described further in this document. More information may be
whether specific practises are necessary, or endorse the use of any found in other RFCs (e.g., [RFC3449], [RFC3135], [RFC8404],
specific approach. [RFC8462]), and [RFC8517].
The list below provides an overview with different uses of exposed
immutable information.
Network Operations: A transport protocol with observable header Network Operations: A transport protocol with observable header
information can enable explicit measurement and information can enable explicit measurement and
analysis of protocol performance, network analysis of protocol performance, network
anomalies, and failure pathologies at any point anomalies, and failure pathologies at any point
along the Internet path. In many cases, it is along the Internet path. In many cases, it is
important to relate observations to specific important to relate observations to specific
equipment/configurations, to a specific network equipment/configurations, to a specific network
segment, or sometimes to a specific protocol or segment, or sometimes to a specific protocol or
application. application.
skipping to change at page 10, line 33 skipping to change at page 10, line 37
usage, decoupled from the internal design of the usage, decoupled from the internal design of the
protocol state machine. This could avoid protocol state machine. This could avoid
ossifying the protocol around the design of a ossifying the protocol around the design of a
specific protocol mechanism. specific protocol mechanism.
See also Section 3.3 and Section 5. See also Section 3.3 and Section 5.
Network Protection: Observable transport headers currently provide Network Protection: Observable transport headers currently provide
information that is useful input to classify and information that is useful input to classify and
detect anomalous events, such as changes in detect anomalous events, such as changes in
application behaviour or distributed denial of application behaviour or distributed DoS attacks.
service attacks. Operators often seek to Operators often seek to uniquely disambiguate
uniquely disambiguate unwanted traffic. unwanted traffic.
Where flows cannot be disambiguated based on Where flows cannot be disambiguated based on
transport header information, this could result transport header information, this could result
in less-efficient identification of unwanted in less-efficient identification of unwanted
traffic, the introduction of rate limits for traffic, the introduction of rate limits for
uncharacterised traffic, or the use of heuristics uncharacterised traffic, or the use of heuristics
to identify anomalous flows. to identify anomalous flows.
See also Section 7.2 and Section 7.3. See also Section 7.2 and Section 7.3.
skipping to change at page 11, line 45 skipping to change at page 11, line 48
assurance to those operating networks, often assurance to those operating networks, often
avoiding deployment of complex techniques that avoiding deployment of complex techniques that
routinely monitor and manage Internet traffic routinely monitor and manage Internet traffic
flows (e.g., avoiding the capital and operational flows (e.g., avoiding the capital and operational
costs of deploying flow rate-limiting and network costs of deploying flow rate-limiting and network
circuit-breaker methods [RFC8084]). circuit-breaker methods [RFC8084]).
See also Section 5 and Section 7.1 to See also Section 5 and Section 7.1 to
Section 7.4. Section 7.4.
Note, again, that this is a list of example uses that have been made This analysis does not judge whether specific practises are
of transport header information. It is not an endorsement of any necessary. It is not an endorsement of any particular practice.
particular practice.
3. Current uses of Transport Headers within the Network 3. Current uses of Transport Headers within the Network
In response to pervasive monitoring [RFC7624] revelations and the In response to pervasive monitoring [RFC7624] revelations and the
IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258],
efforts are underway to increase encryption of Internet traffic. efforts are underway to increase encryption of Internet traffic.
Applying confidentiality to transport header fields affects how Applying confidentiality to transport header fields affects how
protocol information is used [RFC8404], requiring consideration of protocol information is used [RFC8404], requiring consideration of
the trade-offs discussed in Section 2.3. the trade-offs discussed in Section 2.3.
There are architectural challenges and considerations in the way The decision about which transport headers fields are made observable
transport protocols are designed, and the ability to characterise and offers trade-offs around header confidentiality versus header
compare different transport solutions [Measurement]. The decision observability (including non-encrypted, but authenticated, header
about which transport headers fields are made observable offers fields) for network operations and management, and the implications
trade-offs around header confidentiality versus header observability for ossification and user privacy [Measurement]. Different parties
(including non-encrypted but authenticated header fields) for network will view the relative importance of these differently. For some,
operations and management, and the implications for ossification and the benefits of encrypting all transport headers outweigh the impact
user privacy. Different parties will view the relative importance of of doing so; others might analyse the security, privacy and
these differently. For some, the benefits of encrypting all ossification impacts, and arrive at a different trade-off.
transport headers outweigh the impact of doing so; others might
analyse the security, privacy and ossification impacts, and arrive at
a different trade-off.
To understand the implications, it is necessary to understand how This section reviews examples of the observation of transport layer
transport layer headers are currently observed and/or modified by headers within the network. It does not consider intentional
middleboxes within the network. This section therefore reviews
examples of current usage. It does not consider the intentional
modification of transport headers by middleboxes (such as in Network modification of transport headers by middleboxes (such as in Network
Address Translation, NAT, or Firewalls). Common issues concerning IP Address Translation, NAT, or Firewalls). Common issues concerning IP
address sharing are described in [RFC6269]. address sharing are described in [RFC6269].
3.1. Observing Transport Information in the Network 3.1. Observing Transport Information in the Network
In-network observation of transport protocol headers requires In-network observation of transport protocol headers requires
knowledge of the format of the transport header: knowledge of the format of the transport header:
o Flows have to be identified at the level where observation is o Flows have to be identified at the level where observation is
skipping to change at page 13, line 7 skipping to change at page 13, line 7
o Observing transport header information depends on the observer o Observing transport header information depends on the observer
knowing the location and the syntax of the observable transport knowing the location and the syntax of the observable transport
headers. IETF transport protocols can specify this information. headers. IETF transport protocols can specify this information.
The following subsections describe various ways that observable The following subsections describe various ways that observable
transport header information has been utilised. transport header information has been utilised.
3.1.1. Flow Identification Using Transport Layer Headers 3.1.1. Flow Identification Using Transport Layer Headers
Flow/Session identification [RFC8558] is a common function. For Flow/Session identification [RFC8558] is a common function performed,
example, performed by measurement activities, QoS classification, for example, by measurement activities, QoS classifiers, firewalls,
firewalls, Denial of Service, DOS, prevention. and as part of Denial of Service (DoS) prevention.
Observable transport header information, together with information in Observable transport header information, together with information in
the network header, has been used to identify flows and their the network header, has been used to identify flows and their
connection state, together with the set of protocol options being connection state, together with the set of protocol options being
used. Transport protocols, such as TCP and the Stream Control used. Transport protocols, such as TCP and the Stream Control
Transport Protocol (SCTP), specify a standard base header that Transport Protocol (SCTP), specify a standard base header that
includes sequence number information and other data. They also have includes sequence number information and other data. They also have
the possibility to negotiate additional headers at connection setup, the possibility to negotiate additional headers at connection setup,
identified by an option number in the transport header. identified by an option number in the transport header.
In some uses, a low-numbered (well-known) transport port number can In some uses, an assigned transport port (e.g., 0..49151) can
identify the protocol. However, port information alone is not identify the protocol [RFC7605]. However, port information alone is
sufficient to guarantee identification. Applications can use not sufficient to guarantee identification. Applications can use
arbitrary ports, multiple sessions can be multiplexed on a single arbitrary ports and do not need to use assigned port numbers. The
port, and ports can be re-used by subsequent sessions. UDP-based use of an assigned port number is also not limited to the protocol
protocols often do not use well-known port numbers. Some flows can for which the port is intended. Multiple sessions can also be
be identified by observing signalling protocol data (e.g., [RFC3261], multiplexed on a single port, and ports can be re-used by subsequent
[I-D.ietf-rtcweb-overview]) or through the use of magic numbers sessions.
placed in the first byte(s) of the datagram payload [RFC7983].
Some flows can be identified by observing signalling protocol data
(e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of
magic numbers placed in the first byte(s) of the datagram payload
[RFC7983].
When transport header information can not be observed, this removes When transport header information can not be observed, this removes
information that could have been used to classify flows by passive information that could have been used to classify flows by passive
observers along the path. More ambitious ways could be used to observers along the path. More ambitious ways could be used to
collect, estimate, or infer flow information, including heuristics collect, estimate, or infer flow information, including heuristics
based on the analysis of traffic patterns. For example, an operator based on the analysis of traffic patterns. For example, an operator
that cannot access the Session Description Protocol (SDP) session that cannot access the Session Description Protocol (SDP) session
descriptions to classify a flow as audio traffic, might instead use descriptions to classify a flow as audio traffic, might instead use
(possibly less-reliable) heuristics to infer that short UDP packets (possibly less-reliable) heuristics to infer that short UDP packets
with regular spacing carry audio traffic. Operational practises with regular spacing carry audio traffic. Operational practises
skipping to change at page 17, line 33 skipping to change at page 17, line 39
Passive measurements (see Section 3.6 of [RFC7799]) can have Passive measurements (see Section 3.6 of [RFC7799]) can have
advantages in terms of eliminating unproductive test traffic, advantages in terms of eliminating unproductive test traffic,
reducing the influence of test traffic on the overall traffic mix, reducing the influence of test traffic on the overall traffic mix,
and the ability to choose the point of observation (see and the ability to choose the point of observation (see
Section 3.2.1). Measurements can rely on observing packet headers, Section 3.2.1). Measurements can rely on observing packet headers,
which is not possible if those headers are encrypted, but could which is not possible if those headers are encrypted, but could
utilise information about traffic volumes or patterns of interaction utilise information about traffic volumes or patterns of interaction
to deduce metrics. to deduce metrics.
An alternative approach is to use in-network techniques to add and One alternative approach is to use in-network techniques, which does
observe packet headers to facilitate measurements while traffic not require the cooperation of an endpoint (see Section 5).
traverses an operational network. This approach does not require the
cooperation of an endpoint.
3.1.3. Transport use of Network Layer Header Fields 3.1.3. Transport use of Network Layer Header Fields
Information from the transport header is used by a multi-field Information from the transport header is used by a multi-field
classifier as a part of policy framework. Policies are commonly used classifier as a part of policy framework. Policies are commonly used
for management of the QoS or Quality of Experience (QoE) in resource- for management of the QoS or Quality of Experience (QoE) in resource-
constrained networks, and by firewalls to implement access rules (see constrained networks, and by firewalls to implement access rules (see
also Section 2.2.2 of [RFC8404]). Network-layer classification also Section 2.2.2 of [RFC8404]). Network-layer classification
methods that rely on a multi-field classifier (e.g., inferring QoS methods that rely on a multi-field classifier (e.g., inferring QoS
from the 5-tuple or choice of application protocol) are incompatible from the 5-tuple or choice of application protocol) are incompatible
skipping to change at page 18, line 27 skipping to change at page 18, line 29
this could be done: this could be done:
IP Address: Applications normally expose the addresses used by IP Address: Applications normally expose the addresses used by
endpoints, and this is used in the forwarding decisions in network endpoints, and this is used in the forwarding decisions in network
devices. Address and other protocol information can be used by a devices. Address and other protocol information can be used by a
Multi-Field (MF) classifier to determine how traffic is treated Multi-Field (MF) classifier to determine how traffic is treated
[RFC2475], and hence the quality of experience for a flow. [RFC2475], and hence the quality of experience for a flow.
Using the IPv6 Network-Layer Flow Label: A number of Standards Track Using the IPv6 Network-Layer Flow Label: A number of Standards Track
and Best Current Practice RFCs (e.g., [RFC8085], and Best Current Practice RFCs (e.g., [RFC8085],
[RFC6437][RFC6438]) encourage endpoints to set the IPv6 Flow label [RFC6437][RFC6438]) encourage endpoints to set the IPv6 flow label
field of the network-layer header. IPv6 "source nodes SHOULD field of the network-layer header. IPv6 "source nodes SHOULD
assign each unrelated transport connection and application data assign each unrelated transport connection and application data
stream to a new flow" [RFC6437]. A multiplexing transport could stream to a new flow" [RFC6437]. A multiplexing transport could
choose to use multiple Flow labels to allow the network to choose to use multiple flow labels to allow the network to
independently forward sub-flows. RFC6437 provides further independently forward sub-flows. RFC6437 provides further
guidance on choosing a flow label value, stating these "should be guidance on choosing a flow label value, stating these "should be
chosen such that their bits exhibit a high degree of variability", chosen such that their bits exhibit a high degree of variability",
and chosen so that "third parties should be unlikely to be able to and chosen so that "third parties should be unlikely to be able to
guess the next value that a source of flow labels will choose". guess the next value that a source of flow labels will choose".
Once set, a flow label can provide information that can help Once set, a flow label can provide information that can help
inform network-layer queueing and forwarding [RFC6438], for inform network-layer queueing and forwarding [RFC6438], for
example with Equal Cost Multi-Path routing and Link Aggregation example with Equal Cost Multi-Path routing and Link Aggregation
[RFC6294]. Considerations when using IPsec are further described [RFC6294]. Considerations when using IPsec are further described
in [RFC6438]. in [RFC6438].
The choice of how to assign a Flow Label needs to avoid The choice of how to assign a flow label needs to avoid
introducing linkability that a network device could observe. introducing linkability that a network device could observe.
Inappropriate use by the transport can have privacy implications Inappropriate use by the transport can have privacy implications
(e.g., assigning the same label to two independent flows that (e.g., assigning the same label to two independent flows that
ought not to be classified the same). ought not to be classified the same).
Using the Network-Layer Differentiated Services Code Point: Using the Network-Layer Differentiated Services Code Point:
Applications can expose their delivery expectations to the network Applications can expose their delivery expectations to the network
by setting the Differentiated Services Code Point (DSCP) field of by setting the Differentiated Services Code Point (DSCP) field of
IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications
identify different forwarding treatments for individual sub-flows identify different forwarding treatments for individual sub-flows
skipping to change at page 20, line 17 skipping to change at page 20, line 19
are required to ignore IPv4 options that they does not recognise. are required to ignore IPv4 options that they does not recognise.
Many current paths include network devices that forward packets Many current paths include network devices that forward packets
that carry options on a slower processing path. Some network that carry options on a slower processing path. Some network
devices (e.g., firewalls) can be (and are) configured to drop devices (e.g., firewalls) can be (and are) configured to drop
these packets [RFC7126]. RFC 7126 provides Best Current Practice these packets [RFC7126]. RFC 7126 provides Best Current Practice
guidance on how operators should treat IPv4 packets that specify guidance on how operators should treat IPv4 packets that specify
options. options.
IPv6 can encode optional network-layer information in separate IPv6 can encode optional network-layer information in separate
headers that may be placed between the IPv6 header and the upper- headers that may be placed between the IPv6 header and the upper-
layer header [RFC8200]. The Hop-by-Hop Options header, when layer header [RFC8200]. The Hop-by-Hop options header, when
present, immediately follows the IPv6 header. IPv6 permits this present, immediately follows the IPv6 header. IPv6 permits this
header to be examined by any node along the path. While [RFC7872] header to be examined by any node along the path. While [RFC7872]
required all nodes to examine and process the Hop-by-Hop Options required all nodes to examine and process the Hop-by-Hop options
header, it is now expected [RFC8200] that nodes along a path only header, it is now expected [RFC8200] that nodes along a path only
examine and process the Hop-by-Hop Options header if explicitly examine and process the Hop-by-Hop options header if explicitly
configured to do so. configured to do so.
When transport headers cannot be observed, operators are unable to When transport headers cannot be observed, operators are unable to
use this information directly. Careful use of the network layer use this information directly. Careful use of the network layer
features can help provide similar information in the case where the features can help provide similar information in the case where the
network is unable to inspect transport protocol headers. Section 5 network is unable to inspect transport protocol headers. Section 6
describes use of network extension headers. describes use of network extension headers.
3.2. Transport Measurement 3.2. Transport Measurement
The common language between network operators and application/content The common language between network operators and application/content
providers/users is packet transfer performance at a layer that all providers/users is packet transfer performance at a layer that all
can view and analyse. For most packets, this has been the transport can view and analyse. For most packets, this has been the transport
layer, until the emergence of transport protocols performing header layer, until the emergence of transport protocols performing header
encryption, with the obvious exception of VPNs and IPsec. encryption, with the obvious exception of VPNs and IPsec.
skipping to change at page 21, line 10 skipping to change at page 21, line 12
network performance or understand a pathology. Collecting and network performance or understand a pathology. Collecting and
coordinating such metadata is more difficult when the observation coordinating such metadata is more difficult when the observation
point is at a different location to the bottleneck/device under point is at a different location to the bottleneck/device under
evaluation [RFC7799]. evaluation [RFC7799].
Packet sampling techniques are used to scale the processing involved Packet sampling techniques are used to scale the processing involved
in observing packets on high rate links. This exports only the in observing packets on high rate links. This exports only the
packet header information of (randomly) selected packets. The packet header information of (randomly) selected packets. The
utility of these measurements depends on the type of bearer and utility of these measurements depends on the type of bearer and
number of mechanisms used by network devices. Simple routers are number of mechanisms used by network devices. Simple routers are
relatively easy to manage, a device with more complexity demands relatively easy to manage, but a device with more complexity demands
understanding of the choice of many system parameters. This level of understanding of the choice of many system parameters. This level of
complexity exists when several network methods are combined. complexity exists when several network methods are combined.
This section discusses topics concerning observation of transport This section discusses topics concerning observation of transport
flows, with a focus on transport measurement. flows, with a focus on transport measurement.
3.2.1. Point of Observation 3.2.1. Point of Observation
On-path measurements are particularly useful for locating the source On-path measurements are particularly useful for locating the source
of problems, or to assess the performance of a network segment or a of problems, or to assess the performance of a network segment or a
skipping to change at page 23, line 51 skipping to change at page 24, line 11
Section 3.1.2). The Secure RTP and RTCP extensions [RFC3711] were Section 3.1.2). The Secure RTP and RTCP extensions [RFC3711] were
explicitly designed to expose some header information to enable explicitly designed to expose some header information to enable
such observation, while protecting the payload data. such observation, while protecting the payload data.
3.3. Use for Network Diagnostics and Troubleshooting 3.3. Use for Network Diagnostics and Troubleshooting
Transport header information can be utilised for a variety of Transport header information can be utilised for a variety of
operational tasks [RFC8404]: to diagnose network problems, assess operational tasks [RFC8404]: to diagnose network problems, assess
network provider performance, evaluate equipment or protocol network provider performance, evaluate equipment or protocol
performance, capacity planning, management of security threats performance, capacity planning, management of security threats
(including denial of service), and responding to user performance (including DoS), and responding to user performance questions.
questions. Section 3.1.2 and Section 5 of [RFC8404] provide further Section 3.1.2 and Section 5 of [RFC8404] provide further examples.
examples.
Operators can monitor the health of a portion of the Internet, to Operators can monitor the health of a portion of the Internet, to
provide early warning and trigger action. Traffic and performance provide early warning and trigger action. Traffic and performance
measurements can assist in setting buffer sizes, debugging and measurements can assist in setting buffer sizes, debugging and
diagnosing the root causes of faults that concern a particular user's diagnosing the root causes of faults that concern a particular user's
traffic. They can also be used to support post-mortem investigation traffic. They can also be used to support post-mortem investigation
after an anomaly to determine the root cause of a problem. after an anomaly to determine the root cause of a problem. In other
cases, measurement involves dissecting network traffic flows.
In other cases, measurement involves dissecting network traffic Observed transport header information can help identify whether link/
flows. Observed transport header information can help identify network tuning is effective and alert to potential problems that can
whether link/network tuning is effective and alert to potential be hard to derive from link or device measurements alone.
problems that can be hard to derive from link or device measurements
alone.
An alternative could rely on access to endpoint diagnostic tools or An alternative could rely on access to endpoint diagnostic tools or
user involvement in diagnosing and troubleshooting unusual use cases user involvement in diagnosing and troubleshooting unusual use cases
or to troubleshoot non-trivial problems. or to troubleshoot non-trivial problems.
Another approach is to use traffic pattern analysis. Such tools can Another approach is to use traffic pattern analysis. Such tools can
provide useful information during network anomalies (e.g., detecting provide useful information during network anomalies (e.g., detecting
significant reordering, high or intermittent loss), however indirect significant reordering, high or intermittent loss), however indirect
measurements would need to be carefully designed to provide reliable measurements would need to be carefully designed to provide
signals for diagnostics and troubleshooting. information for diagnostics and troubleshooting.
The design trade-offs for radio networks are often very different The design trade-offs for radio networks are often very different
from those of wired networks. A radio-based network (e.g., cellular from those of wired networks. A radio-based network (e.g., cellular
mobile, enterprise WiFi, satellite access/back-haul, point-to-point mobile, enterprise WiFi, satellite access/back-haul, point-to-point
radio) has the complexity of a subsystem that performs radio resource radio) has the complexity of a subsystem that performs radio resource
management, with direct impact on the available capacity, and management, with direct impact on the available capacity, and
potentially loss/reordering of packets. The impact of the pattern of potentially loss/reordering of packets. The impact of the pattern of
loss and congestion, differs for different traffic types, correlation loss and congestion, differs for different traffic types, correlation
with propagation and interference can all have significant impact on with propagation and interference can all have significant impact on
the cost and performance of a provided service. For radio links, the the cost and performance of a provided service. For radio links, the
skipping to change at page 25, line 14 skipping to change at page 25, line 19
tools seldom seek to observe the payload, or other application tools seldom seek to observe the payload, or other application
details. A flow that hides its transport header information could details. A flow that hides its transport header information could
imply "don't touch" to some operators. This might limit a trouble- imply "don't touch" to some operators. This might limit a trouble-
shooting response to "can't help, no trouble found". shooting response to "can't help, no trouble found".
3.4. Header Compression 3.4. Header Compression
Header compression saves link capacity by compressing network and Header compression saves link capacity by compressing network and
transport protocol headers on a per-hop basis. It was widely used transport protocol headers on a per-hop basis. It was widely used
with low bandwidth dial-up access links, and still finds application with low bandwidth dial-up access links, and still finds application
on wireless links that are subject to capacity constraints. Header on wireless links that are subject to capacity constraints. Examples
compression has been specified for use with TCP/IP and RTP/UDP/IP of header compression include use with TCP/IP and RTP/UDP/IP flows
flows [RFC2507], [RFC2508], [RFC4995]. [RFC2507], [RFC2508], [RFC4995].
While it is possible to compress only the network layer headers, While it is possible to compress only the network layer headers,
significant savings can be made if both the network and transport significant savings can be made if both the network and transport
layer headers are compressed together as a single unit. The Secure layer headers are compressed together as a single unit. The SRTP
RTP extensions [RFC3711] were explicitly designed to leave the extensions [RFC3711] were explicitly designed to leave the transport
transport protocol headers unencrypted, but authenticated, since protocol headers unencrypted, but authenticated, since support for
support for header compression was considered important. Encrypting header compression was considered important. Encrypting the
the transport protocol headers does not break such header transport protocol headers does not break such header compression,
compression, but does cause a fall back to compressing only the but does cause a fall back to compressing only the network layer
network layer headers, with a significant reduction in efficiency. headers, with a significant reduction in efficiency.
4. Encryption and Authentication of Transport Headers 4. Encryption and Authentication of Transport Headers
End-to-end encryption can be applied at various protocol layers. It End-to-end encryption can be applied at various protocol layers. It
can be applied above the transport to encrypt the transport payload can be applied above the transport to encrypt the transport payload
(e.g., using TLS). This can hide information from an eavesdropper in (e.g., using TLS). This can hide information from an eavesdropper in
the network. It can also help protect the privacy of a user, by the network. It can also help protect the privacy of a user, by
hiding data relating to user/device identity or location. hiding data relating to user/device identity or location.
4.1. Motivation 4.1. Motivation
skipping to change at page 27, line 11 skipping to change at page 27, line 15
expose the transport protocol header information in the clear, expose the transport protocol header information in the clear,
allows in-network devices to observe these fields. An integrity allows in-network devices to observe these fields. An integrity
check is not able to prevent in-network modification, but can check is not able to prevent in-network modification, but can
prevent a receiving from accepting changes and avoid impact on the prevent a receiving from accepting changes and avoid impact on the
transport protocol operation. transport protocol operation.
An example transport authentication mechanism is TCP- An example transport authentication mechanism is TCP-
Authentication (TCP-AO) [RFC5925]. This TCP option authenticates Authentication (TCP-AO) [RFC5925]. This TCP option authenticates
the IP pseudo header, TCP header, and TCP data. TCP-AO protects the IP pseudo header, TCP header, and TCP data. TCP-AO protects
the transport layer, preventing attacks from disabling the TCP the transport layer, preventing attacks from disabling the TCP
connection itself and provides replay protection. TCP-AO might connection itself and provides replay protection. Such
interact with middleboxes, depending on their behaviour [RFC3234]. authentication might interact with middleboxes, depending on their
behaviour [RFC3234].
The IPsec Authentication Header (AH) [RFC4302] was designed to The IPsec Authentication Header (AH) [RFC4302] was designed to
work at the network layer and authenticate the IP payload. This work at the network layer and authenticate the IP payload. This
approach authenticates all transport headers, and verifies their approach authenticates all transport headers, and verifies their
integrity at the receiver, preventing in-network modification. integrity at the receiver, preventing in-network modification.
Secure RTP [RFC3711] is another example of a transport protocol The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also
that allows header authentication. provide authentication and integrity without confidentiality using
the NULL encryption algorithm [RFC2410]. SRTP [RFC3711] is
another example of a transport protocol that allows header
authentication.
Selectively Encrypting Transport Headers and Payload: A transport Selectively Encrypting Transport Headers and Payload: A transport
protocol design can encrypt selected header fields, while also protocol design can encrypt selected header fields, while also
choosing to authenticate the entire transport header. This allows choosing to authenticate the entire transport header. This allows
specific transport header fields to be made observable by network specific transport header fields to be made observable by network
devices (explicitly exposed either in a transport header field or devices (explicitly exposed either in a transport header field or
lower layer protocol header). A design that only exposes lower layer protocol header). A design that only exposes
immutable fields can also perform end-to-end authentication of immutable fields can also perform end-to-end authentication of
these fields across the path to prevent undetected modification of these fields across the path to prevent undetected modification of
the immutable transport headers. the immutable transport headers.
skipping to change at page 28, line 33 skipping to change at page 28, line 41
protection. protection.
5. Addition of Transport OAM Information to Network-Layer Headers 5. Addition of Transport OAM Information to Network-Layer Headers
An on-path device can make measurements by utilising additional An on-path device can make measurements by utilising additional
protocol headers carrying operations, administration and management protocol headers carrying operations, administration and management
(OAM) information in an additional packet header. Using network- (OAM) information in an additional packet header. Using network-
layer approaches to reveal information has the potential that the layer approaches to reveal information has the potential that the
same method (and hence same observation and analysis tools) can be same method (and hence same observation and analysis tools) can be
consistently used by multiple transport protocols. This approach consistently used by multiple transport protocols. This approach
also could be applied to methods beyond operations, administration also could be applied to methods beyond OAM (see Section 6). There
and management (see Section 6). There can also be less desirable can also be less desirable implications from separating the operation
implications from separating the operation of the transport protocol of the transport protocol from the measurement framework.
from the measurement framework.
5.1. Use of OAM within a Maintenance Domain 5.1. Use of OAM within a Maintenance Domain
OAM information can be added at the ingress to a maintenance domain OAM information can be added at the ingress to a maintenance domain
(e.g., an Ethernet protocol header with timestamps and sequence (e.g., an Ethernet protocol header with timestamps and sequence
number information using a method such as 802.11ag or in-situ OAM number information using a method such as 802.11ag or in-situ OAM
[I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol). [I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol).
The additional header information is typically removed the at the The additional header information is typically removed the at the
egress of the maintenance domain. egress of the maintenance domain.
Although some types of measurements are supported, this approach does Although some types of measurements are supported, this approach does
not cover the entire range of measurements described in this not cover the entire range of measurements described in this
document. In some cases, it can be difficult to position measurement document. In some cases, it can be difficult to position measurement
tools at the appropriate segments/nodes and there can be challenges tools at the appropriate segments/nodes and there can be challenges
in correlating the downstream/upstream information when in-band OAM in correlating the downstream/upstream information when in-band OAM
data is inserted by an on-path device. data is inserted by an on-path device.
skipping to change at page 29, line 14 skipping to change at page 29, line 22
in correlating the downstream/upstream information when in-band OAM in correlating the downstream/upstream information when in-band OAM
data is inserted by an on-path device. data is inserted by an on-path device.
5.2. Use of OAM across Multiple Maintenance Domains 5.2. Use of OAM across Multiple Maintenance Domains
OAM information can also be added at the network layer as an IPv6 OAM information can also be added at the network layer as an IPv6
extension header or an IPv4 option. This information can be used extension header or an IPv4 option. This information can be used
across multiple network segments, or between the transport endpoints. across multiple network segments, or between the transport endpoints.
One example is the IPv6 Performance and Diagnostic Metrics (PDM) One example is the IPv6 Performance and Diagnostic Metrics (PDM)
Destination Option [RFC8250]. This allows a sender to optionally destination option [RFC8250]. This allows a sender to optionally
include a destination option that caries header fields that can be include a destination option that caries header fields that can be
used to observe timestamps and packet sequence numbers. This used to observe timestamps and packet sequence numbers. This
information could be authenticated by receiving transport endpoints information could be authenticated by receiving transport endpoints
when the information is added at the sender and visible at the when the information is added at the sender and visible at the
receiving endpoint, although methods to do this have not currently receiving endpoint, although methods to do this have not currently
been proposed. This method has to be explicitly enabled at the been proposed. This method has to be explicitly enabled at the
sender. sender.
6. Intentionally Exposing Transport Information to the Network 6. Intentionally Exposing Transport Information to the Network
A transport protocol can choose to expose certain transport A transport protocol can choose to expose certain transport
information to on-path devices operating at the network layer by information to on-path devices operating at the network layer by
sending observable fields. One approach is to make an explicit sending observable fields. One approach is to make an explicit
choice not to encrypt certain transport header fields, making this choice not to encrypt certain transport header fields, making this
transport information observable by the network. Another approach is transport information observable by the network. Another approach is
to choose to expose transport information through the use of network- to choose to expose transport information through the use of network-
layer extension headers. Both are examples of explicit signals that layer extension headers. Both are examples of explicit information
the information is intended to be used by network devices on the path intended to be used by network devices on the path [RFC8558].
[RFC8558].
Whatever the mechanism used to expose the information, a decision to Whatever the mechanism used to expose the information, a decision to
only expose specific transport information, places the transport only expose specific transport information, places the transport
endpoint in control of what to expose or not to expose outside of the endpoint in control of what to expose or not to expose outside of the
encrypted transport header. This decision can then be made encrypted transport header. This decision can then be made
independently of the transport protocol functionality. This provides independently of the transport protocol functionality. This can be
opportunities to standardise the method and format used to expose done by exposing part of the transport header or as a network layer
this transport information. This can be done by exposing part of the option/extension.
transport header or as a network layer option/extension.
6.1. Exposing Transport Information in Extension Headers 6.1. Exposing Transport Information in Extension Headers
At the network-layer, packets can carry optional headers (similar to At the network-layer, packets can carry optional headers (similar to
Section 5) that may be used to explicitly expose transport header Section 5) that may be used to explicitly expose transport header
information to the on-path devices operating at the network layer information to the on-path devices operating at the network layer
(Section 3.1.3). For example, an endpoint that sends an IPv6 Hop-by- (Section 3.1.3). For example, an endpoint that sends an IPv6 Hop-by-
Hop option [RFC8200] can provide explicit transport layer information Hop option [RFC8200] can provide explicit transport layer information
that can be observed and used by network devices on the path. that can be observed and used by network devices on the path.
Network-layer optional headers explicitly indicate the information
that is exposed, whereas use of exposed transport header information
first requires an observer to identify the transport protocol and its
format. See Section 3.1.1 for further discussion of transport
protocol identification.
An arbitrary path can include one or more network devices that drop An arbitrary path can include one or more network devices that drop
packets that include a specific header or option used for this packets that include a specific header or option used for this
purpose (see [RFC7872]). This could impact the proper functioning of purpose (see [RFC7872]). This could impact the proper functioning of
the protocols using the path. Protocol methods can be designed to the protocols using the path. Protocol methods can be designed to
probe to discover whether the specific option(s) can be used along probe to discover whether the specific option(s) can be used along
the current path, enabling use on arbitrary paths. the current path, enabling use on arbitrary paths.
6.2. Common Exposed Transport Information 6.2. Common Exposed Transport Information
There are opportunities for multiple transport protocols to There are opportunities for multiple transport protocols to
skipping to change at page 30, line 48 skipping to change at page 31, line 14
evolution of transport-independent tools around a common evolution of transport-independent tools around a common
observable header, and permit transport protocols to also evolve observable header, and permit transport protocols to also evolve
independently of this ossified header [RFC8558]. independently of this ossified header [RFC8558].
o On the other hand, protocols and implementations may not o On the other hand, protocols and implementations may not
consistently expose external information that reflects the actual consistently expose external information that reflects the actual
internal information used by the protocol itself. An endpoint/ internal information used by the protocol itself. An endpoint/
protocol could choose to expose transport header information to protocol could choose to expose transport header information to
optimise the benefit it gets from the network [RFC8558]. The optimise the benefit it gets from the network [RFC8558]. The
value of this information would be enhanced if the exposed value of this information would be enhanced if the exposed
information could be verified to match the internal state of the information could be verified to match the protocol's observed
transport by observing the transport behaviour. behavior.
7. Implications of Protecting the Transport Headers 7. Implications of Protecting the Transport Headers
The choice of which transport header fields to expose and which to The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible. header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to Security work typically employs a design technique that seeks to
skipping to change at page 32, line 15 skipping to change at page 32, line 28
information in this transport header. A network device can have information in this transport header. A network device can have
confidence that the well-known (and ossified) transport header confidence that the well-known (and ossified) transport header
information represents the actual state of the endpoints. information represents the actual state of the endpoints.
When encryption is used to hide some or all of the transport headers, When encryption is used to hide some or all of the transport headers,
the transport protocol chooses which information to reveal to the the transport protocol chooses which information to reveal to the
network about its internal state, what information to leave network about its internal state, what information to leave
encrypted, and what fields to grease to protect against future encrypted, and what fields to grease to protect against future
ossification. Such a transport could be designed (or an existing ossification. Such a transport could be designed (or an existing
transport modified), for example, to provide summary data regarding transport modified), for example, to provide summary data regarding
its performance, congestion control state, etc., or to make an its performance, congestion control state, etc., or to make available
explicit measurement signal available. For example, a QUIC endpoint explicit measurement information. For example, a QUIC endpoint can
can optionally set the spin bit to reflect to explicitly reveal the optionally set the spin bit to reflect to explicitly reveal the RTT
RTT of an encrypted transport session to the on-path network devices of an encrypted transport session to the on-path network devices
[I-D.ietf-quic-transport]). [I-D.ietf-quic-transport]).
When providing or using such information, it is important to consider When providing or using such information, it is important to consider
the privacy of the user and their incentive for providing accurate the privacy of the user and their incentive for providing accurate
and detailed information. Protocols that selectively reveal some and detailed information. Protocols that selectively reveal some
transport state or measurement signals are choosing to establish a transport state or measurable information are choosing to establish a
trust relationship with the network operators. There is no protocol trust relationship with the network operators. There is no protocol
mechanism that can guarantee that the information provided represents mechanism that can guarantee that the information provided represents
the actual transport state of the endpoints, since those endpoints the actual transport state of the endpoints, since those endpoints
can always send additional information in the encrypted part of the can always send additional information in the encrypted part of the
header, to update or replace whatever they reveal. This reduces the header, to update or replace whatever they reveal. This reduces the
ability to independently measure and verify that a protocol is ability to independently measure and verify that a protocol is
behaving as expected. For some operational uses, the information has behaving as expected. For some operational uses, the information has
to contain sufficient detail to understand, and possibly reconstruct, to contain sufficient detail to understand, and possibly reconstruct,
the network traffic pattern for further testing. In this case, the network traffic pattern for further testing. In this case,
operators have to gain the trust of transport protocol implementers operators have to gain the trust of transport protocol implementers
if the transport headers are to correctly reveal such information. if the transport headers are to correctly reveal such information.
Operations, Administration, and Maintenance (OAM) data records OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a
[I-D.ietf-ippm-ioam-data] could be embedded into a variety of variety of encapsulation methods at different layers to support the
encapsulation methods at different layers to support the goals of a goals of a specific operational domain. OAM-related metadata can
specific operational domain. OAM-related metadata can support support functions such as performance evaluation, path-tracing, path
functions such as performance evaluation, path-tracing, path
verification information, classification and a diversity of other verification information, classification and a diversity of other
uses. When encryption is used to hide some or all of the transport uses. When encryption is used to hide some or all of the transport
headers, analysis requires coordination between actors at different headers, analysis requires coordination between actors at different
layers to successfully characterise flows and correlate the layers to successfully characterise flows and correlate the
performance or behaviour of a specific mechanism with the performance or behaviour of a specific mechanism with the
configuration and traffic using operational equipment (e.g., configuration and traffic using operational equipment (e.g.,
combining transport and network measurements to explore congestion combining transport and network measurements to explore congestion
control dynamics, the implications of designs for active queue control dynamics, the implications of designs for active queue
management or circuit breakers). management or circuit breakers).
skipping to change at page 33, line 42 skipping to change at page 34, line 4
of the traffic aggregate passing through a network device or segment of the traffic aggregate passing through a network device or segment
of the network the path, the dynamics of the uncharacterised traffic of the network the path, the dynamics of the uncharacterised traffic
might not have a significant collateral impact on the performance of might not have a significant collateral impact on the performance of
other traffic that shares this network segment. Once the proportion other traffic that shares this network segment. Once the proportion
of this traffic increases, monitoring the traffic can determine if of this traffic increases, monitoring the traffic can determine if
appropriate safety measures have to be put in place. appropriate safety measures have to be put in place.
Tracking the impact of new mechanisms and protocols requires traffic Tracking the impact of new mechanisms and protocols requires traffic
volume to be measured and new transport behaviours to be identified. volume to be measured and new transport behaviours to be identified.
This is especially true of protocols operating over a UDP substrate. This is especially true of protocols operating over a UDP substrate.
The level and style of encryption has to be considered in determining The level and style of encryption has to be considered in determining
how this activity is performed. On a shorter timescale, information how this activity is performed. On a shorter timescale, information
could also have to be collected to manage denial of service attacks could also have to be collected to manage DoS attacks against the
against the infrastructure. infrastructure.
7.3. Accountability and Internet Transport Protocols 7.3. Accountability and Internet Transport Protocols
Information provided by tools observing transport headers can be used Information provided by tools observing transport headers can be used
to classify traffic, and to limit the network capacity used by to classify traffic, and to limit the network capacity used by
certain flows, as discussed in Section 3.2.4). Equally, operators certain flows, as discussed in Section 3.2.4). Equally, operators
could use analysis of transport headers and transport flow state to could use analysis of transport headers and transport flow state to
demonstrate that they are not providing differential treatment to demonstrate that they are not providing differential treatment to
certain flows. Obfuscating or hiding this information using certain flows. Obfuscating or hiding this information using
encryption could lead operators and maintainers of middleboxes encryption could lead operators and maintainers of middleboxes
skipping to change at page 35, line 38 skipping to change at page 35, line 45
and traffic patterns. and traffic patterns.
New transport protocol formats are expected to facilitate an New transport protocol formats are expected to facilitate an
increased pace of transport evolution, and with it the possibility to increased pace of transport evolution, and with it the possibility to
experiment with and deploy a wide range of protocol mechanisms. experiment with and deploy a wide range of protocol mechanisms.
There has been recent interest in a wide range of new transport There has been recent interest in a wide range of new transport
methods, e.g., Larger Initial Window, Proportional Rate Reduction methods, e.g., Larger Initial Window, Proportional Rate Reduction
(PRR), congestion control methods based on measuring bottleneck (PRR), congestion control methods based on measuring bottleneck
bandwidth and round-trip propagation time, the introduction of AQM bandwidth and round-trip propagation time, the introduction of AQM
techniques and new forms of ECN response (e.g., Data Centre TCP, techniques and new forms of ECN response (e.g., Data Centre TCP,
DCTP, and methods proposed for L4S).The growth and diversity of DCTP, and methods proposed for L4S). The growth and diversity of
applications and protocols using the Internet also continues to applications and protocols using the Internet also continues to
expand. For each new method or application it is desirable to build expand. For each new method or application it is desirable to build
a body of data reflecting its behaviour under a wide range of a body of data reflecting its behaviour under a wide range of
deployment scenarios, traffic load, and interactions with other deployment scenarios, traffic load, and interactions with other
deployed/candidate methods. deployed/candidate methods.
Encryption of transport header information could reduce the range of Encryption of transport header information could reduce the range of
actors that can observe useful data. This would limit the actors that can observe useful data. This would limit the
information sources available to the Internet community to understand information sources available to the Internet community to understand
the operation of new transport protocols, reducing information to the operation of new transport protocols, reducing information to
skipping to change at page 36, line 13 skipping to change at page 36, line 22
on the Internet is uncertain when only endpoints (i.e., at user on the Internet is uncertain when only endpoints (i.e., at user
devices and within service platforms) can observe performance, and devices and within service platforms) can observe performance, and
when performance cannot be independently verified by all parties. when performance cannot be independently verified by all parties.
Independently observed data is also important to ensure the health of Independently observed data is also important to ensure the health of
the research and development communities and can help promote the research and development communities and can help promote
acceptance of proposed specifications by the wider community (e.g., acceptance of proposed specifications by the wider community (e.g.,
as a method to judge the safety for Internet deployment) and provides as a method to judge the safety for Internet deployment) and provides
valuable input during standardisation. Open standards motivate a valuable input during standardisation. Open standards motivate a
desire to include independent observation and evaluation of desire to include independent observation and evaluation of
performance data, which in turn demands control over where and when performance data, which in turn demands control/understanding about
measurement samples are collected. This requires consideration of where and when measurement samples are collected. This requires
the methods used to observe data and the appropriate balance between consideration of the methods used to observe data and the appropriate
encrypting all and no transport header information. balance between encrypting all and no transport header information.
8. Conclusions 8. Conclusions
Header encryption and strong integrity checks are being incorporated Header encryption and strong integrity checks are being incorporated
into new transport protocols and have important benefits. The pace into new transport protocols and have important benefits. The pace
of development of transports using the WebRTC data channel, and the of development of transports using the WebRTC data channel, and the
rapid deployment of the QUIC transport protocol, can both be rapid deployment of the QUIC transport protocol, can both be
attributed to using the combination of UDP as a substrate while attributed to using the combination of UDP as a substrate while
providing confidentiality and authentication of the encapsulated providing confidentiality and authentication of the encapsulated
transport headers and payload. transport headers and payload.
skipping to change at page 38, line 34 skipping to change at page 38, line 42
sharing the capacity. If increased use of transport header sharing the capacity. If increased use of transport header
encryption results in reduced availability of open data, it could encryption results in reduced availability of open data, it could
eliminate the independent self-checks to the standardisation eliminate the independent self-checks to the standardisation
process that have previously been in place from research and process that have previously been in place from research and
academic contributors (e.g., the role of the IRTF Internet academic contributors (e.g., the role of the IRTF Internet
Congestion Control Research Group (ICCRG) and research Congestion Control Research Group (ICCRG) and research
publications in reviewing new transport mechanisms and assessing publications in reviewing new transport mechanisms and assessing
the impact of their deployment). the impact of their deployment).
Observable transport header information might be useful to various Observable transport header information might be useful to various
stake holders. Other stake holders have incentives to limit what can stake holders. Other sets of stake holders have incentives to limit
be observed. This document does not make recommendations about what what can be observed. This document does not make recommendations
information ought to be exposed, to whom it ought to be observable, about what information ought to be exposed, to whom it ought to be
or how this will be achieved. There are also design choices about observable, or how this will be achieved. There are also design
where observable fields are placed. For example, one location could choices about where observable fields are placed. For example, one
be a part of the transport header outside of the encryption envelope, location could be a part of the transport header outside of the
another alternative is to carry the information in a network-layer encryption envelope, another alternative is to carry the information
option or extension header. New transport protocol designs ought to in a network-layer option or extension header. New transport
explicitly identify any fields that are intended to be observed, protocol designs ought to explicitly identify any fields that are
consider if there are alternative ways of providing the information, intended to be observed, consider if there are alternative ways of
and reflect on the implications of observable fields being used by providing the information, and reflect on the implications of
network devices, and how this might impact user privacy and protocol observable fields being used by network devices, and how this might
evolution when these fields become ossified. impact user privacy and protocol evolution when these fields become
ossified.
As [RFC7258] notes, "Making networks unmanageable to mitigate As [RFC7258] notes, "Making networks unmanageable to mitigate
(pervasive monitoring) is not an acceptable outcome, but ignoring (pervasive monitoring) is not an acceptable outcome, but ignoring
(pervasive monitoring) would go against the consensus documented (pervasive monitoring) would go against the consensus documented
here." Providing explicit information can help avoid traffic being here." Providing explicit information can help avoid traffic being
inappropriately classified, impacting application performance. An inappropriately classified, impacting application performance. An
appropriate balance will emerge over time as real instances of this appropriate balance will emerge over time as real instances of this
tension are analysed [RFC7258]. This balance between information tension are analysed [RFC7258]. This balance between information
exposed and information hidden ought to be carefully considered when exposed and information hidden ought to be carefully considered when
specifying new transport protocols. specifying new transport protocols.
skipping to change at page 40, line 14 skipping to change at page 40, line 23
encrypted transport headers; and a separate domain of protection and encrypted transport headers; and a separate domain of protection and
associated keys for any observable transport header fields. associated keys for any observable transport header fields.
Exposed transport headers are sometimes utilised as a part of the Exposed transport headers are sometimes utilised as a part of the
information to detect anomalies in network traffic. "While PM is an information to detect anomalies in network traffic. "While PM is an
attack, other forms of monitoring that might fit the definition of PM attack, other forms of monitoring that might fit the definition of PM
can be beneficial and not part of any attack, e.g., network can be beneficial and not part of any attack, e.g., network
management functions monitor packets or flows and anti-spam management functions monitor packets or flows and anti-spam
mechanisms need to see mail message content." [RFC7258]. This can mechanisms need to see mail message content." [RFC7258]. This can
be used as the first line of defence to identify potential threats be used as the first line of defence to identify potential threats
from DOS or malware and redirect suspect traffic to dedicated nodes from DoS or malware and redirect suspect traffic to dedicated nodes
responsible for DOS analysis, malware detection, or to perform packet responsible for DoS analysis, malware detection, or to perform packet
"scrubbing" (the normalisation of packets so that there are no "scrubbing" (the normalisation of packets so that there are no
ambiguities in interpretation by the ultimate destination of the ambiguities in interpretation by the ultimate destination of the
packet). These techniques are currently used by some operators to packet). These techniques are currently used by some operators to
also defend from distributed DOS attacks. also defend from distributed DoS attacks.
Exposed transport header fields can also form a part of the Exposed transport header fields can also form a part of the
information used by the receiver of a transport protocol to protect information used by the receiver of a transport protocol to protect
the transport layer from data injection by an attacker. In the transport layer from data injection by an attacker. In
evaluating this use of exposed header information, it is important to evaluating this use of exposed header information, it is important to
consider whether it introduces a significant DOS threat. For consider whether it introduces a significant DoS threat. For
example, an attacker could construct a DOS attack by sending packets example, an attacker could construct a DoS attack by sending packets
with a sequence number that falls within the currently accepted range with a sequence number that falls within the currently accepted range
of sequence numbers at the receiving endpoint, this would then of sequence numbers at the receiving endpoint, this would then
introduce additional work at the receiving endpoint, even though the introduce additional work at the receiving endpoint, even though the
data in the attacking packet might not finally be delivered by the data in the attacking packet might not finally be delivered by the
transport layer. This is sometimes known as a "shadowing attack". transport layer. This is sometimes known as a "shadowing attack".
An attack can, for example, disrupt receiver processing, trigger loss An attack can, for example, disrupt receiver processing, trigger loss
and retransmission, or make a receiving endpoint perform unproductive and retransmission, or make a receiving endpoint perform unproductive
decryption of packets that cannot be successfully decrypted (forcing decryption of packets that cannot be successfully decrypted (forcing
a receiver to commit decryption resources, or to update and then a receiver to commit decryption resources, or to update and then
restore protocol state). restore protocol state).
skipping to change at page 41, line 19 skipping to change at page 41, line 26
between encrypting all and no transport header information. Open between encrypting all and no transport header information. Open
data, and accessibility to tools that can help understand trends in data, and accessibility to tools that can help understand trends in
application deployment, network traffic and usage patterns can all application deployment, network traffic and usage patterns can all
contribute to understanding security challenges. contribute to understanding security challenges.
The Security and Privacy Considerations in the Framework for Large- The Security and Privacy Considerations in the Framework for Large-
Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain
considerations for Active and Passive measurement techniques and considerations for Active and Passive measurement techniques and
supporting material on measurement context. supporting material on measurement context.
Addition of observable signals to the path increases the information Addition of observable transport information to the path increases
available to an observer and may, when the information can be linked the information available to an observer and may, when this
to a node or user, reduce the privacy of the user. See the security information can be linked to a node or user, reduce the privacy of
considerations of [RFC8558]. the user. See the security considerations of [RFC8558].
10. IANA Considerations 10. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Mohamed Boucadair, Spencer Dawkins, The authors would like to thank Mohamed Boucadair, Spencer Dawkins,
Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen
Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris
Wood, Thomas Fossati, Martin Thomson, David Black, and other members Wood, Thomas Fossati, Martin Thomson, David Black, and other members
of the TSVWG for their comments and feedback. of TSVWG for their comments and feedback.
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 688421, research and innovation programme under grant agreement No 688421,
and the EU Stand ICT Call 4. The opinions expressed and arguments and the EU Stand ICT Call 4. The opinions expressed and arguments
employed reflect only the authors' view. The European Commission is employed reflect only the authors' view. The European Commission is
not responsible for any use that might be made of that information. not responsible for any use that might be made of that information.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
skipping to change at page 43, line 9 skipping to change at page 43, line 18
Communications, Oulu, Finland.", June 2017. Communications, Oulu, Finland.", June 2017.
[Quic-Trace] [Quic-Trace]
"https:QUIC trace utilities //github.com/google/quic- "https:QUIC trace utilities //github.com/google/quic-
trace". trace".
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
skipping to change at page 43, line 33 skipping to change at page 43, line 46
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999, DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>. <https://www.rfc-editor.org/info/rfc2508>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<https://www.rfc-editor.org/info/rfc3234>. <https://www.rfc-editor.org/info/rfc3234>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 46, line 9 skipping to change at page 46, line 28
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options", on Filtering of IPv4 Packets Containing IPv4 Options",
BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
<https://www.rfc-editor.org/info/rfc7126>. <https://www.rfc-editor.org/info/rfc7126>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
skipping to change at page 48, line 9 skipping to change at page 48, line 41
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404, Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, DOI 10.17487/RFC8404, July 2018,
<https://www.rfc-editor.org/info/rfc8404>. <https://www.rfc-editor.org/info/rfc8404>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8462] Rooney, N. and S. Dawkins, Ed., "Report from the IAB
Workshop on Managing Radio Networks in an Encrypted World
(MaRNEW)", RFC 8462, DOI 10.17487/RFC8462, October 2018,
<https://www.rfc-editor.org/info/rfc8462>.
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/info/rfc8517>.
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/info/rfc8546>. 2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>. <https://www.rfc-editor.org/info/rfc8548>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
skipping to change at page 51, line 19 skipping to change at page 52, line 19
-12 Updated following additional feedback from reviewers. -12 Updated following additional feedback from reviewers.
-13 Updated following 2nd WGLC with comments from D.L.Black; T. -13 Updated following 2nd WGLC with comments from D.L.Black; T.
Herbert; Ekr; and other reviewers. Herbert; Ekr; and other reviewers.
-14 Update to resolve feedback to rev -13. This moves the general -14 Update to resolve feedback to rev -13. This moves the general
discussion of adding fields to transport packets to section 6, and discussion of adding fields to transport packets to section 6, and
discusses with reference to material in RFC8558. discusses with reference to material in RFC8558.
-15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins
and M. Duke. Update to add reference to RFC7605. Clarify a focus
on immutable transport fields, rather than modifying middleboxes with
Tom H. Clarified Header Compression discusion only provides a list
of examples of HC methods for transport. Clarified port usage with
Tom H/Joe T. Removed some duplicated sentences, and minor edits.
Added NULL-ESP. Improved after initial feedback from Martin Duke.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
EMail: gorry@erg.abdn.ac.uk EMail: gorry@erg.abdn.ac.uk
 End of changes. 72 change blocks. 
213 lines changed or deleted 256 lines changed or added

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