draft-ietf-tsvwg-transport-encrypt-15.txt   draft-ietf-tsvwg-transport-encrypt-16.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: November 2, 2020 University of Glasgow Expires: January 14, 2021 University of Glasgow
May 01, 2020 July 13, 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-15 draft-ietf-tsvwg-transport-encrypt-16
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
longer possible when those transport headers are encrypted. This longer possible when those transport headers are encrypted.
document discusses the possible impact when network traffic uses a
protocol with an encrypted transport header. It suggests issues to This document discusses the possible impact when network traffic uses
a protocol with an encrypted transport header. It suggests issues to
consider when designing new transport protocols or features. These consider when designing new transport protocols or features. These
considerations arise from concerns such as network operations, considerations arise from concerns such as network operations,
prevention of network ossification, enabling transport protocol prevention of network ossification, enabling transport protocol
evolution and respect for user privacy. evolution and respect for user privacy.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2020. This Internet-Draft will expire on January 14, 2021.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . 4 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. To Identify Transport Protocols and Flows . . . . . . . . 13
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 20 3.2. To Understand Transport Protocol Performance . . . . . . 14
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 24 3.3. To Support Network Operations . . . . . . . . . . . . . . 21
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 25 3.4. To Support Network Diagnostics and Troubleshooting . . . 24
4. Encryption and Authentication of Transport Headers . . . . . 25 3.5. To Support Header Compression . . . . . . . . . . . . . . 25
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 25 4. Encryption and Authentication of Transport Headers . . . . . 26
4.2. Approaches to Transport Header Protection . . . . . . . . 26 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Approaches to Transport Header Protection . . . . . . . . 27
5. Addition of Transport OAM Information to Network-Layer 5. Addition of Transport OAM Information to Network-Layer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 29
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 . 30
6.1. Exposing Transport Information in Extension Headers . . . 30 6.1. Exposing Transport Information in Extension Headers . . . 30
6.2. Common Exposed Transport Information . . . . . . . . . . 30 6.2. Common Exposed Transport Information . . . . . . . . . . 31
6.3. Considerations for Exposing Transport Information . . . . 30 6.3. Considerations for Exposing Transport Information . . . . 31
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 . . . . . . . . . . . . . . . . . 32
7.2. Characterising "Unknown" Network Traffic . . . . . . . . 33 7.2. Characterising "Unknown" Network Traffic . . . . . . . . 34
7.3. Accountability and Internet Transport Protocols . . . . . 34 7.3. Accountability and Internet Transport Protocols . . . . . 34
7.4. Impact on Network Operations . . . . . . . . . . . . . . 34 7.4. Impact on Network Operations . . . . . . . . . . . . . . 35
7.5. Impact on Research, Development and Deployment . . . . . 35 7.5. Impact on Research, Development and Deployment . . . . . 35
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
12. Informative References . . . . . . . . . . . . . . . . . . . 42 12. Informative References . . . . . . . . . . . . . . . . . . . 42
Appendix A. Revision information . . . . . . . . . . . . . . . . 50 Appendix A. Revision information . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 [RFC6347][I-D.ietf-tls-dtls13],
RTP [RFC3711], and TCPcrypt [RFC8548]. Some of these also provide Secure Real-time Transport Protocol (SRTP) [RFC3711], and tcpcrypt
integrity protection of all, or part, of the transport header. [RFC8548]. Some of these specifications also provide 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 3, line 43 skipping to change at page 3, line 45
There is also a middle ground, comprising transport protocols that There is also a middle ground, comprising transport protocols that
encrypt some, or all, of the transport layer header information, in encrypt some, or all, of the transport layer header information, in
addition to encrypting the transport payload data. An example of addition to encrypting the transport payload data. An example of
such a protocol, that is now seeing widespread interest and such a protocol, that is now seeing widespread interest and
deployment, is the QUIC transport protocol [I-D.ietf-quic-transport]. deployment, is the QUIC transport protocol [I-D.ietf-quic-transport].
The encryption and authentication of transport header information can The encryption and authentication of transport header information can
prevent unwanted modification of transport header information by prevent unwanted modification of transport header information by
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].
document, the term "transport header information" is used to describe
transport layer information concerning the operation of the transport In this document, the term "transport header information" is used to
protocol (i.e., information used by the transport protocol that might describe transport layer information concerning the operation of the
be carried in a protocol header). This does not refer to transport transport protocol (i.e., information used by the transport protocol
payload data (i.e., information transferred by the transport that might be carried in a protocol header). This does not refer to
service), which itself could be encrypted. transport payload data (i.e., information transferred by the
transport service), which itself could be encrypted.
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 includes 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 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 a transport header field; and whether any modification along modify a transport header field; and whether any modification along
the network path can be detected by the receiving endpoint. This can the network path can be detected by the receiving endpoint. This can
require changes to network operations and other practises and could require changes to network operations and other practises and could
drive changes to the design of network measurement for research, drive changes to the design of network measurement for research,
operational, and standardisation purposes. 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 RFC7258 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.
The transport protocols developed for the Internet are used across a The transport protocols developed for the Internet are used across a
wide range of paths across network segments with many different wide range of paths across network segments with many different
regulatory, commercial, and engineering considerations. This regulatory, commercial, and engineering considerations. This
skipping to change at page 4, line 47 skipping to change at page 4, line 49
transport layer headers, and considers the effect of such changes on transport layer headers, and considers the effect of such changes on
transport protocol design, transport protocol evolution, and network transport protocol design, transport protocol evolution, and network
operations. It also considers some anticipated implications on operations. It also considers some anticipated implications on
application evolution. This provides considerations relating to the application evolution. This provides considerations relating to the
design of transport protocols and features where the transport design of transport protocols and features where the transport
protocol encrypts some or all of their header information. protocol encrypts some or all of their header information.
2. Context and Rationale 2. Context and Rationale
The transport layer provides end-to-end interactions between The transport layer provides end-to-end interactions between
endpoints (processes) using an Internet path. Transport protocols endpoints (processes) using a network path. Transport protocols
layer over the network-layer service, and are usually sent in the layer over the network-layer service, and are usually sent in the
payload of network-layer packets. Transport protocols support end- payload of network-layer packets. Transport protocols support end-
to-end communication between applications, using higher-layer to-end communication between applications, using higher-layer
protocols running on the end systems (i.e., transport endpoints). protocols running on the end systems (i.e., transport endpoints).
This simple architectural view does not present one of the core This simple architectural view does not present one of the core
functions of an Internet transport: to discover and adapt to the functions of an Internet transport: to discover and adapt to the
characteristics of the network path that is currently being used. characteristics of the network path that is currently being used.
The design of Internet transport protocols is as much about trying to The design of Internet transport protocols is as much about trying to
avoid the unwanted side effects of congestion on a flow and other avoid the unwanted side effects of congestion on a flow and other
capacity-sharing flows, avoiding congestion collapse, adapting to capacity-sharing flows, avoiding congestion collapse, adapting to
changes in the path characteristics, etc., as it is about end-to-end changes in the path characteristics, etc., as it is about end-to-end
feature negotiation, flow control, and optimising for performance of feature negotiation, flow control, and optimising for performance of
a specific application. a specific application.
Transport headers have end-to-end meaning, but have often been Transport headers have end-to-end meaning, but have often been
observed by equipment within the network. Transport protocol observed by equipment within the network. Transport protocol
specifications have not tended to consider this, and have often specifications have not tended to consider this. Designs have often
failed to indicate what parts of the transport header are intended to failed to:
be invariant across protocol versions and visible to the network; to
specify what parts of the transport header can be modified by the o specify what parts of the transport header can be modified by the
network to signal to the transport, and in what way; and to define network to signal to the transport, and in what way;
which parts of the header are private and/or expected to change in
future and which need to be protected for privacy or to prevent o indicate what parts of the transport header are intended to be
protocol ossification. This motivates a need to change the way invariant across protocol versions and visible to the network;
transport protocols are designed, modified, and specified.
o indicate what parts of the transport header are intended expected
to change in future and might need to be protected to prevent
protocol ossification;
o and have often not defined which parts of the header need to be
protected for privacy.
This motivates a need to change the way transport protocols are
designed, modified, and specified.
Increasing concern about pervasive network monitoring Increasing concern about pervasive network monitoring
[RFC7258][RFC7624], and growing awareness of the problem of protocol [RFC7258][RFC7624], and growing awareness of the problem of protocol
ossification caused by middlebox interference with Internet traffic, ossification caused by middlebox interference with Internet traffic,
has motivated a shift in transport protocol design. Recent transport has motivated a shift in transport protocol design. For example,
protocols, such as QUIC [I-D.ietf-quic-transport], encrypt the transport protocols, such as QUIC [I-D.ietf-quic-transport], encrypt
majority of their transport headers to prevent observation and the 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.
skipping to change at page 6, line 9 skipping to change at page 6, line 21
inform the selection of appropriate mechanisms to ensure a safe, inform the selection of appropriate mechanisms to ensure a safe,
reliable, and robust Internet. In turn, network operators and access reliable, and robust Internet. In turn, network operators and access
providers have relied upon being able to observe traffic patterns and providers have relied upon being able to observe traffic patterns and
requirements, both in aggregate and at the flow level, to help requirements, both in aggregate and at the flow level, to help
understand and optimise the behaviour of their networks. understand and optimise the behaviour of their networks.
Transport header encryption can be used to intentionally limit the Transport header encryption can be used to intentionally limit the
information available to network observers. The widespread use would information available to network observers. The widespread use would
therefore limit such observations, unless transport protocols are therefore limit such observations, unless transport protocols are
modified to selectively expose transport header information outside modified to selectively expose transport header information outside
of the encrypted transport header. It is important to understand how of the encrypted transport header.
transport header information is used by networks, to allow future
protocol designs to make an informed choice on what, if any, It is important to understand how transport header information is
transport layer information to expose to the network. used by networks, to allow future protocol designs to make an
informed choice on what, if any, 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 ([RFC8517] transport headers of packets passing through their network ([RFC8517]
gives an operator perspective on such use). 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 an SRTP
RTP (SRTP) flow [RFC3711], or explicitly using exposed protocol flow [RFC3711], or explicitly using exposed protocol information to
information to provide consistent decisions by on-path devices). provide consistent decisions by on-path devices). Header compression
Header compression (e.g., [RFC5795]) depends on understanding of (e.g., [RFC5795]) depends on understanding of transport header and
transport header and the way fields change packet-by-packet; as also the way fields change packet-by-packet; as also do techniques to
do techniques to improve TCP performance by transparent modification improve TCP performance by transparent modification of
of acknowledgement traffic [RFC3449]. Introducing a new transport acknowledgement traffic [RFC3449]. Introducing a new transport
protocol or changes to existing transport header information prevent protocol or changes to existing transport header information prevent
these methods being used or require the network devices to be these methods being used or require the network devices to be
updated. 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
of Transport Layer Security (TLS) 1.3 [RFC8446], where the design of TLS 1.3 [RFC8446], where the design needed to function in the
needed to function in the presence of deployed middleboxes that presence of deployed middleboxes that relied on the presence of
relied on the presence of certain header fields exposed in TLS 1.2. certain header fields exposed in TLS 1.2 [RFC5426]. The design of
Multipath TCP (MPTCP) [RFC8684] also had to be revised to account for
The design of MPTCP also had to be revised to account for middleboxes middleboxes (known as "TCP Normalizers") that monitor the evolution
(known as "TCP Normalizers") that monitor the evolution of the window of the window advertised in the TCP header and then reset connections
advertised in the TCP header and then reset connections when the when the window did not grow as expected. Similarly, issues have
window did not grow as expected. Similarly, issues have been been reported using TCP. For example, TCP Fast Open [RFC7413] can
reported using TCP. For example, TCP Fast Open [RFC7413] can
experience middleboxes that modify the transport header of packets by experience middleboxes that modify the transport header of packets by
removing "unknown" TCP options, segments with unrecognised TCP removing "unknown" TCP options, segments with unrecognised TCP
options can be dropped, segments that contain data and set the SYN options can be dropped, segments that contain data and set the SYN
bit can be dropped, or middleboxes that disrupt connections that send bit can be dropped, or middleboxes that disrupt connections that send
data 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 SACK (SACK) option and therefore fail to correctly rewrite the SACK
skipping to change at page 7, line 36 skipping to change at page 7, line 50
some case, the middleboxes modified or replaced information in the some case, the middleboxes modified or replaced information in the
transport protocol header. transport protocol header.
Transport header encryption prevents an on-path device from observing Transport header encryption prevents an on-path device from observing
the transport headers, and therefore stops mechanisms being built the transport headers, and therefore stops mechanisms being built
that directly rely on or infer semantics of the transport header that directly rely on or infer semantics of the transport header
information. Encryption is normally combined with authentication of information. Encryption is normally combined with authentication of
the protected information. RFC 8546 summarises this approach, the protected information. RFC 8546 summarises this approach,
stating that it is "The wire image, not the protocol's specification, stating that it is "The wire image, not the protocol's specification,
determines how third parties on the network paths among protocol determines how third parties on the network paths among protocol
participants will interact with that protocol" [RFC8546], and it can participants will interact with that protocol" (Section 1 of
be expected that header information that is not encrypted will become
ossified. [RFC8546]), and it can be expected that header information that is
not encrypted will become 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 have to decide whether to
or a part of, the transport layer information. Section 4 of RFC8558 encrypt all, or a part of, the transport layer information.
states: "Anything exposed to the path should be done with the intent Section 4 of [RFC8558] states: "Anything exposed to the path should
that it be used by the network elements on the path" [RFC8558]. be done with the intent that it be used by the network elements on
Protocol designs can decide not to encrypt certain transport header the path".
Protocol designers can decide not to encrypt certain transport header
fields, making those fields observable in the network, or can define fields, making those fields observable in the network, or can define
new fields designed to explicitly expose observable transport layer new fields designed to explicitly expose observable transport layer
information to the network. Where exposed fields are intended to be information to the network. Where exposed fields are intended to be
immutable (i.e., can be observed, but not modified by a network immutable (i.e., can be observed, but not modified by a network
device), the endpoints are encouraged to use authentication to device), the endpoints are encouraged to use authentication to
provide a cryptographic integrity check that can detect if these provide a cryptographic integrity check that can detect if these
immutable fields have been modified by network devices. immutable fields have been modified by network devices.
Authentication can also help to prevent attacks that rely on sending Authentication can also help to prevent attacks that rely on sending
packets that fake exposed control signals in transport headers (e.g., packets that fake exposed control signals in transport headers (e.g.,
TCP RST spoofing). TCP RST spoofing).
Making part of a transport header observable, or exposing new header Making a 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 header fields have been observed within the network for a Transport header fields have been observed within the network for a
variety of purposes. Some purposes are related to network management variety of purposes. Some purposes are related to network management
skipping to change at page 9, line 17 skipping to change at page 9, line 32
operators. Some operators might work without operators. Some operators might work without
that information, or some might turn to more that information, or some might turn to more
ambitious ways to collect, estimate, or infer ambitious ways to collect, estimate, or infer
this data. (Operational practises aimed at this data. (Operational practises aimed at
guessing transport parameters are out of scope guessing transport parameters are out of scope
for this document, and are only mentioned here to for this document, and are only mentioned here to
recognise that encryption does not stop operators recognise that encryption does not stop operators
from attempting to apply practises that have been from attempting to apply practises that have been
used with unencrypted transport headers.) used with unencrypted transport headers.)
See also Section 3, Section 5, Section 7.4 and s See also Section 3, Section 5, Section 7.4 and
(Section 7.5). Section 7.5.
Analysis of Aggregate Traffic: Observable transport headers have Analysis of Aggregate Traffic: Observable transport headers have
been utilised to determine which transport been utilised to determine which transport
protocols and features are being used across a protocols and features are being used across a
network segment, and to measure trends in the network segment, and to measure trends in the
pattern of usage. For some use cases, end-to-end pattern of usage. For some use cases, end-to-end
measurements/traces are sufficient and can assist measurements/traces are sufficient and can assist
in developing and debugging new transports and in developing and debugging new transports and
analysing their deployment. In other uses, it is analysing their deployment. In other uses, it is
important to relate observations to specific important to relate observations to specific
skipping to change at page 9, line 49 skipping to change at page 10, line 16
could fail to produce useful data when those could fail to produce useful data when those
headers are encrypted. While this impact could, headers are encrypted. While this impact could,
in many cases, be small, there are scenarios in many cases, be small, there are scenarios
where operators have actively monitored and where operators have actively monitored and
supported particular services, e.g., to explore supported particular services, e.g., to explore
issues relating to Quality of Service (QoS), to issues relating to Quality of Service (QoS), to
perform fast re-routing of critical traffic, to perform fast re-routing of critical traffic, to
mitigate the characteristics of specific radio mitigate the characteristics of specific radio
links, and so on. links, and so on.
See also Section 3.1 to Section 3.2 and
Section 5.
Troubleshooting: Observable transport headers have been utilised Troubleshooting: Observable transport headers have been utilised
by operators as a part of network troubleshooting by operators as a part of network troubleshooting
and diagnostics. Metrics derived from this and diagnostics. Metrics derived from this
observed header information can help localise the observed header information can help localise the
network segment introducing the loss or latency. network segment introducing the loss or latency.
Effective troubleshooting often requires Effective troubleshooting often requires
understanding of transport behaviour. Flows understanding of transport behaviour. Flows
experiencing packet loss or jitter are hard to experiencing packet loss or jitter are hard to
distinguish from unaffected flows when only distinguish from unaffected flows when only
observing network layer headers. observing network layer headers.
skipping to change at page 10, line 32 skipping to change at page 10, line 43
When the transport header information is When the transport header information is
encrypted, explicit observable fields could also encrypted, explicit observable fields could also
be made available at the network or transport be made available at the network or transport
layers to provide these functions. [RFC8558] layers to provide these functions. [RFC8558]
motivates the design of signals to focus on their motivates the design of signals to focus on their
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.4 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 DoS attacks. application behaviour or distributed DoS attacks.
Operators often seek to uniquely disambiguate Operators often seek to 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
skipping to change at page 12, line 10 skipping to change at page 12, line 20
Section 7.4. Section 7.4.
This analysis does not judge whether specific practises are This analysis does not judge whether specific practises are
necessary. It is not an endorsement of any particular practice. necessary. It is not an endorsement of any 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 can improve
protocol information is used [RFC8404], requiring consideration of privacy, and can help to mitigate certain attacks, but can also
the trade-offs discussed in Section 2.3. affect network operations [RFC8404].
The decision about which transport headers fields are made observable When considering what parts of the transport headers should be
offers trade-offs around header confidentiality versus header encrypted to provide confidentiality, and what parts should be
observability (including non-encrypted, but authenticated, header visible to the network (including non-encrypted but authenticated
fields) for network operations and management, and the implications headers), it is necessary to consider both the impact on network
for ossification and user privacy [Measurement]. Different parties operations and management, and the implications for ossification and
will view the relative importance of these differently. For some, user privacy [Measurement]. Different parties will view the relative
the benefits of encrypting all transport headers outweigh the impact importance of these concerns differently. For some, the benefits of
of doing so; others might analyse the security, privacy and encrypting all the transport headers outweigh the impact of doing so;
ossification impacts, and arrive at a different trade-off. others might analyse the security, privacy, and ossification impacts
and arrive at a different trade-off.
This section reviews examples of the observation of transport layer This section reviews examples of the observation of transport layer
headers within the network. It does not consider intentional headers within the network. Unencrypted transport headers provide
modification of transport headers by middleboxes (such as in Network information can support network operations and management, and this
Address Translation, NAT, or Firewalls). Common issues concerning IP section notes some ways in which this has been done. Unencrypted
address sharing are described in [RFC6269]. transport header information also contributes metadata that can be
exploited for purposes unrelated to network transport measurement,
3.1. Observing Transport Information in the Network diagnostics or troubleshooting (e.g., to block or to throttle traffic
from a specific content provider), and this section also notes some
In-network observation of transport protocol headers requires threats relating to unencrypted transport headers.
knowledge of the format of the transport header:
o Flows have to be identified at the level where observation is
performed. This implies visibility of the protocol and version of
the header, e.g., by defining the wire image [RFC8546]. As
protocols evolve over time, new transport headers could be
introduced. Detecting this could require interpretation of
protocol version information or connection setup information;
o Observing transport header information depends on the observer Exposed transport information also provides a source of information
knowing the location and the syntax of the observable transport that contributes to linked data sets, which could be exploited to
headers. IETF transport protocols can specify this information. deduce private information, e.g., user patterns, user location,
tracking behaviour, etc. This might reveal information the parties
did not intend to be revealed. [RFC6973] aims to make designers,
implementers, and users of Internet protocols aware of privacy-
related design choices in IETF protocols.
The following subsections describe various ways that observable This section does not consider intentional modification of transport
transport header information has been utilised. headers by middleboxes, such as in Network Address Translation (NAT)
or Firewalls. Common issues concerning IP address sharing are
described in [RFC6269].
3.1.1. Flow Identification Using Transport Layer Headers 3.1. To Identify Transport Protocols and Flows
Flow/Session identification [RFC8558] is a common function performed, Information in exposed transport layer headers can be used by the
for example, by measurement activities, QoS classifiers, firewalls, network to identify transport protocols and flows [RFC8558]. The
and as part of Denial of Service (DoS) prevention. ability to identify transport protocols, flows, and sessions is a
common function performed, for example, by measurement activities,
QoS classifiers, and firewalls. These functions can be beneficial,
and performed with the consent of, and in support of, the end user.
Alternatively, a network operator could use the same mechanisms to
support practises that are adversarial to the end user, including
blocking, de-prioritising, and monitoring traffic without consent.
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, an assigned transport port (e.g., 0..49151) can In some uses, an assigned transport port (e.g., 0..49151) can
identify the protocol [RFC7605]. However, port information alone is identify the upper-layer protocol or service [RFC7605]. However,
not sufficient to guarantee identification. Applications can use port information alone is not sufficient to guarantee identification.
arbitrary ports and do not need to use assigned port numbers. The Applications can use arbitrary ports and do not need to use assigned
use of an assigned port number is also not limited to the protocol port numbers. The use of an assigned port number is also not limited
for which the port is intended. Multiple sessions can also be to the protocol for which the port is intended. Multiple sessions
multiplexed on a single port, and ports can be re-used by subsequent can also be multiplexed on a single port, and ports can be re-used by
sessions. subsequent sessions.
Some flows can be identified by observing signalling protocol data Some flows can be identified by observing signalling protocol data
(e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of (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 magic numbers placed in the first byte(s) of the datagram payload
[RFC7983]. [RFC7983].
When transport header information can not be observed, this removes When transport header information cannot 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 [RFC4566] to classify a flow as audio traffic, might
(possibly less-reliable) heuristics to infer that short UDP packets instead use (possibly less-reliable) heuristics to infer that short
with regular spacing carry audio traffic. Operational practises UDP packets with regular spacing carry audio traffic. Operational
aimed at inferring transport parameters are out of scope for this practises aimed at inferring transport parameters are out of scope
document, and are only mentioned here to recognise that encryption for this document, and are only mentioned here to recognise that
does not prevent operators from attempting to apply practises that encryption does not prevent operators from attempting to apply
were used with unencrypted transport headers. The IAB have provided practises that were used with unencrypted transport headers.
a summary of expected implications of increased encryption on network
functions that use the observable headers [RFC8546] and describe the
expected benefits of designs that explicitly declare protocol
invariant header information that can be used for this purpose.
3.1.2. Metrics derived from Transport Layer Headers The IAB [RFC8546] have provided a summary of expected implications of
increased encryption on network functions that use the observable
headers and describe the expected benefits of designs that explicitly
declare protocol invariant header information that can be used for
this purpose.
3.2. To Understand Transport Protocol Performance
Information in exposed transport layer headers can be used by the
network to understand transport protocol performance and behaviour.
3.2.1. Using Information Derived from Transport Layer Headers
Observable transport headers enable explicit measurement and analysis Observable transport headers enable explicit measurement and analysis
of protocol performance, network anomalies, and failure pathologies of protocol performance, network anomalies, and failure pathologies
at any point along the Internet path. Some operators use passive at any point along the Internet path. Some operators use passive
monitoring to manage their portion of the Internet by characterising monitoring to manage their portion of the Internet by characterising
the performance of link/network segments. Inferences from transport the performance of link/network segments. Inferences from transport
headers are used to derive performance metrics. A variety of open headers are used to derive performance metrics. A variety of open
source and commercial tools have been deployed that utilise transport source and commercial tools have been deployed that utilise transport
header information in this way to derive the following metrics: header information in this way to derive the following metrics:
Traffic Rate and Volume: Volume measures per-application can be used Traffic Rate and Volume: Volume measures per-application can be used
to characterise the traffic that uses a network segment or the to characterise the traffic that uses a network segment or the
pattern of network usage. Observing the protocol sequence number pattern of network usage. Observing the protocol sequence number
and packet size offers one way to measure this (e.g., measurements and packet size offers one way to measure this (e.g., measurements
observing counters in periodic reports such as RTCP; or observing counters in periodic reports such as RTCP; or
measurements observing protocol sequence numbers in statistical measurements observing protocol sequence numbers in statistical
samples of packet flows, or specific control packets, such as samples of packet flows, or specific control packets, such as
those observed at the start and end of a flow). Measurements can those observed at the start and end of a flow).
be per endpoint or for an endpoint aggregate (e.g., to assess
subscriber usage). Measurements can also be used to trigger Measurements can be per endpoint, or for an endpoint aggregate.
traffic shaping, and to associate QoS support within the network This can be used, for example, to assess subscriber usage or for
and lower layers. Volume measures can also be valuable for billing purposes.
capacity planning and providing detail of trends in usage. The
traffic rate and volume can be determined providing that the Measurements can also be used to trigger traffic shaping, and to
associate QoS support within the network and lower layers. This
can be done with consent and in support of an end user, to improve
quality of service; or can be used by the network to de-prioritise
certain flows without user consent.
Volume measures can also be valuable for capacity planning and
providing detail of trends in usage.
The traffic rate and volume can be determined providing that the
packets belonging to individual flows can be identified, but there packets belonging to individual flows can be identified, but there
might be no additional information about a flow when the transport might be no additional information about a flow when the transport
headers cannot be observed. headers cannot be observed.
Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g.,
from transport sequence numbers or inferred from observing from transport sequence numbers or inferred from observing
transport protocol interactions) and has been used as a metric for transport protocol interactions) and has been used as a metric for
performance assessment and to characterise transport behaviour. performance assessment and to characterise transport behaviour.
Understanding the location and root cause of loss can help an Understanding the location and root cause of loss can help an
operator determine whether this requires corrective action. operator determine whether this requires corrective action.
Network operators have used the variation in patterns of loss as a Network operators have used the variation in patterns of loss as a
key performance metric, utilising this to detect changes in the key performance metric, utilising this to detect changes in the
offered service. offered service.
There are various causes of loss, including: corruption of link There are various causes of loss, including: corruption of link
frames (e.g., due to interference on a radio link), buffering loss frames (e.g., due to interference on a radio link), buffering loss
(e.g., overflow due to congestion, Active Queue Management, AQM (e.g., overflow due to congestion, Active Queue Management (AQM)
[RFC7567], or inadequate provision following traffic pre-emption), [RFC7567], or inadequate provision following traffic pre-emption),
and policing (traffic management). Understanding flow loss rates and policing (traffic management) [RFC2475]. Understanding flow
requires either observing sequence numbers in network or transport loss rates requires either observing sequence numbers in network
headers, or maintaining per-flow packet counters (flow or transport headers, or maintaining per-flow packet counters
identification often requires transport layer information). Per- (flow identification often requires transport layer information).
hop loss can also sometimes be monitored at the interface level by Per-hop loss can also sometimes be monitored at the interface
devices in the network. level by devices in the network.
Losses can often occur as bursts, randomly-timed events, etc. The Losses can often occur as bursts, randomly-timed events, etc. The
pattern of loss can provide insight into the cause of loss. It pattern of loss can provide insight into the cause of loss. It
can also be valuable to understand the conditions under which loss can also be valuable to understand the conditions under which loss
occurs, which usually requires relating loss to the traffic occurs, which usually requires relating loss to the traffic
flowing on the network node/segment at the time of loss. This can flowing at a network node or segment at the time of loss. This
also help identify cases where loss could have been wrongly can also help identify cases where loss could have been wrongly
identified, or where the transport did not require transmission of identified, or where the transport did not require transmission of
a lost packet. a lost packet.
Throughput and Goodput: Throughput is the amount of payload data Throughput and Goodput: Throughput is the amount of payload data
sent by a flow per time interval. Goodput [RFC7928] is a measure sent by a flow per time interval. Goodput (see Section 2.5 of
of useful data exchanged (the ratio of useful data to total volume [RFC7928]) is a measure of useful data exchanged (the ratio of
of traffic sent by a flow). The throughput of a flow can be useful data to total volume of traffic sent by a flow). The
determined in the absence of transport header information, throughput of a flow can be determined in the absence of transport
providing that the individual flow can be identified, and the header information, providing that the individual flow can be
overhead known. Goodput requires ability to differentiate loss identified, and the overhead known. Goodput requires ability to
and retransmission of packets, for example by observing packet differentiate loss and retransmission of packets, for example by
sequence numbers in the TCP or the Real-time Transport Protocol observing packet sequence numbers in the TCP or RTP headers
(RTP) headers [RFC3550]. [RFC3550].
Latency: Latency is a key performance metric that impacts Latency: Latency is a key performance metric that impacts
application and user-perceived response times. It often application and user-perceived response times. It often
indirectly impacts throughput and flow completion time. This indirectly impacts throughput and flow completion time. This
determines the reaction time of the transport protocol itself, determines the reaction time of the transport protocol itself,
impacting flow setup, congestion control, loss recovery, and other impacting flow setup, congestion control, loss recovery, and other
transport mechanisms. The observed latency can have many transport mechanisms. The observed latency can have many
components [Latency]. Of these, unnecessary/unwanted queueing in components [Latency]. Of these, unnecessary/unwanted queueing in
network buffers has often been observed as a significant factor network buffers has often been observed as a significant factor
[bufferbloat]. Once the cause of unwanted latency has been [bufferbloat]. Once the cause of unwanted latency has been
skipping to change at page 16, line 13 skipping to change at page 16, line 39
and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
could identify excessively large buffers, indicating where to could identify excessively large buffers, indicating where to
deploy or configure AQM. An AQM method is often deployed in deploy or configure AQM. An AQM method is often deployed in
combination with other techniques, such as scheduling [RFC7567] combination with other techniques, such as scheduling [RFC7567]
[RFC8290] and although parameter-less methods are desired [RFC8290] and although parameter-less methods are desired
[RFC7567], current methods often require tuning [RFC8290] [RFC7567], current methods often require tuning [RFC8290]
[RFC8289] [RFC8033] because they cannot scale across all possible [RFC8289] [RFC8033] because they cannot scale across all possible
deployment scenarios. deployment scenarios.
Latency and round-trip time information can potentially expose
some information useful for approximate geolocation, as discussed
in [PAM-RTT]. Encrypting transport headers can reduce the latency
information that is available.
Variation in delay: Some network applications are sensitive to Variation in delay: Some network applications are sensitive to
(small) changes in packet timing (jitter). Short and long-term (small) changes in packet timing (jitter). Short and long-term
delay variation can impact on the latency of a flow and hence the delay variation can impact on the latency of a flow and hence the
perceived quality of applications using the network. For example, perceived quality of applications using the network. For example,
jitter metrics are often cited when characterising paths jitter metrics are often cited when characterising paths
supporting real-time traffic. The expected performance of such supporting real-time traffic. The expected performance of such
applications, can be inferred from a measure the variation in applications, can be inferred from a measure the variation in
delay observed along a portion of the path [RFC3393] [RFC5481]. delay observed along a portion of the path [RFC3393] [RFC5481].
The requirements resemble those for the measurement of latency. The requirements resemble those for the measurement of latency.
skipping to change at page 17, line 34 skipping to change at page 18, line 15
endpoint. Injection of test traffic can incur an additional cost in endpoint. Injection of test traffic can incur an additional cost in
running such tests (e.g., the implications of capacity tests in a running such tests (e.g., the implications of capacity tests in a
mobile network are obvious). Some active measurements [RFC7799] mobile network are obvious). Some active measurements [RFC7799]
(e.g., response under load or particular workloads) perturb other (e.g., response under load or particular workloads) perturb other
traffic, and could require dedicated access to the network segment. traffic, and could require dedicated access to the network segment.
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.3.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.
One alternative approach is to use in-network techniques, which does One alternative approach is to use in-network techniques, which does
not require the cooperation of an endpoint (see Section 5). not require the cooperation of an endpoint (see Section 5).
3.1.3. Transport use of Network Layer Header Fields 3.2.2. Using Information Derived from Network Layer Header Fields
Information from the transport header is used by a multi-field Information from the transport header can be 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, or by firewalls to implement access rules (see
also Section 2.2.2 of [RFC8404]). Network-layer classification also Section 2.2.2 of [RFC8404]). Operators can use such policies to
methods that rely on a multi-field classifier (e.g., inferring QoS support user applications and to protect against unwanted traffic.
from the 5-tuple or choice of application protocol) are incompatible Such policies can also be used without user consent, to de-prioritise
with transport protocols that encrypt the transport header certain applications or services, for example.
information. Traffic that cannot be classified typically receives a
default treatment. Network-layer classification methods that rely on a multi-field
classifier (e.g., inferring QoS from the 5-tuple or choice of
application protocol) are incompatible with transport protocols that
encrypt the transport header information. Traffic that cannot be
classified typically receives a default treatment. Some networks
block or rate traffic that cannot be classified.
Transport layer information can also be explicitly carried in Transport layer information can also be explicitly carried in
network-layer header fields that are not encrypted, serving as a network-layer header fields that are not encrypted, serving as a
replacement/addition to the exposed transport header information replacement/addition to the exposed transport header information
[RFC8558]. This information can enable a different forwarding [RFC8558]. This information can enable a different forwarding
treatment by the network, even when a transport employs encryption to treatment by the network, even when a transport employs encryption to
protect other header information. protect other header information.
The user of a transport that multiplexes multiple sub-flows might The user of a transport that multiplexes multiple sub-flows might
want to obscure the presence and characteristics of these sub-flows. want to obscure the presence and characteristics of these sub-flows.
On the other hand, an encrypted transport could set the network-layer On the other hand, an encrypted transport could set the network-layer
information to indicate the presence of sub-flows, and to reflect the information to indicate the presence of sub-flows, and to reflect the
service requirements of individual sub-flows. There are several ways service requirements of individual sub-flows. There are several ways
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 affect 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],
[RFC6437][RFC6438]) encourage endpoints to set the IPv6 flow label [RFC6438]) encourage endpoints to set the IPv6 flow label field of
field of the network-layer header. IPv6 "source nodes SHOULD the network-layer header. IPv6 "source nodes SHOULD assign each
assign each unrelated transport connection and application data unrelated transport connection and application data stream to a
stream to a new flow" [RFC6437]. A multiplexing transport could new flow" [RFC6437]. A multiplexing transport could choose to use
choose to use multiple flow labels to allow the network to multiple flow labels to allow the network to independently forward
independently forward sub-flows. RFC6437 provides further sub-flows. RFC6437 provides further guidance on choosing a flow
guidance on choosing a flow label value, stating these "should be label value, stating these "should be chosen such that their bits
chosen such that their bits exhibit a high degree of variability", exhibit a high degree of variability", and chosen so that "third
and chosen so that "third parties should be unlikely to be able to parties should be unlikely to be able to guess the next value that
guess the next value that a source of flow labels will choose". 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
skipping to change at page 20, line 5 skipping to change at page 20, line 38
AQM and ECN offer a range of algorithms and configuration options. AQM and ECN offer a range of algorithms and configuration options.
Tools therefore have to be available to network operators and Tools therefore have to be available to network operators and
researchers to understand the implication of configuration choices researchers to understand the implication of configuration choices
and transport behaviour as the use of ECN increases and new and transport behaviour as the use of ECN increases and new
methods emerge [RFC7567]. methods emerge [RFC7567].
Network-Layer Options Network protocols can carry optional headers. Network-Layer Options Network protocols can carry optional headers.
These can be used to explicitly expose transport header These can be used to explicitly expose transport header
information to on-path devices operating at the network layer (as information to on-path devices operating at the network layer (as
discussed further inSection 5). discussed further in Section 5).
IPv4 [RFC0791] has provision for optional header fields identified IPv4 [RFC0791] has provision for optional header fields identified
by an option type field. IP routers can examine these headers and by an option type field. IP routers can examine these headers and
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]. BCP 186 [RFC7126] provides Best Current
guidance on how operators should treat IPv4 packets that specify Practice guidance on how operators should treat IPv4 packets that
options. specify 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 6 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.3. To Support Network Operations
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.
When encryption hides more layers in each packet, people seeking When encryption hides more layers in each packet, people seeking
understanding of the network operation rely more on pattern inference understanding of the network operation rely more on pattern inference
and other heuristics. It remains to be seen whether more complex and other heuristics. It remains to be seen whether more complex
skipping to change at page 21, line 19 skipping to change at page 22, line 5
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, but 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.3.1. Problem Location
On-path measurements are particularly useful for locating the source In network measurements of transport header information can be used
of problems, or to assess the performance of a network segment or a to locate the source of problems, or to assess the performance of a
particular device configuration. Often issues can only be understood network segment or a particular device configuration. Often issues
in the context of the other flows that share a particular path, can only be understood in the context of the other flows that share a
common network device, interface port, etc. A simple example is particular path, common network device, interface port, etc. A
monitoring of a network device that uses a scheduler or active queue simple example is monitoring of a network device that uses a
management technique [RFC7567], where it could be desirable to scheduler or active queue management technique [RFC7567], where it
understand whether the algorithms are correctly controlling latency, could be desirable to understand whether the algorithms are correctly
or if overload protection is working. This understanding implies controlling latency, or if overload protection is working. This
knowledge of how traffic is assigned to any sub-queues used for flow understanding implies knowledge of how traffic is assigned to any
scheduling, but can also require information about how the traffic sub-queues used for flow scheduling, but can also require information
dynamics impact active queue management, starvation prevention about how the traffic dynamics impact active queue management,
mechanisms, and circuit-breakers. starvation prevention mechanisms, and circuit-breakers.
Sometimes multiple on-path observation points have to be used. By Sometimes multiple in network observation points have to be used. By
correlating observations of headers at multiple points along the path correlating observations of headers at multiple points along the path
(e.g., at the ingress and egress of a network segment), an observer (e.g., at the ingress and egress of a network segment), an observer
can determine the contribution of a portion of the path to an can determine the contribution of a portion of the path to an
observed metric, to locate a source of delay, jitter, loss, observed metric, to locate a source of delay, jitter, loss,
reordering, congestion marking, etc. reordering, congestion marking, etc.
3.2.2. Use by Operators to Plan and Provision Networks 3.3.2. Network Planning and Provisioning
Traffic rate and volume measurements are used by operators to help Traffic rate and volume measurements are used by operators to help
plan deployment of new equipment and configuration in their networks. plan deployment of new equipment and configuration in their networks.
Data is also valuable to equipment vendors who want to understand Data is also valuable to equipment vendors who want to understand
traffic trends and patterns of usage as inputs to decisions about traffic trends and patterns of usage as inputs to decisions about
planning products and provisioning for new deployments. This planning products and provisioning for new deployments. This
measurement information can also be correlated with billing measurement information can also be correlated with billing
information when this is also collected by an operator. information when this is also collected by an operator.
Trends in aggregate traffic can be observed and can be related to the Trends in aggregate traffic can be observed and can be related to the
endpoint addresses being used, but when transport header information endpoint addresses being used, but when transport header information
is not observable, it might be impossible to correlate patterns in is not observable, it might be impossible to correlate patterns in
measurements with changes in transport protocols. This increases the measurements with changes in transport protocols. This increases the
dependency on other indirect sources of information to inform dependency on other indirect sources of information to inform
planning and provisioning. planning and provisioning.
3.2.3. Service Performance Measurement 3.3.3. Service Performance Measurement
Performance measurements (e.g., throughput, loss, latency) can be Performance measurements (e.g., throughput, loss, latency) can be
used by various actors to analyse the service offered to the users of used by various actors to analyse the service offered to the users of
a network segment, and to inform operational practice. a network segment, and to inform operational practice.
3.2.4. Measuring Transport to Support Network Operations 3.3.4. Compliance with Congestion Control
The traffic that can be observed by on-path network devices (the The traffic that can be observed by on-path network devices (the
"wire image") is a function of transport protocol design/options, "wire image") is a function of transport protocol design/options,
network use, applications, and user characteristics. In general, network use, applications, and user characteristics. In general,
when only a small proportion of the traffic has a specific when only a small proportion of the traffic has a specific
(different) characteristic, such traffic seldom leads to operational (different) characteristic, such traffic seldom leads to operational
concern, although the ability to measure and monitor it is less. The concern, although the ability to measure and monitor it is less. The
desire to understand the traffic and protocol interactions typically desire to understand the traffic and protocol interactions typically
grows as the proportion of traffic increases in volume. The grows as the proportion of traffic increases in volume. The
challenges increase when multiple instances of an evolving protocol challenges increase when multiple instances of an evolving protocol
skipping to change at page 23, line 45 skipping to change at page 24, line 31
A network operator can observe the headers of transport protocols A network operator can observe the headers of transport protocols
layered above UDP to understand if the datagram flows comply with layered above UDP to understand if the datagram flows comply with
congestion control expectations. This can help inform a decision congestion control expectations. This can help inform a decision
on whether it might be appropriate to deploy methods such as rate- on whether it might be appropriate to deploy methods such as rate-
limiters to enforce acceptable usage. limiters to enforce acceptable usage.
UDP flows that expose a well-known header can be observed to gain UDP flows that expose a well-known header can be observed to gain
understanding of the dynamics of a flow and its congestion control understanding of the dynamics of a flow and its congestion control
behaviour. For example, tools exist to monitor various aspects of behaviour. For example, tools exist to monitor various aspects of
RTP header information and RTCP reports for real-time flows (see RTP header information and RTCP reports for real-time flows (see
Section 3.1.2). The Secure RTP and RTCP extensions [RFC3711] were Section 3.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.4. To Support 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 DoS), and responding to user performance questions. (including DoS), and responding to user performance questions.
Section 3.1.2 and Section 5 of [RFC8404] provide further examples. Section 3.1.2 and Section 5 of [RFC8404] provide further 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
skipping to change at page 24, line 37 skipping to change at page 25, line 19
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 measurements would need to be carefully designed to provide
information 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 Wireless LAN (WLAN), satellite access/back-haul,
radio) has the complexity of a subsystem that performs radio resource point-to-point radio) has the complexity of a subsystem that performs
management, with direct impact on the available capacity, and radio resource management, with direct impact on the available
potentially loss/reordering of packets. The impact of the pattern of capacity, and potentially loss/reordering of packets. The impact of
loss and congestion, differs for different traffic types, correlation the pattern of loss and congestion, differs for different traffic
with propagation and interference can all have significant impact on types, correlation with propagation and interference can all have
the cost and performance of a provided service. For radio links, the significant impact on the cost and performance of a provided service.
use for this type of information is expected to increase as operators For radio links, the use for this type of information is expected to
bring together heterogeneous types of network equipment and seek to increase as operators bring together heterogeneous types of network
deploy opportunistic methods to access radio spectrum. equipment and seek to deploy opportunistic methods to access radio
spectrum.
Lack of tools and resulting information can reduce the ability of an Lack of tools and resulting information can reduce the ability of an
operator to observe transport performance and could limit the ability operator to observe transport performance and could limit the ability
of network operators to trace problems, make appropriate QoS of network operators to trace problems, make appropriate QoS
decisions, or respond to other queries about the network service. decisions, or respond to other queries about the network service.
A network operator supporting traffic that uses transport header A network operator supporting traffic that uses transport header
encryption is unable to use tools that rely on transport protocol encryption is unable to use tools that rely on transport protocol
information. However, the use of encryption has the desirable effect information. However, the use of encryption has the desirable effect
of preventing unintended observation of the payload data and these of preventing unintended observation of the payload data and these
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.5. To Support 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. Examples on wireless links that are subject to capacity constraints. Examples
of header compression include use with TCP/IP and RTP/UDP/IP flows of header compression include use with TCP/IP and RTP/UDP/IP 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
skipping to change at page 30, line 10 skipping to change at page 30, line 39
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 can be independently of the transport protocol functionality. This can be
done by exposing part of the transport header or as a network layer done by exposing part of the transport header or as a network layer
option/extension. 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.2.2). 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 Network-layer optional headers explicitly indicate the information
that is exposed, whereas use of exposed transport header information that is exposed, whereas use of exposed transport header information
first requires an observer to identify the transport protocol and its first requires an observer to identify the transport protocol and its
format. See Section 3.1.1 for further discussion of transport format. See Section 3.1 for further discussion of transport protocol
protocol identification. 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
skipping to change at page 34, line 4 skipping to change at page 34, line 35
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 DoS attacks against the could also have to be collected to manage DoS attacks 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.3.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
(firewalls, etc.) to seek other methods to classify, and potentially (firewalls, etc.) to seek other methods to classify, and potentially
other mechanisms to condition, network traffic. other mechanisms to condition, network traffic.
A lack of data that reduces the level of precision with which flows A lack of data that reduces the level of precision with which flows
can be classified also reduces the design space for conditioning can be classified also reduces the design space for conditioning
mechanisms (e.g., rate limiting, circuit breaker techniques mechanisms (e.g., rate limiting, circuit breaker techniques
skipping to change at page 37, line 45 skipping to change at page 38, line 27
header format (wire image) or their transport behaviour, this can header format (wire image) or their transport behaviour, this can
result in the currently deployed tools and methods becoming no result in the currently deployed tools and methods becoming no
longer relevant. Where this needs to be accompanied by longer relevant. Where this needs to be accompanied by
development of appropriate operational support functions and development of appropriate operational support functions and
procedures, it can incur a cost in new tooling to catch-up with procedures, it can incur a cost in new tooling to catch-up with
each change. Protocols that consistently expose observable data each change. Protocols that consistently expose observable data
do not require such development, but can suffer from ossification do not require such development, but can suffer from ossification
and need to consider if the exposed protocol metadata has privacy and need to consider if the exposed protocol metadata has privacy
implications, There is no single deployment context, and therefore implications, There is no single deployment context, and therefore
designers need to consider the diversity of operational networks designers need to consider the diversity of operational networks
(ISPs, enterprises, DDoS mitigation and firewall maintainers, (ISPs, enterprises, Distributed DoS (DDoS) mitigation and firewall
etc.). maintainers, etc.).
o Supporting Common Specifications: Common, open, specifications can o Supporting Common Specifications: Common, open, specifications can
stimulate engagement by developers, users, researchers, and the stimulate engagement by developers, users, researchers, and the
broader community. Increased protocol diversity can be beneficial broader community. Increased protocol diversity can be beneficial
in meeting new requirements, but the ability to innovate without in meeting new requirements, but the ability to innovate without
public scrutiny risks point solutions that optimise for specific public scrutiny risks point solutions that optimise for specific
cases, but that can accidentally disrupt operations of/in cases, but that can accidentally disrupt operations of/in
different parts of the network. The social contract that different parts of the network. The social contract that
maintains the stability of the Internet relies on accepting common maintains the stability of the Internet relies on accepting common
interworking specifications, and on it being possible to detect interworking specifications, and on it being possible to detect
skipping to change at page 40, line 51 skipping to change at page 41, line 36
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).
One mitigation to off-path attack is to deny knowledge of what header One mitigation to off-path attack is to deny knowledge of what header
information is accepted by a receiver or obfuscate the accepted information is accepted by a receiver or obfuscate the accepted
header information, e.g., setting a non-predictable initial value for header information, e.g., setting a non-predictable initial value for
a sequence number during a protocol handshake, as in [RFC3550] and a sequence number during a protocol handshake, as in [RFC3550] and
[RFC6056], or a port value that can not be predicted (see Section 5.1 [RFC6056], or a port value that cannot be predicted (see Section 5.1
of [RFC8085]). A receiver could also require additional information of [RFC8085]). A receiver could also require additional information
to be used as a part of a validation check before accepting packets to be used as a part of a validation check before accepting packets
at the transport layer (e.g., utilising a part of the sequence number at the transport layer (e.g., utilising a part of the sequence number
space that is encrypted; or by verifying an encrypted token not space that is encrypted; or by verifying an encrypted token not
visible to an attacker). This would also mitigate against on-path visible to an attacker). This would also mitigate against on-path
attacks. An additional processing cost can be incurred when attacks. An additional processing cost can be incurred when
decryption has to be attempted before a receiver is able to discard decryption has to be attempted before a receiver is able to discard
injected packets. injected packets.
Open standards motivate a desire for this evaluation to include Open standards motivate a desire for this evaluation to include
skipping to change at page 41, line 42 skipping to change at page 42, line 28
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, Mohamed Boucadair, Martin Thomson, David Black,
of TSVWG for their comments and feedback. and other members 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 42, line 38 skipping to change at page 43, line 28
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-19 Browser-based Applications", draft-ietf-rtcweb-overview-19
(work in progress), November 2017. (work in progress), November 2017.
[I-D.ietf-taps-transport-security] [I-D.ietf-taps-transport-security]
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K.
Rose, "A Survey of Transport Security Protocols", draft- Rose, "A Survey of Transport Security Protocols", draft-
ietf-taps-transport-security-08 (work in progress), August ietf-taps-transport-security-08 (work in progress), August
2019. 2019.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May
2020.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016. qos-18 (work in progress), August 2016.
[I-D.trammell-plus-abstract-mech] [I-D.trammell-plus-abstract-mech]
Trammell, B., "Abstract Mechanisms for a Cooperative Path Trammell, B., "Abstract Mechanisms for a Cooperative Path
Layer under Endpoint Control", draft-trammell-plus- Layer under Endpoint Control", draft-trammell-plus-
abstract-mech-00 (work in progress), September 2016. abstract-mech-00 (work in progress), September 2016.
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of
Techniques and Their Merits, IEEE Comm. Surveys & Techniques and Their Merits, IEEE Comm. Surveys &
Tutorials. 26;18(3) p2149-2196", November 2014. Tutorials. 26;18(3) p2149-2196", November 2014.
[Measurement] [Measurement]
Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement-
based Protocol Design, Eur. Conf. on Networks and based Protocol Design, Eur. Conf. on Networks and
Communications, Oulu, Finland.", June 2017. Communications, Oulu, Finland.", June 2017.
[PAM-RTT] Trammell, B. and M. Kuehlewind, "Revisiting the Privacy
Implications of Two-Way Internet Latency Data (in Proc.
PAM 2018)", March 2018.
[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 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
skipping to change at page 44, line 48 skipping to change at page 45, line 48
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
DOI 10.17487/RFC4737, November 2006, DOI 10.17487/RFC4737, November 2006,
<https://www.rfc-editor.org/info/rfc4737>. <https://www.rfc-editor.org/info/rfc4737>.
skipping to change at page 45, line 24 skipping to change at page 46, line 30
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R.
Whitner, "Improved Packet Reordering Metrics", RFC 5236, Whitner, "Improved Packet Reordering Metrics", RFC 5236,
DOI 10.17487/RFC5236, June 2008, DOI 10.17487/RFC5236, June 2008,
<https://www.rfc-editor.org/info/rfc5236>. <https://www.rfc-editor.org/info/rfc5236>.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, DOI 10.17487/RFC5426, March 2009,
<https://www.rfc-editor.org/info/rfc5426>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/info/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010, DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>. <https://www.rfc-editor.org/info/rfc5795>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
skipping to change at page 46, line 19 skipping to change at page 47, line 28
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[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 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
skipping to change at page 50, line 5 skipping to change at page 50, line 29
[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",
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
Appendix A. Revision information Appendix A. Revision information
-00 This is an individual draft for the IETF community. -00 This is an individual draft for the IETF community.
-01 This draft was a result of walking away from the text for a few -01 This draft was a result of walking away from the text for a few
days and then reorganising the content. days and then reorganising the content.
-02 This draft fixes textual errors. -02 This draft fixes textual errors.
-03 This draft follows feedback from people reading this draft. -03 This draft follows feedback from people reading this draft.
skipping to change at page 52, line 27 skipping to change at page 53, line 27
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 -15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins
and M. Duke. Update to add reference to RFC7605. Clarify a focus and M. Duke. Update to add reference to RFC7605. Clarify a focus
on immutable transport fields, rather than modifying middleboxes with on immutable transport fields, rather than modifying middleboxes with
Tom H. Clarified Header Compression discusion only provides a list Tom H. Clarified Header Compression discusion only provides a list
of examples of HC methods for transport. Clarified port usage with of examples of HC methods for transport. Clarified port usage with
Tom H/Joe T. Removed some duplicated sentences, and minor edits. Tom H/Joe T. Removed some duplicated sentences, and minor edits.
Added NULL-ESP. Improved after initial feedback from Martin Duke. Added NULL-ESP. Improved after initial feedback from Martin Duke.
-16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3.
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. 77 change blocks. 
238 lines changed or deleted 314 lines changed or added

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