draft-ietf-tsvwg-transport-encrypt-17.txt   draft-ietf-tsvwg-transport-encrypt-18.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: March 12, 2021 University of Glasgow Expires: May 6, 2021 University of Glasgow
September 08, 2020 November 2, 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-17 draft-ietf-tsvwg-transport-encrypt-18
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, mitigate attacks against the transport
communication. Current operational practice in some networks inspect protocol, and protect metadata about the communication. Current
transport header information within the network, but this is no operational practice in some networks inspect transport header
longer possible when those transport headers are encrypted. information within the network, but this is no longer possible when
those transport headers are encrypted.
This document discusses the possible impact when network traffic uses This document discusses the possible impact when network traffic uses
a protocol with an encrypted transport header. It suggests issues to 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.
considerations arise from concerns such as network operations,
prevention of network ossification, enabling transport protocol
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 March 12, 2021. This Internet-Draft will expire on May 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 2. Current uses of Transport Headers within the Network . . . . 4
2.1. Use of Transport Header Information in the Network . . . 6 2.1. To Identify Transport Protocols and Flows . . . . . . . . 5
2.2. Authentication of Transport Header Information . . . . . 8 2.2. To Understand Transport Protocol Performance . . . . . . 6
2.3. Perspectives on Observable Transport Header Fields . . . 8 2.3. To Support Network Operations . . . . . . . . . . . . . . 13
3. Current uses of Transport Headers within the Network . . . . 12 2.4. To Support Network Diagnostics and Troubleshooting . . . 16
3.1. To Identify Transport Protocols and Flows . . . . . . . . 13 2.5. To Support Header Compression . . . . . . . . . . . . . . 17
3.2. To Understand Transport Protocol Performance . . . . . . 14 2.6. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18
3.3. To Support Network Operations . . . . . . . . . . . . . . 21 3. Other Uses of Observable Transport Headers . . . . . . . . . 18
3.4. To Support Network Diagnostics and Troubleshooting . . . 24 3.1. Characterising "Unknown" Network Traffic . . . . . . . . 19
3.5. To Support Header Compression . . . . . . . . . . . . . . 25 3.2. Accountability and Internet Transport Protocols . . . . . 19
4. Encryption and Authentication of Transport Headers . . . . . 26 3.3. Impact on Tooling and Network Operations . . . . . . . . 20
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 26 3.4. Independent Measurement . . . . . . . . . . . . . . . . . 20
4.2. Approaches to Transport Header Protection . . . . . . . . 27 3.5. Impact on Research, Development and Deployment . . . . . 22
5. Addition of Transport OAM Information to Network-Layer 4. Encryption and Authentication of Transport Headers . . . . . 23
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 29 4.2. Approaches to Transport Header Protection . . . . . . . . 26
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29 5. Intentionally Exposing Transport Information to the Network . 28
6. Intentionally Exposing Transport Information to the Network . 30 5.1. Exposing Transport Information in Extension Headers . . . 28
6.1. Exposing Transport Information in Extension Headers . . . 30 5.2. Common Exposed Transport Information . . . . . . . . . . 29
6.2. Common Exposed Transport Information . . . . . . . . . . 31 5.3. Considerations for Exposing Transport Information . . . . 29
6.3. Considerations for Exposing Transport Information . . . . 31 6. Addition of Transport OAM Information to Network-Layer
7. Implications of Protecting the Transport Headers . . . . . . 31 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Independent Measurement . . . . . . . . . . . . . . . . . 32 6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 30
7.2. Characterising "Unknown" Network Traffic . . . . . . . . 34 6.2. Use of OAM across Multiple Maintenance Domains . . . . . 30
7.3. Accountability and Internet Transport Protocols . . . . . 34 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4. Impact on Network Operations . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.5. Impact on Research, Development and Deployment . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Informative References . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Revision information . . . . . . . . . . . . . . . . 45
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
12. Informative References . . . . . . . . . . . . . . . . . . . 42
Appendix A. Revision information . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Transport protocols have supported end-to-end encryption of payload The transport layer supports the end-to-end flow of data across a
data for many years. Examples include Transport Layer Security (TLS) network path, providing features such as connection establishment,
over TCP [RFC8446], Datagram TLS [RFC6347][I-D.ietf-tls-dtls13], reliability, framing, ordering, congestion control, flow control,
Secure Real-time Transport Protocol (SRTP) [RFC3711], and tcpcrypt etc., as needed to support applications. One of the core functions
[RFC8548]. Some of these specifications also provide integrity of an Internet transport: to discover and adapt to the
protection of all, or part, of the transport header. characteristics of the network path that is currently being used.
This end-to-end transport payload encryption brings many benefits in
terms of providing confidentiality and protecting user privacy. The
benefits have been widely discussed, for example in [RFC7624]. This
document supports and encourages increased use of end-to-end payload
encryption in transport protocols. The implications of protecting
the transport payload data are therefore not further discussed in
this document.
A further level of protection can be achieved by encrypting the
entire network layer payload, including both the transport headers
and the transport payload data. This does not expose any transport
header information to devices in the network, and therefore also
prevents modification along a network path. An example of encryption
at the network layer is the IPsec Encapsulating Security Payload
(ESP) [RFC4303] in tunnel mode. Virtual Private Networks (VPNs)
typically also operate in this way. This form of encryption is not
further discussed in this document.
There is also a middle ground, comprising transport protocols that
encrypt some, or all, of the transport layer header information, in
addition to encrypting the transport payload data. An example of
such a protocol, that is now seeing widespread interest and
deployment, is the QUIC transport protocol [I-D.ietf-quic-transport].
The encryption and authentication of transport header information can
prevent unwanted modification of transport header information by
network devices, reducing the risk of protocol ossification. It also
reduces the amount of metadata about the progress of the transport
connection that is visible to the network [RFC8558].
In this document, the term "transport header information" is used to For some years, it has been common for the transport layer payload to
describe transport layer information concerning the operation of the be protected by encryption and authentication, but for the transport
transport protocol (i.e., information used by the transport protocol layer headers to be sent unprotected. Examples of protocols that
that might be carried in a protocol header). This does not refer to behave in this manner include Transport Layer Security (TLS) over TCP
transport payload data (i.e., information transferred by the [RFC8446], Datagram TLS [RFC6347] [I-D.ietf-tls-dtls13], the Secure
transport service), which itself could be encrypted. Real-time Transport Protocol [RFC3711], and tcpcrypt [RFC8548]. The
use of unencrypted transport headers has led some network operators,
researchers, and others to develop tools and processes that rely on
observations of transport headers both in aggregate and at the flow
level to infer details of the network's behaviour and inform
operational practice.
The direction in which the use of transport header encryption evolves Transport protocols are now being developed that encrypt some or all
could have significant implications on the way the Internet of the transport headers, in addition to the transport payload data.
architecture develops, and therefore needs to be considered as a part The QUIC transport protocol [I-D.ietf-quic-transport] is an example
of protocol design and evolution. This includes considering whether of such a protocol. Such transport header encryption makes it
the endpoints permit (or are able to permit) network devices to difficult to observe transport protocol behaviour within the network.
observe specific information by explicitly exposing a transport This document discusses some implications of transport header
header field (or a field derived from transport header information) encryption for network operators, researchers, and others that have
to the network; whether it is intended that a network device can previously observed transport headers, and highlights some issues to
modify a transport header field; and whether any modification along consider for transport protocol designers.
the network path can be detected by the receiving endpoint. This can
require changes to network operations and other practises and could
drive changes to the design of network measurement for research,
operational, and standardisation purposes.
As discussed in [RFC7258], the IETF has concluded that Pervasive As discussed in [RFC7258], the IETF has concluded that Pervasive
Monitoring (PM) is a technical attack that needs to be mitigated in Monitoring (PM) is a technical attack that needs to be mitigated in
the design of IETF protocols, but RFC7258 also notes that "Making the design of IETF protocols. This document supports that
networks unmanageable to mitigate PM is not an acceptable outcome, conclusion. It also recognises that RFC7258 states "Making networks
but ignoring PM would go against the consensus documented here. An unmanageable to mitigate PM is not an acceptable outcome, 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". This document is written to provide input
document discusses design and deployment considerations for use of to the discussion around what is an appropriate balance, by
transport header encryption to protect against pervasive monitoring. highlighting some implications of transport header encryption.
The transport protocols developed for the Internet are used across a
wide range of paths across network segments with many different
regulatory, commercial, and engineering considerations. This
document considers some of the costs and changes to network
management and research that are implied by widespread use of
transport protocols that encrypt their transport header information.
It reviews the implications of developing transport protocols that
use end-to-end encryption to provide confidentiality of their
transport layer headers, and considers the effect of such changes on
transport protocol design, transport protocol evolution, and network
operations. It also considers some anticipated implications on
application evolution. This provides considerations relating to the
design of transport protocols and features where the transport
protocol encrypts some or all of their header information.
2. Context and Rationale
The transport layer provides end-to-end interactions between
endpoints (processes) using a network path. Transport protocols
layer over the network-layer service, and are usually sent in the
payload of network-layer packets. Transport protocols support end-
to-end communication between applications, using higher-layer
protocols running on the end systems (i.e., transport endpoints).
This simple architectural view does not present one of the core
functions of an Internet transport: to discover and adapt to the
characteristics of the network path that is currently being used.
The design of Internet transport protocols is as much about trying to
avoid the unwanted side effects of congestion on a flow and other
capacity-sharing flows, avoiding congestion collapse, adapting to
changes in the path characteristics, etc., as it is about end-to-end
feature negotiation, flow control, and optimising for performance of
a specific application.
Transport headers have end-to-end meaning, but have often been
observed by equipment within the network. Transport protocol
specifications have not tended to consider this. Designs have often
failed to:
o specify what parts of the transport header can be modified by the
network to signal to the transport, and in what way;
o indicate what parts of the transport header are intended to be
invariant across protocol versions and visible to the network;
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
[RFC7258][RFC7624], and growing awareness of the problem of protocol
ossification caused by middlebox interference with Internet traffic,
has motivated a shift in transport protocol design. For example,
transport protocols, such as QUIC [I-D.ietf-quic-transport], encrypt
the majority of their transport headers to prevent observation and
protect against modification by the network, and to make explicit
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 protocol designs. It can help to protect against pervasive
monitoring, improve privacy, and reduce protocol ossification.
Transport protocols that use header encryption with secure key
distribution can provide confidentiality and protection for some, or
all, of the transport header, controlling what is visible to, and can
be modified by the network.
The increased use of transport header encryption has benefits, but
also has implications for the broader ecosystem. The transport
community has, to date, relied on measurements and insights from the
network operations community to understand protocol behaviour, and to
inform the selection of appropriate mechanisms to ensure a safe,
reliable, and robust Internet. In turn, network operators and access
providers have relied upon being able to observe traffic patterns and
requirements, both in aggregate and at the flow level, to help
understand and optimise the behaviour of their networks.
Transport header encryption can be used to intentionally limit the
information available to network observers. The widespread use would
therefore limit such observations, unless transport protocols are
modified to selectively expose transport header information outside
of the encrypted transport header.
It is important to understand how transport header information is
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
In-network measurement of transport flow characteristics can be used
to enhance performance, control cost and improve service reliability.
To support network operations and enhance performance, some operators
have deployed functionality that utilises on-path observations of the
transport headers of packets passing through their network ([RFC8517]
gives an operator perspective on such use).
When network devices rely on the presence of a header field or the
semantics of specific header information, this can lead to
ossification where an endpoint has to supply a specific header to
receive the network service that it desires.
In some cases, network-layer use of transport layer information can
be benign or advantageous to the protocol (e.g., recognising the
start of a TCP connection, providing header compression for an SRTP
flow [RFC3711], or explicitly using exposed protocol information to
provide consistent decisions by on-path devices). Header compression
(e.g., [RFC5795], [RFC2508]) depends on understanding of transport
header and the way fields change packet-by-packet; as also do
techniques to improve TCP performance by transparent modification of
acknowledgement traffic [RFC3449]. Introducing a new transport
protocol or changes to existing transport header information prevent
these methods being used or require the network devices to be
updated.
However, in other cases, ossification can have unwanted outcomes.
Ossification can frustrate the evolution of a transport protocol. A
mechanism implemented in a network device, such as a firewall, that
requires a header field to have only a specific known set of values
can prevent the device from forwarding packets using a different
version of the protocol that introduces a feature that changes to a
new value for the observed field.
An example of this type ossification was observed in the development
of TLS 1.3 [RFC8446], where the design needed to function in the
presence of deployed middleboxes that relied on the presence of
certain header fields exposed in TLS 1.2 [RFC5426]. The design of
Multipath TCP (MPTCP) [RFC8684] also had to be revised to account for
middleboxes (known as "TCP Normalizers") that monitor the evolution
of the window advertised in the TCP header and then reset connections
when the window did not grow as expected. Similarly, issues have
been reported using TCP. For example, TCP Fast Open [RFC7413] can
experience middleboxes that modify the transport header of packets by
removing "unknown" TCP options, segments with unrecognised TCP
options can be dropped, segments that contain data and set the SYN
bit can be dropped, or middleboxes that disrupt connections that send
data before completion of the three-way handshake.
Other examples of ossification have included middleboxes that modify
transport headers by rewriting TCP sequence and acknowledgement
numbers, but are unaware of the (newer) TCP selective acknowledgement
(SACK) option and therefore fail to correctly rewrite the SACK
information to match the changes that were made to the fixed TCP
header, preventing SACK from operating correctly.
In all these cases, middleboxes with a hard-coded, but incomplete,
understanding of transport behaviour, interacted poorly with
transport protocols after the transport behaviour was changed. In
some case, the middleboxes modified or replaced information in the
transport protocol header.
Transport header encryption prevents an on-path device from observing
the transport headers, and therefore stops mechanisms being built
that directly rely on or infer semantics of the transport header
information. Encryption is normally combined with authentication of
the protected information. RFC 8546 summarises this approach,
stating that it is "The wire image, not the protocol's specification,
determines how third parties on the network paths among protocol
participants will interact with that protocol" (Section 1 of
[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,
it does not itself prevent ossification of the network service.
People seeking to understand network traffic could still come to rely
on pattern inferences and other heuristics or machine learning to
derive measurement data and as the basis for network forwarding
decisions [RFC8546]. This can also create dependencies on the
transport protocol, or the patterns of traffic it can generate, also
in time resulting in ossification of the service.
2.2. Authentication of Transport Header Information
The designers of a transport protocol have to decide whether to
encrypt all, or a part of, the transport layer information.
Section 4 of [RFC8558] states: "Anything exposed to the path should
be done with the intent that it be used by the network elements on
the path".
Protocol designers can decide not to encrypt certain transport header
fields, making those fields observable in the network, or can define
new fields designed to explicitly expose observable transport layer
information to the network. Where exposed fields are intended to be
immutable (i.e., can be observed, but not modified by a network
device), the endpoints are encouraged to use authentication to
provide a cryptographic integrity check that can detect if these
immutable fields have been modified by network devices.
Authentication can also help to prevent attacks that rely on sending
packets that fake exposed control signals in transport headers (e.g.,
TCP RST spoofing).
Making a part of a transport header observable or exposing new header
fields can lead to ossification of that part of a header as network
devices come to rely on observations of the exposed fields. A
protocol design that provides an observable field might want to
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
ossification (see Section 4).
2.3. Perspectives on Observable Transport Header Fields
Transport header fields have been observed within the network for a
variety of purposes. Some purposes are related to network management
and operations. Use cases where the network devices intentionally
modify mutable transport layer information are out of scope and are
not described further in this document. More information may be
found in other RFCs (e.g., [RFC3449], [RFC3135], [RFC8404],
[RFC8462]), and [RFC8517].
The list below provides an overview with different uses of exposed
immutable information.
Network Operations: A transport protocol with observable header
information can enable explicit measurement and
analysis of protocol performance, network
anomalies, and failure pathologies at any point
along the Internet path. In many cases, it is
important to relate observations to specific
equipment/configurations, to a specific network
segment, or sometimes to a specific protocol or
application.
When transport header information is not
observable, it cannot be used by network
operators. Some operators might work without
that information, or some might turn to more
ambitious ways to collect, estimate, or infer
this data. (Operational practises aimed at
guessing transport parameters are out of scope
for this document, and are only mentioned here to
recognise that encryption does not stop operators
from attempting to apply practises that have been
used with unencrypted transport headers.)
See also Section 3, Section 5, Section 7.4 and
Section 7.5.
Analysis of Aggregate Traffic: Observable transport headers have
been utilised to determine which transport
protocols and features are being used across a
network segment, and to measure trends in the
pattern of usage. For some use cases, end-to-end
measurements/traces are sufficient and can assist
in developing and debugging new transports and
analysing their deployment. In other uses, it is
important to relate observations to specific
equipment/configurations or particular network
segments.
This information can help anticipate the demand
for network upgrades and roll-out, or affect on-
going traffic engineering activities performed by
operators such as determining which parts of the
path contribute delay, jitter, or loss.
Tools that rely upon observing specific headers,
could fail to produce useful data when those
headers are encrypted. While this impact could,
in many cases, be small, there are scenarios
where operators have actively monitored and
supported particular services, e.g., to explore
issues relating to Quality of Service (QoS), to
perform fast re-routing of critical traffic, to
mitigate the characteristics of specific radio
links, and so on.
Troubleshooting: Observable transport headers have been utilised
by operators as a part of network troubleshooting
and diagnostics. Metrics derived from this
observed header information can help localise the
network segment introducing the loss or latency.
Effective troubleshooting often requires
understanding of transport behaviour. Flows
experiencing packet loss or jitter are hard to
distinguish from unaffected flows when only
observing network layer headers.
Observable transport feedback information (e.g.,
RTP Control Protocol (RTCP) reception reports
[RFC3550]) can explicitly make loss metrics
visible to operators. Loss metrics can also be
deduced with more complexity from other header
information (e.g., by observing TCP SACK blocks).
When the transport header information is
encrypted, explicit observable fields could also
be made available at the network or transport
layers to provide these functions. [RFC8558]
motivates the design of signals to focus on their
usage, decoupled from the internal design of the
protocol state machine. This could avoid
ossifying the protocol around the design of a
specific protocol mechanism.
See also Section 3.4 and Section 5.
Network Protection: Observable transport headers currently provide
information that is useful input to classify and
detect anomalous events, such as changes in
application behaviour or distributed DoS attacks.
Operators often seek to uniquely disambiguate
unwanted traffic.
Where flows cannot be disambiguated based on
transport header information, this could result
in less-efficient identification of unwanted
traffic, the introduction of rate limits for
uncharacterised traffic, or the use of heuristics
to identify anomalous flows.
See also Section 7.2 and Section 7.3.
Verifiable Data: Observable transport headers can be used to
provide open and verifiable measurements to
support operations, research, and protocol
development. The ability of multiple stake
holders to review transport header traces helps
develop insight into performance and traffic
contribution of specific variants of a protocol.
Independently observed data is important to help
ensure the health of the research and development
communities.
When transport header information can not be
observed, this can reduce the range of actors
that can observe data. This limits the
information sources available to the Internet
community to understand the operation of
transport protocols, reducing information to
inform design decisions and standardisation of
the new protocols/features and related
operational practises
See also Section 7.
SLA Compliance: Observable transport headers coupled with
published transport specifications allow
operators and regulators to explore the
compliance with Service Level Agreements (SLAs).
When transport header information can not be
observed, other methods have to be found to
confirm that the traffic produced conforms to the
expectations of the operator or developer.
Independently verifiable performance metrics can
be utilised to demonstrate regulatory compliance
in some jurisdictions, and as a basis for
informing design decisions. This can bring
assurance to those operating networks, often
avoiding deployment of complex techniques that
routinely monitor and manage Internet traffic
flows (e.g., avoiding the capital and operational
costs of deploying flow rate-limiting and network
circuit-breaker methods [RFC8084]).
See also Section 5 and Section 7.1 to
Section 7.4.
This analysis does not judge whether specific practises are This document explains current uses of transport header information
necessary. It is not an endorsement of any particular practice. in the network, which can be beneficial or malicious. It is written
to provide input to the discussion around what is an appropriate
balance, by highlighting some implications of transport header
encryption.
3. Current uses of Transport Headers within the Network 2. 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 can improve Applying confidentiality to transport header fields can improve
privacy, and can help to mitigate certain attacks, but can also privacy, and can help to mitigate certain attacks, but can also
affect network operations [RFC8404]. affect network operations [RFC8404].
When considering what parts of the transport headers should be When considering what parts of the transport headers should be
encrypted to provide confidentiality, and what parts should be encrypted to provide confidentiality, and what parts should be
skipping to change at page 13, line 10 skipping to change at page 5, line 5
tracking behaviour, etc. This might reveal information the parties tracking behaviour, etc. This might reveal information the parties
did not intend to be revealed. [RFC6973] aims to make designers, did not intend to be revealed. [RFC6973] aims to make designers,
implementers, and users of Internet protocols aware of privacy- implementers, and users of Internet protocols aware of privacy-
related design choices in IETF protocols. related design choices in IETF protocols.
This section does not consider intentional modification of transport This section does not consider intentional modification of transport
headers by middleboxes, such as in Network Address Translation (NAT) headers by middleboxes, such as in Network Address Translation (NAT)
or Firewalls. Common issues concerning IP address sharing are or Firewalls. Common issues concerning IP address sharing are
described in [RFC6269]. described in [RFC6269].
3.1. To Identify Transport Protocols and Flows 2.1. To Identify Transport Protocols and Flows
Information in exposed transport layer headers can be used by the Information in exposed transport layer headers can be used by the
network to identify transport protocols and flows [RFC8558]. The network to identify transport protocols and flows [RFC8558]. The
ability to identify transport protocols, flows, and sessions is a ability to identify transport protocols, flows, and sessions is a
common function performed, for example, by measurement activities, common function performed, for example, by measurement activities,
QoS classifiers, and firewalls. These functions can be beneficial, QoS classifiers, and firewalls. These functions can be beneficial,
and performed with the consent of, and in support of, the end user. and performed with the consent of, and in support of, the end user.
Alternatively, a network operator could use the same mechanisms to Alternatively, a network operator could use the same mechanisms to
support practises that are adversarial to the end user, including support practises that are adversarial to the end user, including
blocking, de-prioritising, and monitoring traffic without consent. blocking, de-prioritising, and monitoring traffic without consent.
skipping to change at page 14, line 16 skipping to change at page 6, line 11
for this document, and are only mentioned here to recognise that for this document, and are only mentioned here to recognise that
encryption does not prevent operators from attempting to apply encryption does not prevent operators from attempting to apply
practises that were used with unencrypted transport headers. practises that were used with unencrypted transport headers.
The IAB [RFC8546] have provided a summary of expected implications of The IAB [RFC8546] have provided a summary of expected implications of
increased encryption on network functions that use the observable increased encryption on network functions that use the observable
headers and describe the expected benefits of designs that explicitly headers and describe the expected benefits of designs that explicitly
declare protocol invariant header information that can be used for declare protocol invariant header information that can be used for
this purpose. this purpose.
3.2. To Understand Transport Protocol Performance 2.2. To Understand Transport Protocol Performance
Information in exposed transport layer headers can be used by the Information in exposed transport layer headers can be used by the
network to understand transport protocol performance and behaviour. network to understand transport protocol performance and behaviour.
3.2.1. Using Information Derived from Transport Layer Headers 2.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:
skipping to change at page 18, line 15 skipping to change at page 10, line 9
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.3.1). Measurements can rely on observing packet headers, Section 2.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 6).
3.2.2. Using Information Derived from Network Layer Header Fields 2.2.2. Using Information Derived from Network Layer Header Fields
Information from the transport header can be 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, or by firewalls to implement access rules (see constrained networks, or by firewalls to implement access rules (see
also Section 2.2.2 of [RFC8404]). Operators can use such policies to also Section 2.2.2 of [RFC8404]). Operators can use such policies to
support user applications and to protect against unwanted traffic. support user applications and to protect against unwanted traffic.
Such policies can also be used without user consent, to de-prioritise Such policies can also be used without user consent, to de-prioritise
certain applications or services, for example. certain applications or services, for example.
skipping to change at page 20, line 38 skipping to change at page 12, line 32
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 in Section 5). discussed further in Section 6).
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]. BCP 186 [RFC7126] provides Best Current these packets [RFC7126]. BCP 186 [RFC7126] provides Best Current
Practice guidance on how operators should treat IPv4 packets that Practice guidance on how operators should treat IPv4 packets that
specify options. specify options.
skipping to change at page 21, line 12 skipping to change at page 13, line 7
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 Careful use of the network layer features can help provide similar
use this information directly. Careful use of the network layer information in the case where the network is unable to inspect
features can help provide similar information in the case where the transport protocol headers. Section 5 describes use of network
network is unable to inspect transport protocol headers. Section 6 extension headers.
describes use of network extension headers.
3.3. To Support Network Operations 2.3. To Support Network Operations
The common language between network operators and application/content Some network operators make use of on-path observations of transport
providers/users is packet transfer performance at a layer that all headers to monitor the performance of their networks, and to support
can view and analyse. For most packets, this has been the transport network operations. Transport protocols with observable headers
layer, until the emergence of transport protocols performing header allow such operators to explicitly measurement and analyse transport
encryption, with the obvious exception of VPNs and IPsec. protocol performance, and in some cases this can help detect and
locate network problems. [RFC8517] gives an operator's perspective
about such use.
When encryption hides more layers in each packet, people seeking When encryption hides the transport headers, making it difficult to
understanding of the network operation rely more on pattern inference directly observe transport behaviour and dynamics, those seeking an
and other heuristics. It remains to be seen whether more complex understanding of network operations might learn to work without that
inferences can be mastered to produce the same monitoring accuracy information. Alternatively, they might use more limited measurements
(see Section 2.1.1 of [RFC8404]). combined with pattern inference and other heuristics to infer network
behaviour (see Section 2.1.1 of [RFC8404]). Operational practises
aimed at inferring transport parameters are out of scope for this
document, and are only mentioned here to recognise that encryption
does not necessarily stop operators from attempting to apply
practises that have been used with unencrypted transport headers.
When measurement datasets are made available by servers or client When measurement datasets are made available by servers or client
endpoints, additional metadata, such as the state of the network, is endpoints, additional metadata, such as the state of the network, is
often necessary to interpret this data to answer questions about often necessary to interpret this data to answer questions about
network performance or understand a pathology. Collecting and network performance or understand a pathology. Collecting and
coordinating such metadata is more difficult when the observation coordinating such metadata is more difficult when the observation
point is at a different location to the bottleneck/device under point is at a different location to the bottleneck or device under
evaluation [RFC7799]. evaluation [RFC7799].
Packet sampling techniques are used to scale the processing involved Packet sampling techniques are used to scale the processing involved
in observing packets on high rate links. This exports only the in observing packets on high rate links. This exports only the
packet header information of (randomly) selected packets. The packet header information of (randomly) selected packets. The
utility of these measurements depends on the type of bearer and utility of these measurements depends on the type of bearer and
number of mechanisms used by network devices. Simple routers are number of mechanisms used by network devices. Simple routers are
relatively easy to manage, 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.3.1. Problem Location 2.3.1. Problem Location
In network measurements of transport header information can be used In network measurements of transport header information can be used
to locate the source of problems, or to assess the performance of a to locate the source of problems, or to assess the performance of a
network segment or a particular device configuration. Often issues network segment or a particular device configuration. Often issues
can only be understood in the context of the other flows that share a can only be understood in the context of the other flows that share a
particular path, common network device, interface port, etc. A particular path, common network device, interface port, etc. A
simple example is monitoring of a network device that uses a simple example is monitoring of a network device that uses a
scheduler or active queue management technique [RFC7567], where it scheduler or active queue management technique [RFC7567], where it
could be desirable to understand whether the algorithms are correctly could be desirable to understand whether the algorithms are correctly
controlling latency, or if overload protection is working. This controlling latency, or if overload protection is working. This
skipping to change at page 22, line 28 skipping to change at page 14, line 28
about how the traffic dynamics impact active queue management, about how the traffic dynamics impact active queue management,
starvation prevention mechanisms, and circuit-breakers. starvation prevention mechanisms, and circuit-breakers.
Sometimes multiple in network 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.3.2. Network Planning and Provisioning 2.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.3.3. Service Performance Measurement 2.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.3.4. Compliance with Congestion Control 2.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 lower.
desire to understand the traffic and protocol interactions typically The desire to understand the traffic and protocol interactions
grows as the proportion of traffic increases in volume. The typically grows as the proportion of traffic increases in volume.
challenges increase when multiple instances of an evolving protocol The challenges increase when multiple instances of an evolving
contribute to the traffic that share network capacity. protocol contribute to the traffic that share network capacity.
Operators can manage traffic load (e.g., when the network is severely Operators can manage traffic load (e.g., when the network is severely
overloaded) by deploying rate-limiters, traffic shaping, or network overloaded) by deploying rate-limiters, traffic shaping, or network
transport circuit breakers [RFC8084]. The information provided by transport circuit breakers [RFC8084]. The information provided by
observing transport headers is a source of data that can help to observing transport headers is a source of data that can help to
inform such mechanisms. inform such mechanisms.
Congestion Control Compliance of Traffic: Congestion control is a Congestion Control Compliance of Traffic: Congestion control is a
key transport function [RFC2914]. Many network operators key transport function [RFC2914]. Many network operators
implicitly accept that TCP traffic complies with a behaviour that implicitly accept that TCP traffic complies with a behaviour that
skipping to change at page 24, line 31 skipping to change at page 16, 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.2). The Secure RTP and RTCP extensions [RFC3711] were Section 2.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.4. To Support Network Diagnostics and Troubleshooting 2.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 25, line 23 skipping to change at page 17, line 23
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 Wireless LAN (WLAN), satellite access/back-haul, mobile, enterprise Wireless LAN (WLAN), satellite access/back-haul,
point-to-point radio) has the complexity of a subsystem that performs point-to-point radio) has the complexity of a subsystem that performs
radio resource management, with direct impact on the available radio resource management, with direct impact on the available
capacity, and potentially loss/reordering of packets. The impact of capacity, and potentially loss/reordering of packets. The impact of
the pattern of loss and congestion, differs for different traffic the pattern of loss and congestion and differences between traffic
types, correlation with propagation and interference can all have types, and their correlation with link propagation and interference
significant impact on the cost and performance of a provided service. can all have significant impact on the cost and performance of a
For radio links, the use for this type of information is expected to provided service. For radio links, the use for this type of
increase as operators bring together heterogeneous types of network information is expected to increase as operators bring together
equipment and seek to deploy opportunistic methods to access radio heterogeneous types of network equipment and seek to deploy
spectrum. 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.5. To Support Header Compression 2.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 (e.g., [RFC5795]). It transport protocol headers on a per-hop basis. It was widely used
was widely used with low bandwidth dial-up access links, and still with low bandwidth dial-up access links, and still finds application
finds application on wireless links that are subject to capacity on wireless links that are subject to capacity constraints. Examples
constraints. Examples of header compression include use with TCP/IP of header compression include use with TCP/IP and RTP/UDP/IP flows
and RTP/UDP/IP flows [RFC2507], [RFC6846], [RFC2508].
While it is possible to compress only the network layer headers, [RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful compression
significant savings can be made if both the network and transport depends on observing the transport headers and understanding of the
layer headers are compressed together as a single unit. The SRTP way header fields change packet-by-packet, and is hence incompatible
extensions [RFC3711] were explicitly designed to leave the transport with header encryption. Devices that compress transport headers are
protocol headers unencrypted, but authenticated, since support for dependent on a stable header format, implying ossification of that
header compression was considered important. Encrypting the format.
transport protocol headers does not break such header compression,
but does cause a fall back to compressing only the network layer Introducing a new transport protocol, or changing the format of the
headers, with a significant reduction in efficiency. transport header information, will limit the effectiveness of header
compression until the network devices are updated. Encrypting the
transport protocol headers will tend to cause the header compression
to a fall back to compressing only the network layer headers, with a
significant reduction in efficiency. This can limit connectivity if
the resulting flow exceeds the link capacity, or if the packets are
dropped because they exceed the link MTU.
The Secure RTP (SRTP) extensions [RFC3711] were explicitly designed
to leave the transport protocol headers unencrypted, but
authenticated, since support for header compression was considered
important.
2.6. To Verify SLA Compliance
Observable transport headers coupled with published transport
specifications allow operators and regulators to explore and verify
compliance with Service Level Agreements (SLAs).
When transport header information cannot be observed, other methods
have to be found to confirm that the traffic produced conforms to the
expectations of the operator or developer.
Independently verifiable performance metrics can be utilised to
demonstrate regulatory compliance in some jurisdictions, and as a
basis for informing design decisions. This can bring assurance to
those operating networks, often avoiding deployment of complex
techniques that routinely monitor and manage Internet traffic flows
(e.g., avoiding the capital and operational costs of deploying flow
rate-limiting and network circuit-breaker methods [RFC8084]).
3. Other Uses of Observable Transport Headers
The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to
expose only what is needed [RFC3552]. This approach provides
incentives to not reveal any information that is not necessary for
the end-to-end communication. The IAB has provided guidelines for
writing Security Considerations for IETF specifications [RFC3552].
Endpoint design choices impacting privacy also need to be considered
as a part of the design process [RFC6973]. The IAB has provided
guidance for analyzing and documenting privacy considerations within
IETF specifications [RFC6973].
There can also be performance and operational trade-offs in exposing
selected information to network tools. This section explores key
implications of working with encrypted transport protocols, but does
not endorse or condemn these practices.
3.1. Characterising "Unknown" Network Traffic
The patterns and types of traffic that share Internet capacity change
over time as networked applications, usage patterns and protocols
continue to evolve.
If "unknown" or "uncharacterised" traffic patterns form a small part
of the traffic aggregate passing through a network device or segment
of the network the path, the dynamics of the uncharacterised traffic
might not have a significant collateral impact on the performance of
other traffic that shares this network segment. Once the proportion
of this traffic increases, monitoring the traffic can determine if
appropriate safety measures have to be put in place.
Tracking the impact of new mechanisms and protocols requires traffic
volume to be measured and new transport behaviours to be identified.
This is especially true of protocols operating over a UDP substrate.
The level and style of encryption has to be considered in determining
how this activity is performed. On a shorter timescale, information
could also have to be collected to manage DoS attacks against the
infrastructure.
3.2. Accountability and Internet Transport Protocols
Information provided by tools observing transport headers can be used
to classify traffic, and to limit the network capacity used by
certain flows, as discussed in Section 2.3.4). Equally, operators
could use analysis of transport headers and transport flow state to
demonstrate that they are not providing differential treatment to
certain flows. Obfuscating or hiding this information using
encryption could lead operators and maintainers of middleboxes
(firewalls, etc.) to seek other methods to classify, and potentially
other mechanisms to condition network traffic.
A lack of data that reduces the level of precision with which flows
can be classified also reduces the design space for conditioning
mechanisms (e.g., rate limiting, circuit breaker techniques
[RFC8084], or blocking of uncharacterised traffic) [RFC5218].
3.3. Impact on Tooling and Network Operations
A variety and open source and proprietary tools have been deployed to
can make use of the transport header information that's observable in
widely used protocols such as TCP or RTP/UDP/IP.
Changes to the transport, whether to protect the transport headers,
introduce a new transport protocol, protocol feature, or application
might require changes to such tools, and so could impact operational
practice and policies. Such changes have associated costs that are
incurred by the network operators that need to update their tooling
or develop alternative practises that work without access to the
changed/removed information.
If new protocols, or protocol extensions, are made to closely
resemble or match existing mechanisms, then these changes and the
associated costs can be small. Equally, more extensive changes to
the transport tend to require more extensive, and more expensive,
changes to tooling and operational practice.
Protocol designers can mitigate these costs by explicitly choosing to
expose selected information as invariants that are guaranteed not to
change for a particular protocol (e.g., the header invariants and the
spin-bit in QUIC [I-D.ietf-quic-transport]). Specification of common
log formats and development of alternative approaches can also help
mitigate the costs of transport changes.
3.4. Independent Measurement
Independent observation by multiple actors is currently used by the
transport community to maintain an accurate understanding of the
network. Encrypting transport header encryption changes the ability
to collect and independently analyse data.
Protocols that expose the state information used by the transport
protocol in their header information (e.g., timestamps used to
calculate the RTT, packet numbers used to assess congestion and
requests for retransmission) provide an incentive for the sending
endpoint to provide correct information, since the protocol will not
work otherwise. This increases confidence that the observer
understands the transport interaction with the network. For example,
when TCP is used over an unencrypted network path (i.e., one that
does not use IPsec or other encryption below the transport), it
implicitly exposes transport header information that can be used for
measurement at any point along the path. This information is
necessary for the protocol's correct operation, therefore there is no
incentive for a TCP or RTP implementation to put incorrect
information in this transport header. A network device can have
confidence that the well-known (and ossified) transport header
information represents the actual state of the endpoints.
When encryption is used to hide some or all of the transport headers,
the transport protocol chooses which information to reveal to the
network about its internal state, what information to leave
encrypted, and what fields to grease to protect against future
ossification [RFC8701]. Such a transport could provide summary data
regarding its performance, congestion control state, etc., or to make
available explicit measurement information. For example, a QUIC
endpoint can optionally set the spin bit to reflect to explicitly
reveal the RTT of an encrypted transport session to the on-path
network devices [I-D.ietf-quic-transport]).
When providing or using such information, it is important to consider
the privacy of the user and their incentive for providing accurate
and detailed information. Protocols that selectively reveal some
transport state or measurable information are choosing to establish a
trust relationship with the network operators. There is no protocol
mechanism that can guarantee that the information provided represents
the actual transport state of the endpoints, since those endpoints
can always send additional information in the encrypted part of the
header, to update or replace whatever they reveal. This reduces the
ability to independently measure and verify that a protocol is
behaving as expected. For some operational uses, the information has
to contain sufficient detail to understand, and possibly reconstruct,
the network traffic pattern for further testing. In this case,
operators have to gain the trust of transport protocol implementers
if the transport headers are to correctly reveal such information.
OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a
variety of encapsulation methods at different layers to support the
goals of a specific operational domain. OAM-related metadata can
support functions such as performance evaluation, path-tracing, path
verification information, classification and a diversity of other
uses. When encryption is used to hide some or all of the transport
headers, analysis requires coordination between actors at different
layers to successfully characterise flows and correlate the
performance or behaviour of a specific mechanism with the
configuration and traffic using operational equipment (e.g.,
combining transport and network measurements to explore congestion
control dynamics, the implications of designs for active queue
management or circuit breakers).
Some measurements could be completed by utilising endpoint-based
logging (e.g., based on Quic-Trace [Quic-Trace]). Such information
has a diversity of uses, including developers wishing to debug/
understand the transport/application protocols with which they work,
researchers seeking to spot trends and anomalies, and to characterise
variants of protocols. A standard format for endpoint logging could
allow these to be shared (after appropriate anonymisation) to
understand performance and pathologies. Measurements based on
logging have to establish the validity and provenance of the logged
information to establish how and when traces were captured.
Despite being applicable in some scenarios, endpoint logs do not
provide equivalent information to in-network measurements. In
particular, endpoint logs contain only a part of the information to
understand the operation of network devices and identify issues such
as link performance or capacity sharing between multiple flows.
Additional information has to be combined to determine which
equipment/links are used and the configuration of equipment along the
network paths being measured.
3.5. Impact on Research, Development and Deployment
Transport protocol evolution, and the ability to measure and
understand the impact of protocol changes, have to proceed hand-in-
hand. A transport protocol that provides observable headers can be
used to provide open and verifiable measurement data. Observation of
pathologies has a critical role in the design of transport protocol
mechanisms and development of new mechanisms and protocols. This
helps understanding of the interactions between cooperating protocols
and network mechanisms, the implications of sharing capacity with
other traffic and the impact of different patterns of usage. The
ability of other stakeholders to review transport header traces helps
develop insight into performance and traffic contribution of specific
variants of a protocol.
Development of new transport protocol mechanisms has to consider the
scale of deployment and the range of environments in which the
transport is used. Experience has shown that it is often difficult
to correctly implement new mechanisms [RFC8085], and that mechanisms
often evolve as a protocol matures, or in response to changes in
network conditions, changes in network traffic, or changes to
application usage. Analysis is especially valuable when based on the
behaviour experienced across a range of topologies, vendor equipment,
and traffic patterns.
New transport protocol formats are expected to facilitate an
increased pace of transport evolution, and with it the possibility to
experiment with and deploy a wide range of protocol mechanisms.
There has been recent interest in a wide range of new transport
methods, e.g., Larger Initial Window, Proportional Rate Reduction
(PRR), congestion control methods based on measuring bottleneck
bandwidth and round-trip propagation time, the introduction of AQM
techniques and new forms of ECN response (e.g., Data Centre TCP,
DCTP, and methods proposed for L4S). The growth and diversity of
applications and protocols using the Internet also continues to
expand. For each new method or application, it is desirable to build
a body of data reflecting its behaviour under a wide range of
deployment scenarios, traffic load, and interactions with other
deployed/candidate methods.
Encryption of transport header information could reduce the range of
actors that can observe useful data. This would limit the
information sources available to the Internet community to understand
the operation of new transport protocols, reducing information to
inform design decisions and standardisation of the new protocols and
related operational practises. The cooperating dependence of
network, application, and host to provide communication performance
on the Internet is uncertain when only endpoints (i.e., at user
devices and within service platforms) can observe performance, and
when performance cannot be independently verified by all parties.
Independently observed data is also important to ensure the health of
the research and development communities and can help promote
acceptance of proposed specifications by the wider community (e.g.,
as a method to judge the safety for Internet deployment) and provides
valuable input during standardisation. Open standards motivate a
desire to include independent observation and evaluation of
performance data, which in turn demands control/understanding about
where and when measurement samples are collected. This requires
consideration of the methods used to observe data and the appropriate
balance between encrypting all and no transport header information.
4. Encryption and Authentication of Transport Headers 4. Encryption and Authentication of Transport Headers
End-to-end encryption can be applied at various protocol layers. It End-to-end encryption can be applied at various protocol layers. It
can be applied above the transport to encrypt the transport payload can be applied above the transport to encrypt the transport payload
(e.g., using TLS). This can hide information from an eavesdropper in (e.g., using TLS). This can hide information from an eavesdropper in
the network. It can also help protect the privacy of a user, by the network. It can also help protect the privacy of a user, by
hiding data relating to user/device identity or location. hiding data relating to user/device identity or location. Encryption
and authentication is also increasingly used to protect the transport
headers.
4.1. Motivation 4.1. Motivation
There are several motivations for encryption: There are several motivations for transport header encryption.
o One motive to encrypt transport headers is in response to a One motive to encrypt transport headers is to prevent network
growing awareness of the implications of network ossification from ossification from network devices that inspect transport headers.
network devices that inspect transport headers. Once a network Once a network device observes a transport header and becomes reliant
devices observes a transport header and becomes reliant upon using upon using it, the overall use of that field can become ossified,
it, the overall use of that field can become ossified, preventing preventing new protocols and mechanisms from being deployed. One of
new protocols and mechanisms from being deployed. One of the the benefits of encrypting transport headers is that it can help
benefits of encrypting transport headers is that it can help improve the pace of transport development by eliminating interference
improve the pace of transport development by eliminating by deployed middleboxes. Examples of this include:
interference by deployed middleboxes.
o Another motivation stems from increased concerns about privacy and o During the development of TLS 1.3 [RFC8446], the design needed to
surveillance. Users value the ability to protect their identity be modified to function in the presence of deployed middleboxes
and location, and defend against analysis of the traffic. that relied on the presence of certain header fields exposed in
Revelations about the use of pervasive surveillance [RFC7624] TLS 1.2 [RFC5426].
have, to some extent, eroded trust in the service offered by
network operators and have led to an increased use of encryption o The design of Multipath TCP (MPTCP) [RFC8684] also had to be
to avoid unwanted eavesdropping on communications. Concerns have revised to account for middleboxes (known as "TCP Normalizers")
also been voiced about the addition of information to packets by that monitor the evolution of the window advertised in the TCP
third parties to provide analytics, customisation, advertising, header and then reset connections when the window did not grow as
cross-site tracking of users, to bill the customer, or to expected.
selectively allow or block content. Whatever the reasons, the
IETF is designing protocols that include transport header o TCP Fast Open [RFC7413] can experience problems due to middleboxes
encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement that modify the transport header of packets by removing "unknown"
the already widespread payload encryption, and to further limit TCP options, segments with unrecognised TCP options can be
exposure of transport metadata to the network. dropped, segments that contain data and set the SYN bit can be
dropped, or middleboxes that disrupt connections that send data
before completion of the three-way handshake.
o Other examples of ossification have included middleboxes that
modify transport headers by rewriting TCP sequence and
acknowledgement numbers, but are unaware of the (newer) TCP
selective acknowledgement (SACK) option and therefore fail to
correctly rewrite the SACK information to match the changes that
were made to the fixed TCP header, preventing SACK from operating
correctly.
In all these cases, middleboxes with a hard-coded, but incomplete,
understanding of transport behaviour, interacted poorly with
transport protocols after the transport behaviour was changed. In
some case, the middleboxes modified or replaced information in the
transport protocol header.
Transport header encryption prevents an on-path device from observing
the transport headers, and therefore stops mechanisms being built
that directly rely on or infer semantics of the transport header
information. Encryption is normally combined with authentication of
the protected information. RFC 8546 summarises this approach,
stating that it is "The wire image, not the protocol's specification,
determines how third parties on the network paths among protocol
participants will interact with that protocol" (Section 1 of
[RFC8546]), and it can be expected that header information that is
not encrypted will become ossified. Encryption can reduce
ossification of the transport protocol, but does not itself prevent
ossification of the network service. People seeking to understand
network traffic could still come to rely on pattern inferences and
other heuristics or machine learning to derive measurement data and
as the basis for network forwarding decisions [RFC8546]. This can
also create dependencies on the transport protocol, or the patterns
of traffic it can generate, also in time resulting in ossification of
the service.
Another motivation stems from increased concerns about privacy and
surveillance. Users value the ability to protect their identity and
location, and defend against analysis of the traffic. Revelations
about the use of pervasive surveillance [RFC7624] have, to some
extent, eroded trust in the service offered by network operators and
have led to an increased use of encryption to avoid unwanted
eavesdropping on communications. Concerns have also been voiced
about the addition of information to packets by third parties to
provide analytics, customisation, advertising, cross-site tracking of
users, to bill the customer, or to selectively allow or block
content. Whatever the reasons, the IETF is designing protocols that
include transport header encryption (e.g., QUIC
[I-D.ietf-quic-transport]) to supplement the already widespread
payload encryption, and to further limit exposure of transport
metadata to the network.
The use of transport header authentication and encryption exposes a The use of transport header authentication and encryption exposes a
tussle between middlebox vendors, operators, applications developers tussle between middlebox vendors, operators, applications developers
and users: and users:
o On the one hand, future Internet protocols that support transport o On the one hand, future Internet protocols that support transport
header encryption assist in the restoration of the end-to-end header encryption assist in the restoration of the end-to-end
nature of the Internet by returning complex processing to the nature of the Internet by returning complex processing to the
endpoints, since middleboxes cannot modify what they cannot see, endpoints, since middleboxes cannot modify what they cannot see,
and can improve privacy by reducing leakage of transport metadata. and can improve privacy by reducing leakage of transport metadata.
skipping to change at page 27, line 29 skipping to change at page 26, line 12
networks, and researchers and analysts seeking to understand the networks, and researchers and analysts seeking to understand the
dynamics of protocols and traffic patterns. dynamics of protocols and traffic patterns.
A decision to use transport header encryption can improve user A decision to use transport header encryption can improve user
privacy, and can reduce protocol ossification and help the evolution privacy, and can reduce protocol ossification and help the evolution
of the transport protocol stack, but is also has implications for of the transport protocol stack, but is also has implications for
network operations and management. network operations and management.
4.2. Approaches to Transport Header Protection 4.2. Approaches to Transport Header Protection
The designers of a transport protocol have to decide whether to
encrypt all, or a part of, the transport layer information.
Section 4 of [RFC8558] states: "Anything exposed to the path should
be done with the intent that it be used by the network elements on
the path".
Protocol designers can decide not to encrypt certain transport header
fields, making those fields observable in the network, or can define
new fields designed to explicitly expose observable transport layer
information to the network. Where exposed fields are intended to be
immutable (i.e., can be observed, but not modified by a network
device), the endpoints are encouraged to use authentication to
provide a cryptographic integrity check that can detect if these
immutable fields have been modified by network devices.
Authentication can also help to prevent attacks that rely on sending
packets that fake exposed control signals in transport headers (e.g.,
TCP RST spoofing). Making a part of a transport header observable or
exposing new header fields can lead to ossification of that part of a
header as network devices come to rely on observations of the exposed
fields.
The following briefly reviews some security design options for The following briefly reviews some security design options for
transport protocols. A Survey of Transport Security Protocols transport protocols. A Survey of the Interaction between Security
[I-D.ietf-taps-transport-security] provides more details concerning Protocols and Transport Services [RFC8922] provides more details
commonly used encryption methods at the transport layer. concerning commonly used encryption methods at the transport layer.
Authenticating the Transport Protocol Header: Transport layer header Authenticating the Transport Protocol Header: Transport layer header
information can be authenticated. An integrity check that information can be authenticated. An integrity check that
protects the immutable transport header fields, but can still protects the immutable transport header fields, but can still
expose the transport protocol header information in the clear, expose the transport protocol header information in the clear,
allows in-network devices to observe these fields. An integrity allows in-network devices to observe these fields. An integrity
check is not able to prevent in-network modification, but can check is not able to prevent in-network modification, but can
prevent a receiving from accepting changes and avoid impact on the prevent a receiving endpoint from accepting changes and avoid
transport protocol operation. impact on the transport protocol operation, including some types
of attack.
An example transport authentication mechanism is TCP- An example transport authentication mechanism is TCP-
Authentication (TCP-AO) [RFC5925]. This TCP option authenticates Authentication (TCP-AO) [RFC5925]. This TCP option authenticates
the IP pseudo header, TCP header, and TCP data. TCP-AO protects the IP pseudo header, TCP header, and TCP data. TCP-AO protects
the transport layer, preventing attacks from disabling the TCP the transport layer, preventing attacks from disabling the TCP
connection itself and provides replay protection. Such connection itself and provides replay protection. Such
authentication might interact with middleboxes, depending on their authentication might interact with middleboxes, depending on their
behaviour [RFC3234]. behaviour [RFC3234].
The IPsec Authentication Header (AH) [RFC4302] was designed to The IPsec Authentication Header (AH) [RFC4302] was designed to
skipping to change at page 29, line 20 skipping to change at page 28, line 22
deployment of new methods. This seeks to prevent in-network deployment of new methods. This seeks to prevent in-network
devices utilising the information in a transport header, or can devices utilising the information in a transport header, or can
make an observation robust to a set of changing values, rather make an observation robust to a set of changing values, rather
than a specific set of values. It is not a security mechanism, than a specific set of values. It is not a security mechanism,
although use can be combined with an authentication mechanism. although use can be combined with an authentication mechanism.
As seen, different transports use encryption to protect their header As seen, different transports use encryption to protect their header
information to varying degrees. The trend is towards increased information to varying degrees. The trend is towards increased
protection. protection.
5. Addition of Transport OAM Information to Network-Layer Headers 5. Intentionally Exposing Transport Information to the Network
An on-path device can make measurements by utilising additional
protocol headers carrying operations, administration and management
(OAM) information in an additional packet header. Using network-
layer approaches to reveal information has the potential that the
same method (and hence same observation and analysis tools) can be
consistently used by multiple transport protocols. This approach
also could be applied to methods beyond OAM (see Section 6). There
can also be less desirable implications from separating the operation
of the transport protocol from the measurement framework.
5.1. Use of OAM within a Maintenance Domain
OAM information can be added at the ingress to a maintenance domain
(e.g., an Ethernet protocol header with timestamps and sequence
number information using a method such as 802.11ag or in-situ OAM
[I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol).
The additional header information is typically removed the at the
egress of the maintenance domain.
Although some types of measurements are supported, this approach does
not cover the entire range of measurements described in this
document. In some cases, it can be difficult to position measurement
tools at the appropriate segments/nodes and there can be challenges
in correlating the downstream/upstream information when in-band OAM
data is inserted by an on-path device.
5.2. Use of OAM across Multiple Maintenance Domains
OAM information can also be added at the network layer as an IPv6
extension header or an IPv4 option. This information can be used
across multiple network segments, or between the transport endpoints.
One example is the IPv6 Performance and Diagnostic Metrics (PDM)
destination option [RFC8250]. This allows a sender to optionally
include a destination option that caries header fields that can be
used to observe timestamps and packet sequence numbers. This
information could be authenticated by receiving transport endpoints
when the information is added at the sender and visible at the
receiving endpoint, although methods to do this have not currently
been proposed. This method has to be explicitly enabled at the
sender.
6. Intentionally Exposing Transport Information to the Network
A transport protocol can choose to expose certain transport A transport protocol can choose to expose certain transport
information to on-path devices operating at the network layer by information to on-path devices operating at the network layer by
sending observable fields. One approach is to make an explicit sending observable fields. One approach is to make an explicit
choice not to encrypt certain transport header fields, making this choice not to encrypt certain transport header fields, making this
transport information observable by the network. Another approach is transport information observable by the network. Another approach is
to choose to expose transport information through the use of network- to choose to expose transport information through the use of network-
layer extension headers. Both are examples of explicit information layer extension headers (see Section 6). Both are examples of
intended to be used by network devices on the path [RFC8558]. explicit information intended to be used by network devices on the
path [RFC8558].
Whatever the mechanism used to expose the information, a decision to Whatever the mechanism used to expose the information, a decision to
only expose specific transport information, places the transport only expose specific transport information, places the transport
endpoint in control of what to expose or not to expose outside of the endpoint in control of what to expose or not to expose outside of the
encrypted transport header. This decision can then be made encrypted transport header. This decision can then be made
independently of the transport protocol functionality. This 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 5.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 6) 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.2.2). For example, an endpoint that sends an IPv6 Hop-by- (Section 2.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 for further discussion of transport protocol format. See Section 2.1 for further discussion of transport 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 5.2. Common Exposed Transport Information
There are opportunities for multiple transport protocols to There are opportunities for multiple transport protocols to
consistently supply common observable information [RFC8558]. A consistently supply common observable information [RFC8558]. A
common approach can result in an open definition of the observable common approach can result in an open definition of the observable
fields. This has the potential that the same information can be fields. This has the potential that the same information can be
utilised across a range of operational and analysis tools. utilised across a range of operational and analysis tools.
6.3. Considerations for Exposing Transport Information 5.3. Considerations for Exposing Transport Information
The motivation to reflect actual transport header information and the
implications of network devices using this information has to be
considered when proposing such a method. RFC 8558 summarises this as
"When signals from endpoints to the path are independent from the
signals used by endpoints to manage the flow's state mechanics, they
may be falsified by an endpoint without affecting the peer's
understanding of the flow's state. For encrypted flows, this
divergence is not detectable by on-path devices." [RFC8558].
Considerations concerning what information, if any, it is appropriate Considerations concerning what information, if any, it is appropriate
to expose include: to expose include:
o On the one hand, explicitly exposing derived fields containing o On the one hand, explicitly exposing derived fields containing
relevant transport information (e.g., metrics for loss, latency, relevant transport information (e.g., metrics for loss, latency,
etc) can avoid network devices needing to derive this information etc) can avoid network devices needing to derive this information
from other header fields. This could result in development and from other header fields. This could result in development and
evolution of transport-independent tools around a common evolution of transport-independent tools around a common
observable header, and permit transport protocols to also evolve observable header, and permit transport protocols to also evolve
skipping to change at page 31, line 46 skipping to change at page 29, line 48
o On the other hand, protocols and implementations might be designed o On the other hand, protocols and implementations might be designed
to avoid consistently exposing external information that reflects to avoid consistently exposing external information that reflects
the actual internal information used by the protocol itself. An the actual internal information used by the protocol itself. An
endpoint/protocol could choose to expose transport header endpoint/protocol could choose to expose transport header
information to optimise the benefit it gets from the network information to optimise the benefit it gets from the network
[RFC8558]. The value of this information would be enhanced if the [RFC8558]. The value of this information would be enhanced if the
exposed information could be verified to match the protocol's exposed information could be verified to match the protocol's
observed behavior. observed behavior.
7. Implications of Protecting the Transport Headers The motivation to reflect actual transport header information and the
implications of network devices using this information has to be
The choice of which transport header fields to expose and which to considered when proposing such a method. RFC 8558 summarises this as
encrypt is a design decision for the transport protocol. Selective "When signals from endpoints to the path are independent from the
encryption requires trading conflicting goals of observability and signals used by endpoints to manage the flow's state mechanics, they
network support, privacy, and risk of ossification, to decide what may be falsified by an endpoint without affecting the peer's
header fields to protect and which to make visible. understanding of the flow's state. For encrypted flows, this
divergence is not detectable by on-path devices." [RFC8558].
Security work typically employs a design technique that seeks to
expose only what is needed [RFC3552]. This approach provides
incentives to not reveal any information that is not necessary for
the end-to-end communication. The IAB has provided guidelines for
writing Security Considerations for IETF specifications [RFC3552].
Endpoint design choices impacting privacy also need to be considered
as a part of the design process [RFC6973]. The IAB has provided
guidance for analyzing and documenting privacy considerations within
IETF specifications [RFC6973].
There can also be performance and operational trade-offs in exposing
selected information to network tools. This section explores key
implications of working with encrypted transport protocols.
7.1. Independent Measurement
Independent observation by multiple actors is important if the
transport community is to maintain an accurate understanding of the
network. Encrypting transport header encryption changes the ability
to collect and independently analyse data. Internet transport
protocols employ a set of mechanisms. Some of these have to work in
cooperation with the network layer for loss detection and recovery,
congestion detection and control. Others have to work only end-to-
end (e.g., parameter negotiation, flow-control).
The majority of present Internet applications use two well-known
transport protocols, TCP and UDP. Although TCP represents the
majority of current traffic, many real-time applications use UDP, and
much of this traffic uses RTP format headers in the payload of the
UDP datagram. Since these protocol headers have been fixed for
decades, a range of tools and analysis methods have became common and
well-understood.
Protocols that expose the state information used by the transport
protocol in their header information (e.g., timestamps used to
calculate the RTT, packet numbers used to asses congestion and
requests for retransmission) provide an incentive for the sending
endpoint to provide correct information, since the protocol will not
work otherwise. This increases confidence that the observer
understands the transport interaction with the network. For example,
when TCP is used over an unencrypted network path (i.e., one that
does not use IPsec or other encryption below the transport), it
implicitly exposes transport header information that can be used for
measurement at any point along the path. This information is
necessary for the protocol's correct operation, therefore there is no
incentive for a TCP or RTP implementation to put incorrect
information in this transport header. A network device can have
confidence that the well-known (and ossified) transport header
information represents the actual state of the endpoints.
When encryption is used to hide some or all of the transport headers,
the transport protocol chooses which information to reveal to the
network about its internal state, what information to leave
encrypted, and what fields to grease to protect against future
ossification [RFC8701]. Such a transport could be designed (or an
existing transport modified), for example, to provide summary data
regarding its performance, congestion control state, etc., or to make
available explicit measurement information. For example, a QUIC
endpoint can optionally set the spin bit to reflect to explicitly
reveal the RTT of an encrypted transport session to the on-path
network devices [I-D.ietf-quic-transport]).
When providing or using such information, it is important to consider
the privacy of the user and their incentive for providing accurate
and detailed information. Protocols that selectively reveal some
transport state or measurable information are choosing to establish a
trust relationship with the network operators. There is no protocol
mechanism that can guarantee that the information provided represents
the actual transport state of the endpoints, since those endpoints
can always send additional information in the encrypted part of the
header, to update or replace whatever they reveal. This reduces the
ability to independently measure and verify that a protocol is
behaving as expected. For some operational uses, the information has
to contain sufficient detail to understand, and possibly reconstruct,
the network traffic pattern for further testing. In this case,
operators have to gain the trust of transport protocol implementers
if the transport headers are to correctly reveal such information.
OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a
variety of encapsulation methods at different layers to support the
goals of a specific operational domain. OAM-related metadata can
support functions such as performance evaluation, path-tracing, path
verification information, classification and a diversity of other
uses. When encryption is used to hide some or all of the transport
headers, analysis requires coordination between actors at different
layers to successfully characterise flows and correlate the
performance or behaviour of a specific mechanism with the
configuration and traffic using operational equipment (e.g.,
combining transport and network measurements to explore congestion
control dynamics, the implications of designs for active queue
management or circuit breakers).
Some measurements could be completed by utilising endpoint-based
logging (e.g., based on Quic-Trace [Quic-Trace]). Such information
has a diversity of uses, including developers wishing to debug/
understand the transport/application protocols with which they work,
researchers seeking to spot trends and anomalies, and to characterise
variants of protocols. A standard format for endpoint logging could
allow these to be shared (after appropriate anonymisation) to
understand performance and pathologies. Measurements based on
logging have to establish the validity and provenance of the logged
information to establish how and when traces were captured.
Despite being applicable in some scenarios, endpoint logs do not
provide equivalent information to in-network measurements. In
particular, endpoint logs contain only a part of the information to
understand the operation of network devices and identify issues such
as link performance or capacity sharing between multiple flows.
Additional information has to be combined to determine which
equipment/links are used and the configuration of equipment along the
network paths being measured.
7.2. Characterising "Unknown" Network Traffic
The patterns and types of traffic that share Internet capacity change
over time as networked applications, usage patterns and protocols
continue to evolve.
If "unknown" or "uncharacterised" traffic patterns form a small part
of the traffic aggregate passing through a network device or segment
of the network the path, the dynamics of the uncharacterised traffic
might not have a significant collateral impact on the performance of
other traffic that shares this network segment. Once the proportion
of this traffic increases, monitoring the traffic can determine if
appropriate safety measures have to be put in place.
Tracking the impact of new mechanisms and protocols requires traffic
volume to be measured and new transport behaviours to be identified.
This is especially true of protocols operating over a UDP substrate.
The level and style of encryption has to be considered in determining
how this activity is performed. On a shorter timescale, information
could also have to be collected to manage DoS attacks against the
infrastructure.
7.3. Accountability and Internet Transport Protocols
Information provided by tools observing transport headers can be used
to classify traffic, and to limit the network capacity used by
certain flows, as discussed in Section 3.3.4). Equally, operators
could use analysis of transport headers and transport flow state to
demonstrate that they are not providing differential treatment to
certain flows. Obfuscating or hiding this information using
encryption could lead operators and maintainers of middleboxes
(firewalls, etc.) to seek other methods to classify, and potentially
other mechanisms to condition, network traffic.
A lack of data that reduces the level of precision with which flows
can be classified also reduces the design space for conditioning
mechanisms (e.g., rate limiting, circuit breaker techniques
[RFC8084], or blocking of uncharacterised traffic), and this has to
be considered when evaluating the impact of designs for transport
encryption [RFC5218].
7.4. Impact on Network Operations
Some network operators currently use observed transport header
information as a part of their operational practice, and have
developed tools and techniques that use information observed in
currently deployed transports and their applications. A variety of
open source and proprietary tools have been deployed that use this
information for a variety of short and long term measurements.
Encryption of the transport header information prevents tooling from
directly observing the transport header information, limiting its
utility.
Alternative diagnostic and troubleshooting tools would have to be 6. Addition of Transport OAM Information to Network-Layer Headers
developed and deployed is transport header encryption is widely
deployed. Introducing a new protocol or application might then
require these tool chains and practises to be updated, and could in
turn impact operational mechanisms, and policies. Each change can
introduce associated costs, including the cost of collecting data,
and the tooling to handle multiple formats (possibly as these co-
exist in the network, when measurements span time periods during
which changes are deployed, or to compare with historical data).
These costs are incurred by an operator to manage the service and
debug network issues.
At the time of writing, the overall operational impact of using If the transport headers are encrypted, on-path devices can make
encrypted transports is not yet well understood. Design trade-offs measurements by utilising additional protocol headers carrying
could mitigate these costs by explicitly choosing to expose selected operations, administration and management (OAM) information in an
information (e.g., header invariants and the spin-bit in QUIC additional packet header. Using network-layer approaches to reveal
[I-D.ietf-quic-transport]), the specification of common log formats, information has the potential that the same method (and hence same
and development of alternative approaches. observation and analysis tools) can be consistently used by multiple
transport protocols. This approach also could be applied to methods
beyond OAM (see Section 5). There can also be less desirable
implications from separating the operation of the transport protocol
from the measurement framework.
7.5. Impact on Research, Development and Deployment 6.1. Use of OAM within a Maintenance Domain
Transport protocol evolution, and the ability to measure and OAM information can be added at the ingress to a maintenance domain
understand the impact of protocol changes, have to proceed hand-in- (e.g., an Ethernet protocol header with timestamps and sequence
hand. A transport protocol that provides observable headers can be number information using a method such as 802.11ag or in-situ OAM
used to provide open and verifiable measurement data. Observation of [I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol).
pathologies has a critical role in the design of transport protocol The additional header information is typically removed the at the
mechanisms and development of new mechanisms and protocols. This egress of the maintenance domain.
helps understanding the interactions between cooperating protocols
and network mechanism, the implications of sharing capacity with
other traffic and the impact of different patterns of usage. The
ability of other stake holders to review transport header traces
helps develop insight into performance and traffic contribution of
specific variants of a protocol.
Development of new transport protocol mechanisms has to consider the Although some types of measurements are supported, this approach does
scale of deployment and the range of environments in which the not cover the entire range of measurements described in this
transport is used. Experience has shown that it is often difficult document. In some cases, it can be difficult to position measurement
to correctly implement new mechanisms [RFC8085], and that mechanisms tools at the appropriate segments/nodes and there can be challenges
often evolve as a protocol matures, or in response to changes in in correlating the downstream/upstream information when in-band OAM
network conditions, changes in network traffic, or changes to data is inserted by an on-path device.
application usage. Analysis is especially valuable when based on the
behaviour experienced across a range of topologies, vendor equipment,
and traffic patterns.
New transport protocol formats are expected to facilitate an 6.2. Use of OAM across Multiple Maintenance Domains
increased pace of transport evolution, and with it the possibility to
experiment with and deploy a wide range of protocol mechanisms.
There has been recent interest in a wide range of new transport
methods, e.g., Larger Initial Window, Proportional Rate Reduction
(PRR), congestion control methods based on measuring bottleneck
bandwidth and round-trip propagation time, the introduction of AQM
techniques and new forms of ECN response (e.g., Data Centre TCP,
DCTP, and methods proposed for L4S). The growth and diversity of
applications and protocols using the Internet also continues to
expand. For each new method or application it is desirable to build
a body of data reflecting its behaviour under a wide range of
deployment scenarios, traffic load, and interactions with other
deployed/candidate methods.
Encryption of transport header information could reduce the range of OAM information can also be added at the network layer as an IPv6
actors that can observe useful data. This would limit the extension header or an IPv4 option. This information can be used
information sources available to the Internet community to understand across multiple network segments, or between the transport endpoints.
the operation of new transport protocols, reducing information to
inform design decisions and standardisation of the new protocols and
related operational practises. The cooperating dependence of
network, application, and host to provide communication performance
on the Internet is uncertain when only endpoints (i.e., at user
devices and within service platforms) can observe performance, and
when performance cannot be independently verified by all parties.
Independently observed data is also important to ensure the health of One example is the IPv6 Performance and Diagnostic Metrics (PDM)
the research and development communities and can help promote destination option [RFC8250]. This allows a sender to optionally
acceptance of proposed specifications by the wider community (e.g., include a destination option that caries header fields that can be
as a method to judge the safety for Internet deployment) and provides used to observe timestamps and packet sequence numbers. This
valuable input during standardisation. Open standards motivate a information could be authenticated by receiving transport endpoints
desire to include independent observation and evaluation of when the information is added at the sender and visible at the
performance data, which in turn demands control/understanding about receiving endpoint, although methods to do this have not currently
where and when measurement samples are collected. This requires been proposed. This method has to be explicitly enabled at the
consideration of the methods used to observe data and the appropriate sender.
balance between encrypting all and no transport header information.
8. Conclusions 7. Conclusions
Header encryption and strong integrity checks are being incorporated Header encryption and strong integrity checks are being incorporated
into new transport protocols and have important benefits. The pace into new transport protocols and have important benefits. The pace
of development of transports using the WebRTC data channel, and the of development of transports using the WebRTC data channel, and the
rapid deployment of the QUIC transport protocol, can both be rapid deployment of the QUIC transport protocol, can both be
attributed to using the combination of UDP as a substrate while attributed to using the combination of UDP as a substrate while
providing confidentiality and authentication of the encapsulated providing confidentiality and authentication of the encapsulated
transport headers and payload. transport headers and payload.
This document has described some current practises, and the This document has described some current practises, and the
implications for some stake holders, when transport layer header implications for some stakeholders, when transport layer header
encryption is used. It does not judge whether these practises are encryption is used. It does not judge whether these practises are
necessary, or endorse the use of any specific practise. Rather, the necessary, or endorse the use of any specific practise. Rather, the
intent is to highlight operational tools and practises to consider intent is to highlight operational tools and practises to consider
when designing and modifying transport protocols, so protocol when designing and modifying transport protocols, so protocol
designers can make informed choice about what transport header fields designers can make informed choice about what transport header fields
to encrypt, and whether it might be beneficial to make an explicit to encrypt, and whether it might be beneficial to make an explicit
choice to expose certain fields to the network. In making such a choice to expose certain fields to the network. In making such a
decision, it is important to balance: decision, it is important to balance:
o User Privacy: The less transport header information that is o User Privacy: The less transport header information that is
exposed to the network, the lower the risk of leaking metadata exposed to the network, the lower the risk of leaking metadata
that might have privacy implications for the users. Transports that might have privacy implications for the users. Transports
that chose to expose some header fields need to make a privacy that chose to expose some header fields need to make a privacy
assessment to understand the privacy cost versus benefit trade-off assessment to understand the privacy cost versus benefit trade-off
in making that information available. The process used to define in making that information available. The process used to define
and expose the QUIC spin bit to the network is an example of such and expose the QUIC spin bit to the network is an example of such
an analysis. an analysis.
o Protocol Ossification: Unencrypted transport header fields are o Transport Ossification: Unencrypted transport header fields are
likely to ossify rapidly, as network devices come to rely on their likely to ossify rapidly, as network devices come to rely on their
presence, making it difficult to change the transport in future. presence, making it difficult to change the transport in future.
This argues that the choice to expose information to the network This argues that the choice to expose information to the network
is made deliberately and with care, since it is essentially is made deliberately and with care, since it is essentially
defining a stable interface between the transport and the network. defining a stable interface between the transport and the network.
Some protocols will want to make that interface as limited as Some protocols will want to make that interface as limited as
possible; other protocols might find value in exposing certain possible; other protocols might find value in exposing certain
information to signal to the network, or in allowing the network information to signal to the network, or in allowing the network
to change certain header fields as signals to the transport. The to change certain header fields as signals to the transport. The
visible wire image of a protocol should be explicitly designed. visible wire image of a protocol should be explicitly designed.
o Network Ossification: While encryption can reduce ossification of
the transport protocol, it does not itself prevent ossification of
the network service. People seeking to understand network traffic
could still come to rely on pattern inferences and other
heuristics or machine learning to derive measurement data and as
the basis for network forwarding decisions [RFC8546]. This can
also create dependencies on the transport protocol, or the
patterns of traffic it can generate, also in time resulting in
ossification of the service.
o Impact on Operational Practice: The network operations community o Impact on Operational Practice: The network operations community
has long relied on being able to understand Internet traffic has long relied on being able to understand Internet traffic
patterns, both in aggregate and at the flow level, to support patterns, both in aggregate and at the flow level, to support
network management, traffic engineering, and troubleshooting. network management, traffic engineering, and troubleshooting.
Operational practice has developed based on the information Operational practice has developed based on the information
available from unencrypted transport headers. The IETF has available from unencrypted transport headers. The IETF has
supported this practice by developing operations and management supported this practice by developing operations and management
specifications, interface specifications, and associated Best specifications, interface specifications, and associated Best
Current Practises. Widespread deployment of transport protocols Current Practises. Widespread deployment of transport protocols
that encrypt their information might impact network operations, that encrypt their information will impact network operations,
unless operators can develop alternative practises that work unless operators can develop alternative practises that work
without access to the transport header. without access to the transport header.
o Pace of Evolution: Removing obstacles to change can enable an o Pace of Evolution: Removing obstacles to change can enable an
increased pace of evolution. If a protocol changes its transport increased pace of evolution. If a protocol changes its transport
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
designers need to consider the diversity of operational networks therefore designers need to consider the diversity of operational
(ISPs, enterprises, Distributed DoS (DDoS) mitigation and firewall networks (ISPs, enterprises, Distributed DoS (DDoS) mitigation and
maintainers, etc.). firewall 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 39, line 26 skipping to change at page 33, line 22
o Impact on Research and Development: Hiding transport header o Impact on Research and Development: Hiding transport header
information can impede independent research into new mechanisms, information can impede independent research into new mechanisms,
measurement of behaviour, and development initiatives. Experience measurement of behaviour, and development initiatives. Experience
shows that transport protocols are complicated to design and shows that transport protocols are complicated to design and
complex to deploy, and that individual mechanisms have to be complex to deploy, and that individual mechanisms have to be
evaluated while considering other mechanisms, across a broad range evaluated while considering other mechanisms, across a broad range
of network topologies and with attention to the impact on traffic of network topologies and with attention to the impact on traffic
sharing the capacity. If increased use of transport header sharing the capacity. If increased use of transport header
encryption results in reduced availability of open data, it could encryption results in reduced availability of open data, it could
eliminate the independent self-checks to the standardisation eliminate the independent checks to the standardisation process
process that have previously been in place from research and that have previously been in place from research and academic
academic contributors (e.g., the role of the IRTF Internet contributors (e.g., the role of the IRTF Internet Congestion
Congestion Control Research Group (ICCRG) and research Control Research Group (ICCRG) and research publications in
publications in reviewing new transport mechanisms and assessing reviewing new transport mechanisms and assessing the impact of
the impact of their deployment). their deployment).
Observable transport header information might be useful to various Observable transport header information might be useful to various
stake holders. Other sets of stake holders have incentives to limit stakeholders. Other sets of stakeholders have incentives to limit
what can be observed. This document does not make recommendations what can be observed. This document does not make recommendations
about what information ought to be exposed, to whom it ought to be about what information ought to be exposed, to whom it ought to be
observable, or how this will be achieved. There are also design observable, or how this will be achieved. There are also design
choices about where observable fields are placed. For example, one choices about where observable fields are placed. For example, one
location could be a part of the transport header outside of the location could be a part of the transport header outside of the
encryption envelope, another alternative is to carry the information encryption envelope, another alternative is to carry the information
in a network-layer option or extension header. New transport in a network-layer option or extension header. New transport
protocol designs ought to explicitly identify any fields that are protocol designs ought to explicitly identify any fields that are
intended to be observed, consider if there are alternative ways of intended to be observed, consider if there are alternative ways of
providing the information, and reflect on the implications of providing the information, and reflect on the implications of
skipping to change at page 40, line 10 skipping to change at page 34, line 7
As [RFC7258] notes, "Making networks unmanageable to mitigate As [RFC7258] notes, "Making networks unmanageable to mitigate
(pervasive monitoring) is not an acceptable outcome, but ignoring (pervasive monitoring) is not an acceptable outcome, but ignoring
(pervasive monitoring) would go against the consensus documented (pervasive monitoring) would go against the consensus documented
here." Providing explicit information can help avoid traffic being here." Providing explicit information can help avoid traffic being
inappropriately classified, impacting application performance. An inappropriately classified, impacting application performance. An
appropriate balance will emerge over time as real instances of this appropriate balance will emerge over time as real instances of this
tension are analysed [RFC7258]. This balance between information tension are analysed [RFC7258]. This balance between information
exposed and information hidden ought to be carefully considered when exposed and information hidden ought to be carefully considered when
specifying new transport protocols. specifying new transport protocols.
9. Security Considerations 8. Security Considerations
This document is about design and deployment considerations for This document is about design and deployment considerations for
transport protocols. Issues relating to security are discussed transport protocols. Issues relating to security are discussed
throughout this document. throughout this document.
Authentication, confidentiality protection, and integrity protection Authentication, confidentiality protection, and integrity protection
are identified as Transport Features by [RFC8095]. As currently are identified as Transport Features by [RFC8095]. As currently
deployed in the Internet, these features are generally provided by a deployed in the Internet, these features are generally provided by a
protocol or layer on top of the transport protocol protocol or layer on top of the transport protocol [RFC8922].
[I-D.ietf-taps-transport-security].
Confidentiality and strong integrity checks have properties that can Confidentiality and strong integrity checks have properties that can
also be incorporated into the design of a transport protocol or to also be incorporated into the design of a transport protocol or to
modify an existing transport. Integrity checks can protect an modify an existing transport. Integrity checks can protect an
endpoint from undetected modification of protocol fields by network endpoint from undetected modification of protocol fields by network
devices, whereas encryption and obfuscation or greasing can further devices, whereas encryption and obfuscation or greasing can further
prevent these headers being utilised by network devices [RFC8701]. prevent these headers being utilised by network devices [RFC8701].
Preventing observation of headers provides an opportunity for greater Preventing observation of headers provides an opportunity for greater
freedom to update the protocols and can ease experimentation with new freedom to update the protocols and can ease experimentation with new
techniques and their final deployment in endpoints. A protocol techniques and their final deployment in endpoints. A protocol
specification needs to weigh the costs of ossifying common headers, specification needs to weigh the costs of ossifying common headers,
versus the potential benefits of exposing specific information that versus the potential benefits of exposing specific information that
could be observed along the network path to provide tools to manage could be observed along the network path to provide tools to manage
new variants of protocols. new variants of protocols.
Header encryption can provide confidentiality of some or all of the Header encryption can provide confidentiality of some or all of the
transport header information. This prevents an on-path device from transport header information. This prevents an on-path device from
knowledge of the header field. It therefore prevents mechanisms knowledge of the header field. It therefore prevents mechanisms
being built that directly rely on the information or seeks to infer being built that directly rely on the information or seeks to infer
semantics of an exposed header field. Reduces visibility into semantics of an exposed header field. Reduced visibility into
transport metadata can limit the ability to measure and characterise transport metadata can limit the ability to measure and characterise
traffic. It can also provide privacy benefits in some cases. traffic, and conversely can provide privacy benefits.
Extending the transport payload security context to also include the Extending the transport payload security context to also include the
transport protocol header protects both information with the same transport protocol header protects both information with the same
key. A privacy concern would arise if this key was shared with a key. A privacy concern would arise if this key was shared with a
third party, e.g., providing access to transport header information third party, e.g., providing access to transport header information
to debug a performance issue, would also result in exposing the to debug a performance issue, would also result in exposing the
transport payload data to the same third party. Such risks would be transport payload data to the same third party. Such risks would be
mitigated using a layered security design that provides one domain of mitigated using a layered security design that provides one domain of
protection and associated keys for the transport payload and protection and associated keys for the transport payload and
encrypted transport headers; and a separate domain of protection and encrypted transport headers; and a separate domain of protection and
skipping to change at page 42, line 24 skipping to change at page 36, line 20
The Security and Privacy Considerations in the Framework for Large- The Security and Privacy Considerations in the Framework for Large-
Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain
considerations for Active and Passive measurement techniques and considerations for Active and Passive measurement techniques and
supporting material on measurement context. supporting material on measurement context.
Addition of observable transport information to the path increases Addition of observable transport information to the path increases
the information available to an observer and may, when this the information available to an observer and may, when this
information can be linked to a node or user, reduce the privacy of information can be linked to a node or user, reduce the privacy of
the user. See the security considerations of [RFC8558]. the user. See the security considerations of [RFC8558].
10. IANA Considerations 9. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 10. 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, Mohamed Boucadair, Martin Thomson, David Black, Wood, Thomas Fossati, Mohamed Boucadair, Martin Thomson, David Black,
and other members of TSVWG for their comments and feedback. Martin Duke, 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.
12. Informative References 11. Informative References
[bufferbloat] [bufferbloat]
Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in
the Internet. Communications of the ACM, 55(1):57-65", the Internet. Communications of the ACM, 55(1):57-65",
January 2012. January 2012.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
progress), July 2020. progress), July 2020.
skipping to change at page 43, line 20 skipping to change at page 37, line 20
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-29 (work and Secure Transport", draft-ietf-quic-transport-29 (work
in progress), June 2020. in progress), June 2020.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
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]
Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction Between Security
Protocols and Transport Services", draft-ietf-taps-
transport-security-12 (work in progress), April 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-38 (work in progress), May
2020. 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.
skipping to change at page 51, line 5 skipping to change at page 44, line 34
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>. 2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And [RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility", Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020, RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>. <https://www.rfc-editor.org/info/rfc8701>.
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/info/rfc8922>.
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 53, line 22 skipping to change at page 47, line 22
-13 Updated following 2nd WGLC with comments from D.L.Black; T. -13 Updated following 2nd WGLC with comments from D.L.Black; T.
Herbert; Ekr; and other reviewers. Herbert; Ekr; and other reviewers.
-14 Update to resolve feedback to rev -13. This moves the general -14 Update to resolve feedback to rev -13. This moves the general
discussion of adding fields to transport packets to section 6, and discussion of adding fields to transport packets to section 6, and
discusses with reference to material in RFC8558. discusses with reference to material in RFC8558.
-15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins -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 discussion 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. -16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3.
-17 Revised to satisfy ID-NITs and updates REFs to latest rev, -17 Revised to satisfy ID-NITs and updates REFs to latest rev,
updated HC REFs; cited IAB guidance on security and privacy within updated HC REFs; cited IAB guidance on security and privacy within
IETF specs. IETF specs.
-18 Revised based on AD review.
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. 80 change blocks. 
902 lines changed or deleted 611 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/