< draft-ietf-tsvwg-transport-encrypt-06.txt   draft-ietf-tsvwg-transport-encrypt-07.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: December 2, 2019 University of Glasgow Expires: January 5, 2020 University of Glasgow
May 31, 2019 July 04, 2019
The Impact of Transport Header Confidentiality on Network Operation and The Impact of Transport Header Confidentiality on Network Operation and
Evolution of the Internet Evolution of the Internet
draft-ietf-tsvwg-transport-encrypt-06 draft-ietf-tsvwg-transport-encrypt-07
Abstract Abstract
This document describes implications of applying end-to-end This document describes implications of applying end-to-end
encryption at the transport layer. It identifies in-network uses of encryption at the transport layer. It identifies in-network uses of
transport layer header information. It then reviews the implications transport layer header information. It then reviews the implications
of developing end-to-end transport protocols that use authentication of developing end-to-end transport protocols that use authentication
to protect the integrity of transport information or encryption to to protect the integrity of transport information or encryption to
provide confidentiality of the transport protocol header and expected provide confidentiality of the transport protocol header and expected
implications of transport protocol design and network operation. implications of transport protocol design and network operation.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 2, 2019. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3
3. Current uses of Transport Headers within the Network . . . . 10 2.1. Use of Transport Header Information in the Network . . . 4
3.1. Observing Transport Information in the Network . . . . . 10 2.2. Encryption of Transport Header Information . . . . . . . 5
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 16 2.3. Encryption tradeoffs . . . . . . . . . . . . . . . . . . 6
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 20 3. Current uses of Transport Headers within the Network . . . . 8
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 21 3.1. Observing Transport Information in the Network . . . . . 9
4. Encryption and Authentication of Transport Headers . . . . . 22 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 19
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 20
4. Encryption and Authentication of Transport Headers . . . . . 21
5. Addition of Transport Information to Network-Layer Protocol 5. Addition of Transport Information to Network-Layer Protocol
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Implications of Protecting the Transport Headers . . . . . . 26 6. Implications of Protecting the Transport Headers . . . . . . 25
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 27 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 26
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 29 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 28
6.3. Accountability and Internet Transport Protocols . . . . . 29 6.3. Accountability and Internet Transport Protocols . . . . . 28
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 29 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 28
6.5. Impact on Research, Development and Deployment . . . . . 30 6.5. Impact on Research, Development and Deployment . . . . . 29
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
11. Informative References . . . . . . . . . . . . . . . . . . . 34 11. Informative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. Revision information . . . . . . . . . . . . . . . . 42 Appendix A. Revision information . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
There is increased interest in, and deployment of, new protocols that There is increased interest in, and deployment of, protocols that
employ end-to-end encryption at the transport layer, including the employ end-to-end encryption at the transport layer, including the
transport layer headers. An example of such a transport is the QUIC transport layer headers. An example of such a transport is the QUIC
transport protocol [I-D.ietf-quic-transport], currently being transport protocol [I-D.ietf-quic-transport], currently being
standardised in the IETF. Encryption of transport layer headers and standardised in the IETF. Encryption of transport layer headers and
payload data has many benefits in terms of protecting user privacy. payload data has many benefits in terms of protecting user privacy.
These benefits have been widely discussed [RFC7258], [RFC7624], and These benefits have been widely discussed [RFC7258], [RFC7624], and
this document strongly supports the increased use of encryption in this document strongly supports the increased use of encryption in
transport protocols. There are also, however, some costs, in that transport protocols. Encryption can also be used to prevent unwanted
the widespread use of transport encryption requires changes to modification of transport header information by middleboxes. There
network operations, and complicates network measurement for research, are also, however, some costs, in that the widespread use of
operational, and standardisation purposes. The direction in which transport encryption requires changes to network operations, and
the use of transport header confidentiality evolves could have complicates network measurement for research, operational, and
significant implications on the way the Internet architecture standardisation purposes. The direction in which the use of
develops, and therefore needs to be considered as a part of protocol transport header confidentiality evolves could have significant
design. implications on the way the Internet architecture develops, and
therefore needs to be considered as a part of protocol design.
This document discusses some consequences of applying end-to-end
encryption at the transport layer. It reviews the implications of
developing end-to-end transport protocols that use encryption to
provide confidentiality of the transport protocol header, and
considers the effect of such changes on transport protocol design and
network operations. It also considers anticipated implications on
transport and application evolution.
The remainder of this document discusses some consequences of The remainder of this document discusses some consequences of
applying end-to-end encryption at the transpvort layer. It reviews applying end-to-end encryption at the transport layer. It reviews
the implications of developing end-to-end transport protocols that the implications of developing end-to-end transport protocols that
use encryption to provide confidentiality of the transport protocol use encryption to provide confidentiality of the transport protocol
header, and considers the effect of such changes on transport header, and considers the effect of such changes on transport
protocol design and network operations. It also considers protocol design and network operations. It also considers
anticipated implications on transport and application evolution. anticipated implications on transport and application evolution.
Transports are increasingly encrypting and authenticating the payload Transports are also increasingly encrypting and authenticating the
(i.e., the application data carried within the transport connection) payload (i.e., the application data carried within the transport
end-to-end. Such protection is encouraged, and the implications of connection) end-to-end. Such protection is encouraged, and the
protecting the payload are not further discussed in this memo. implications of protecting the payload are not further discussed in
this memo.
2. Context and Rationale 2. Context and Rationale
The transport layer provides end-to-end interactions between The transport layer provides end-to-end interactions between
endpoints (processes) using an Internet path. Transport protocols endpoints (processes) using an Internet path. Transport protocols
layer directly over the network-layer service and are sent in the layer directly over the network-layer service and are sent in the
payload of network-layer packets. They support end-to-end payload of network-layer packets. They support end-to-end
communication between applications, supported by higher-layer communication between applications, supported by higher-layer
protocols, running on the end systems (or transport endpoints). This protocols, running on the end systems (transport endpoints). This
simple architectural view hides one of the core functions of the simple architectural view hides one of the core functions of the
transport, however, to discover and adapt to the properties of the transport: to discover and adapt to the Internet path that is
Internet path that is currently being used. The design of Internet currently used. The design of Internet transport protocols is as
transport protocols is as much about trying to avoid the unwanted much about trying to avoid the unwanted side effects of congestion on
side effects of congestion on a flow and other capacity-sharing a flow and other capacity-sharing flows, avoiding congestion
flows, avoiding congestion collapse, adapting to changes in the path collapse, adapting to changes in the path characteristics, etc., as
characteristics, etc., as it is about end-to-end feature negotiation, it is about end-to-end feature negotiation, flow control and
flow control and optimising for performance of a specific optimising for performance of a specific application.
application.
To achieve stable Internet operations the IETF transport community To achieve stable Internet operations the IETF transport community
has to date relied heavily on measurement and insights of the network has to date relied heavily on measurement and the insights of the
operations community to understand the trade-offs, and to inform network operations community to understand the trade-offs, and to
selection of appropriate mechanisms, to ensure a safe, reliable, and inform selection of appropriate mechanisms, to ensure a safe,
robust Internet (e.g., [RFC1273]). In turn, the network operations reliable, and robust Internet (e.g., [RFC1273]). In turn, the
community relies on being able to understand the pattern and network operator (and access provider) community has relied on being
requirements of traffic passing over the Internet, both in aggregate able to understand the pattern and requirements of traffic passing
and at the flow level. over the Internet, both in aggregate and at the flow level.
There are many motivations for deploying encrypted transports
[RFC7624] (i.e., transport protocols that use encryption to provide
confidentiality of some or all of the transport-layer header
information), and encryption of transport payloads (i.e.
Confidentiality of the payload data). The increasing public concerns
about interference with Internet traffic have led to a rapidly
expanding deployment of encryption to protect end-user privacy, e.g.,
QUIC [I-D.ietf-quic-transport]. Encryption is also expected to form
a basis for future transport protocol designs.
Some network operators and access providers have come to rely on the 2.1. Use of Transport Header Information in the Network
in-network measurement of transport properties and the functionality
provided by middleboxes to both support network operations and
enhance performance. There can therefore be implications when
working with encrypted transport protocols that hide transport header
information from the network. These present architectural challenges
and considerations in the way transport protocols are designed, and
ability to characterise and compare different transport solutions
[Measure]. Implementations of network devices are encouraged to
avoid side-effects when protocols are updated. Introducing
cryptographic integrity checks to header fields can also prevent
undetected manipulation of the field by network devices, or
undetected addition of information to a packet. However, this does
not prevent inspection of the information by a device on path, and it
is possible that such devices could develop mechanisms that rely on
the presence of such a field or a known value in the field.
Reliance on the presence and semantics of specific header information In-network measurement of transport flow characteristics can be used
leads to ossification. An endpoint could be required to supply a to enhance performance, and control cost and service reliability.
specific header to receive the network service that it desires. In Some operators have deployed functionality in middleboxes to both
some cases, this could be benign or advantageous to the protocol support network operations can be deployed to enhance performance. A
(e.g., recognising the start of a connection, or explicitly exposing reliance on the presence and semantics of specific header information
leads to ossification, where an endpoint could be required to supply
a specific header to receive the network service that it desires. In
some case this could be benign or advantageous to the protocol (e.g.,
recognising the start of a connection, or explicitly exposing
protocol information can be expected to provide more consistent protocol information can be expected to provide more consistent
decisions by on-path devices than the use of diverse methods to infer decisions by on-path devices than the use of diverse methods to infer
semantics from other flow properties); in other cases this is not semantics from other flow properties). In other cases the
beneficial (e.g., a mechanism implemented in a network device, such ossification could frustrate the evolution of the protocol (e.g., a
as a firewall, that required a header field to have only a specific mechanism implemented in a network device, such as a firewall, that
known set of values could prevent the device from forwarding packets required a header field to have only a specific known set of values
using a different version of a protocol that introduces a new feature would prevent the device from forwarding packets using a different
that changes the value present in this field, preventing the version of a protocol that introduces a feature that changes the
evolution of the protocol). Experience developing Transport Layer value of this field).
Security [RFC8446], required a design that recognised that deployed
middleboxes relied on the exposed information in TLS 1.2
Examples of the impact of ossification on transport protocol design Experience developing Transport Layer Security [RFC8446], required a
and ease of deployment can be seen in the case of Multipath TCP design that recognised that deployed middleboxes relied on the
(MPTCP) and the TCP Fast Open option. The design of MPTCP had to be exposed information in Transport Layer Security (TLS) 1.2. Examples
revised to account for middleboxes, so called "TCP Normalizers", that of the impact of ossification can be found in the development of
monitor the evolution of the window advertised in the TCP headers and Multipath TCP (MPTCP) and the TCP Fast Open option. The design of
that reset connections if the window does not grow as expected. MPTCP had to be revised to account for middleboxes, so called "TCP
Similarly, TCP Fast Open has had issues with middleboxes that remove Normalizers", that monitor the evolution of the window advertised in
unknown TCP options, that drop segments with unknown TCP options, the TCP headers and that reset connections if the window does not
that drop segments that contain data and have the SYN bit set, that grow as expected. Similarly, TCP Fast Open has had issues with
drop packets with SYN/ACK that acknowledge data, or that disrupt middleboxes that remove unknown TCP options, that drop segments with
connections that send data before the three-way handshake completes. unknown TCP options, that drop segments that contain data and have
In both cases, the issue was caused by middleboxes that had a hard- the SYN bit set, that drop packets with SYN/ACK that acknowledge
coded understanding of transport behaviour, and that interacted data, or that disrupt connections that send data before the three-way
poorly with transports that tried to change that behaviour. Other handshake completes. In both cases, the issue was caused by
examples have included middleboxes that rewrite TCP sequence and middleboxes that had a hard-coded understanding of transport
acknowledgement numbers but are unaware of the (newer) SACK option behaviour, and that interacted poorly with transports that tried to
and don't correctly rewrite selective acknowledgements to match the change that behaviour. Other examples have included middleboxes that
changes made to the fixed TCP header. rewrite TCP sequence and acknowledgement numbers but are unaware of
the (newer) SACK option and don't correctly rewrite selective
acknowledgements to match the changes made to the fixed TCP header.
A protocol design that uses header encryption can provide 2.2. Encryption of Transport Header Information
confidentiality of some or all of the protocol header information.
Encryption with secure key distribution prevents an on-path device
from observing the header field. It, therefore, prevents mechanisms
being built that directly rely on the information or seek to infer
semantics of an exposed header field. Using encryption to provide
confidentiality of the transport layer brings some well-known privacy
and security benefits and can therefore help reduce ossification of
the transport layer. In particular, it is important that protocols
either do not expose information where the usage could change in
future protocols or that methods that utilise the information are
robust to potential changes as protocols evolve over time. To avoid
unwanted inspection, a protocol could also intentionally vary the
format and/or value of header fields (sometimes known as Greasing
[I-D.thomson-quic-grease]). However, while encryption hides the
protocol header information, it does not prevent ossification of the
network service. People seeking to understand network traffic could
come to rely on pattern inferences and other heuristics as the basis
for network decision and to derive measurement data, creating new
dependencies on the transport protocol.
Specification of non-encrypted transport header fields explicitly Encryption is expected to form a basis for many future transport
allows protocol designers to make specific header information protocol designs. There are many motivations for deploying encrypted
observable in the network. This supports other uses of this transports [RFC7624] (i.e., transport protocols that use encryption
information by on-path devices, and at the same time this can be to provide confidentiality of some or all of the transport-layer
header information), and encryption of transport payloads (i.e.
Confidentiality of the payload data). Increasing public concerns
about interference with Internet traffic have led to a rapidly
expanding deployment of encryption to protect end-user privacy, e.g.,
QUIC [I-D.ietf-quic-transport]. Using encryption to provide
confidentiality of the transport layer therefore brings some well-
known privacy and security benefits. Although it is important that
protocols either do not expose information where the usage could
change in future protocols or that methods that utilise the
information are robust to potential changes as protocols evolve over
time.
Introducing cryptographic integrity checks for header fields can
prevent undetected manipulation of the field by network devices, or
undetected addition of information to a packet. This does not
prevent inspection of the information by a device on path, and it is
possible that such devices could develop mechanisms that rely on the
presence of such a field or a known value in the field. In this
context, specification of a non-encrypted transport header field
explicitly allows protocol designers to make specific header
information observable in the network. This supports other uses of
this information by on-path devices, and at the same time this can be
expected to lead to ossification of the transport header, because expected to lead to ossification of the transport header, because
network forwarding could evolve to depend on the presence and/or network forwarding could evolve to depend on the presence and/or
value of these fields. The decision about which transport headers value of these fields. To avoid unwanted inspection, a protocol
fields are made observable offers trade-offs around authentication could intentionally vary the format and/or value of exposed header
and confidentiality versus observability, network operations and fields (sometimes known as Greasing [I-D.thomson-quic-grease]).
management, and ossification. For example, a design that provides
confidentiality of protocol header information can impact the
following activities that rely on measurement and analysis of traffic
flows:
Network Operations and Research: Observable transport headers enable
both operators and the research community to explicitly measure
and analyse protocol performance, network anomalies, and failure
pathologies.
This information can help inform capacity planning and assist in
determining the need for equipment and/or configuration changes by
network operators.
The data can also inform Internet engineering research, and help
in the development of new protocols, methodologies, and
procedures. Concealing the transport protocol header information
makes the stream performance unavailable to passive observers
along the path, and likely leads to the development of alternative
methods to collect or infer that data (for example heuristics
based on the analysis of traffic patterns).
Providing confidentiality of the transport payload, but leaving A protocol design that uses header encryption with secure key
some, or all, of the transport headers unencrypted, possibly with distribution can provide confidentiality of some or all of the
authentication, can provide many of the privacy and security protocol header information. This prevents an on-path device from
benefits while supporting operations and research, but at the cost observing the header field. This prevents mechanisms being built
of ossifying the transport headers. that directly rely on the information or seek to infer semantics of
an exposed header field and can therefore help reduce ossification of
the transport layer. While encryption can hide transport header
information, it does not prevent ossification of the network service.
Protection from Denial of Service: Observable transport headers People seeking to understand network traffic could come to rely on
currently provide useful input to classify traffic and detect pattern inferences and other heuristics as the basis for network
anomalous events (e.g., changes in application behaviour, decision and to derive measurement data, creating new dependencies on
distributed denial of service attacks). To be effective, this the transport protocol (or the patterns of traffic it can generate).
protection needs to be able to uniquely disambiguate unwanted This use of machine-learning methods usually demands large data sets,
traffic. An inability to separate this traffic using packet presenting it own requirements for collecting and distributing the
header information could result in less-efficient identification data.
of unwanted traffic or development of different methods (e.g.
rate-limiting of uncharacterised traffic).
Network Troubleshooting and Diagnostics: Encrypting transport 2.3. Encryption tradeoffs
header information eliminates the incentive for operators to
troubleshoot since they cannot interpret the data. A flow
experiencing packet loss or jitter looks like an unaffected flow
when only observing network layer headers (if transport sequence
numbers and flow identifiers are obscured). This limits
understanding of the impact of packet loss or latency on the
flows, or even localizing the network segment causing the packet
loss or latency. Encrypted traffic could imply "don't touch" to
some, and could limit a trouble-shooting response to "can't help,
no trouble found". Additional mechanisms will need to be
introduced to help reconstruct or replace transport-level metrics
to support troubleshooting and diagnostics, but these add
complexity and operational costs (e.g., in deploying additional
functions in equipment or adding traffic overhead).
Network Traffic Analysis: Hiding transport protocol header The are architectural challenges and considerations in the way
information can make it harder to determine which transport transport protocols are designed, and the ability to characterise and
protocols and features are being used across a network segment and compare different transport solutions [Measure]. The decision about
to measure trends in the pattern of usage. This could impact the which transport headers fields are made observable offers trade-offs
ability for an operator to anticipate the need for network around authentication and confidentiality versus observability,
upgrades and roll-out. It can also impact the on-going traffic network operations and management, and ossification. The impact
engineering activities performed by operators (such as determining differs depending on the activity, for example:
which parts of the path contribute delay, jitter or loss). While
this impact could, in many cases, be small, there are scenarios
where operators directly support particular services (e.g., to
troubleshoot issues relating to Quality of Service, QoS; the
ability to perform fast re-routing of critical traffic, or support
to mitigate the characteristics of specific radio links). The
more complex the underlying infrastructure the more important this
impact.
Open and Verifiable Network Data: Hiding transport protocol header Network Operations and Research: Observable transport headers enable
information can reduce the range of actors that can capture useful explicit measure and analysis protocol performance, network
measurement data. This limits the information sources available anomalies, and failure pathologies at any point along the Internet
to the Internet community to understand the operation of new path. In many cases, it is important to relate observations to
transport protocols, so preventing access to the information specific equipment/configurations or network segments.
necessary to inform design decisions and standardisation of the
new protocols and related operational practices.
The cooperating dependence of network, application, and host to Concealing transport header information makes performance/
provide communication performance on the Internet is uncertain behaviour unavailable to passive observers along the path,
when only endpoints (i.e., at user devices and within service Operators will be unable to use this information directly and may
platforms) can observe performance, and when performance cannot be turn to more ambitious ways to collect, estimate, or infer that
independently verified by all parties. The ability of other data. Operational practices aimed at guessing transport
stakeholders to review transport header traces can help develop parameters are out of scope for this document, and are only
deeper insight into performance and traffic contribution of mentioned here to recognize that encryption does not prevent
specific varients of a protocol. In the heterogeneous Internet, operators from attempting to apply practices that were used with
this helps extend the range of topologies, vendor equipment, and unencrypted transport headers.
traffic patterns that are evaluated.
Independently captured data is important to help ensure the health Confidentiality of the transport payload could be provided while
of the research and development communities. It can provide input leaving some, or all, transport headers unencrypted (or providing
and test scenarios to support the development of new transport this information in a network-layer extension), possibly with
protocol mechanisms, especially when this analysis can be based on authentication. This provides many of the privacy and security
the behaviour experienced in a diversity of deployed networks. benefits while supporting operations and research, but at the cost
of ossifying the exposed headers.
Independently verifiable performance metrics might also be Protection from Denial of Service: Observable transport headers
utilised to demonstrate regulatory compliance in some currently provide useful input to classify and detect anomalous
jurisdictions, and to provide a basis for informing design events (e.g., changes in application behaviour, distributed denial
decisions. of service attacks). For this application to be effective, this
needs to be able to uniquely disambiguate unwanted traffic.
The last point leads us to consider the impact of hiding transport Concealing transport header information would prevent separating
headers in the specification and development of protocols and anomalous traffic based on transport information. This could
standards. This has a potential impact on: result in less-efficient identification of unwanted traffic or
development of different methods (e.g. rate-limiting of
uncharacterised traffic). Additional mechanisms will need to be
introduced, such as heuristics to disambiguate any unwanted
traffic.
o Understanding Feature Interactions: An appropriate vantage point, Network Troubleshooting and Diagnostics: Observable transport
coupled with timing information about traffic flows, provides a headers can be used by operators to support network
valuable tool for benchmarking equipment, functions, and/or troubleshooting and diagnostics. A flow experiencing packet loss
configurations, and to understand complex feature interactions. or jitter looks like an unaffected flow when only observing
An inability to observe transport protocol information can limit network layer headers.
the ability to diagnose and explore interactions between features
at different protocol layers, a side-effect of not allowing a
choice of vantage point from which this information is observed.
o Supporting Common Specifications: Transmission Control Protocol Concealing transport header information eliminates the incentive
(TCP) is currently the predominant transport protocol used over for operators to troubleshoot, since they cannot interpret the
Internet paths. Its many variants have broadly consistent data. It can limit understanding of transport dynamics, such as
approaches to avoiding congestion collapse, and to ensuring the the impact of packet loss or latency on the flows, or localizing
stability of the Internet. Increased use of transport layer the network segment causing the packet loss or latency.
encryption can overcome ossification, allowing deployment of new Additional mechanisms will be needed to help reconstruct or
transports and different types of congestion control. This replace transport-level metrics for troubleshooting and
flexibility can be beneficial, but it can come at the cost of diagnostics. These can add complexity and operational costs
fragmenting the ecosystem. There is little doubt that developers (e.g., in deploying additional functions in equipment or adding
will try to produce high quality transports for their intended traffic overhead).
target uses, but it is not clear there are sufficient incentives
to ensure good practice that benefits the wide diversity of
requirements for the Internet community as a whole. Increased
diversity, and the ability to innovate without public scrutiny,
risks point solutions that optimise for specific needs, but
accidentally disrupt operations of/in different parts of the
network. The social contract that maintains the stability of the
Internet relies on accepting common specifications.
o Operational Practice: The network operations community relies on Network Traffic Analysis: Observable transport headers can support
being able to understand the pattern and requirements of traffic network traffic analysis to determine which transport protocols
passing over the Internet, both in aggregate and at the flow and features are being used across a network segment and to
level. These operational practices have developed based on the measure trends in the pattern of usage. For some applications
information available from unencrypted transport headers. If this end-to-end measurements/traces are sufficient, in other
information is only carried in encrypted transport headers, applications it is important to relate observations to specific
operators will not be able to use this information directly. If equipment/configurations or network segments.
operators still wish to use these practices, they may turn to more
ambitious ways of discovering this information. For example, if
an operator wants to know that traffic is audio traffic, and no
longer has access to Session Description Protocol (SDP) session
descriptions that would explicitly say a flow "is audio", the
operator might use heuristics to guess that short UDP packets with
regular spacing are carrying audio traffic. Operational practices
aimed at guessing transport parameters are out of scope for this
document, and are only mentioned here to recognize that encryption
may not prevent operators from attempting to apply the same
practices they used with unencrypted transport headers.
o Compliance: Published transport specifications allow operators and Concealing transport header information can make analysis harder
regulators to check compliance. This can bring assurance to those or impossible. This could impact the ability for an operator to
operating networks, often avoiding the need to deploy complex anticipate the need for network upgrades and roll-out. It can
techniques that routinely monitor and manage Internet traffic also impact the on-going traffic engineering activities performed
flows (e.g., avoiding the capital and operational costs of by operators (such as determining which parts of the path
deploying flow rate-limiting and network circuit-breaker methods contribute delay, jitter or loss). While this impact could, in
[RFC8084]). When it is not possible to observe transport header many cases, be small, there are scenarios where operators directly
information, methods are still needed to confirm that the traffic support particular services (e.g., to explore issues relating to
produced conforms to the expectations of the operator or Quality of Service, QoS; the ability to perform fast re-routing of
developer. critical traffic, or support to mitigate the characteristics of
specific radio links). The more complex the underlying
infrastructure the more important this impact.
o Restricting research and development: Hiding transport information Open and Verifiable Network Data: Observable transport headers can
can impede independent research into new mechanisms, measurement provide open and verifiable measurement data. The ability of
of behaviour, and development initiatives. Experience shows that other stake holders to review transport header traces helps
transport protocols are complicated to design and complex to develop insight into performance and traffic contribution of
deploy, and that individual mechanisms need to be evaluated while specific variants of a protocol. Independently observed data is
considering other mechanisms, across a broad range of network important to help ensure the health of the research and
topologies and with attention to the impact on traffic sharing the development communities.
capacity. If this results in reduced availability of open data,
it could eliminate the independent self-checks to the
standardisation process that have previously been in place from
research and academic contributors (e.g., the role of the IRTF
Internet Congestion Control Research Groups (ICCRG) and research
publications in reviewing new transport mechanisms and assessing
the impact of their experimental deployment)
In summary, there are trade-offs. On the one hand, transport Concealing transport header information can reduce the range of
protocol designers have often ignored the implications of whether the actors that observe useful data. This would limit the information
information in transport header fields can or will be used by in- sources available to the Internet community to understand the
network devices, and the implications this places on protocol operation of new transport protocols, reducing information to
evolution. This motivates a design that provides confidentiality of inform design decisions and standardisation of the new protocols
the header information. On the other hand, it can be expected that a and related operational practices.
lack of visibility of transport header information can impact the
ways that protocols are deployed, standardised, and their operational
support.
To achieve stable Internet operations the IETF transport community Compliance: Observable transport headers coupled with published
has to date relied heavily on measurement and insights of the network transport specifications allow operators and regulators to check
operations community to understand the trade-offs, and to inform compliance. Independently verifiable performance metrics can also
selection of appropriate mechanisms, to ensure a safe, reliable, and be utilised to demonstrate regulatory compliance in some
robust Internet (e.g., [RFC1273],[RFC2914]). jurisdictions, and as a basis for informing design decisions.
This can bring assurance to those operating networks, often
avoiding the need to deploy 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]).
The choice of whether future transport protocols encrypt their When transport header information is concealed, it is not possible
protocol headers therefore needs to be taken based not solely on to observe transport header information. Methods are still needed
security and privacy considerations, but also taking into account the to confirm that the traffic produced conforms to the expectations
impact on operations, standards, and research. As [RFC7258] notes: of the operator or developer.
"Making networks unmanageable to mitigate [pervasive monitoring] is
not an acceptable outcome, but ignoring [pervasive monitoring] would
go against the consensus documented here. An appropriate balance
will emerge over time as real instances of this tension are
considered." This balance between information exposed and
information concealed ought to be carefully considered when
specifying new transport protocols.
3. Current uses of Transport Headers within the Network 3. Current uses of Transport Headers within the Network
Despite transport headers having end-to-end meaning, some of these Despite transport headers having end-to-end meaning, some of these
transport headers have come to be used in various ways within the transport headers have come to be used in various ways within the
Internet. In response to pervasive monitoring [RFC7624] revelations Internet. In response to pervasive monitoring [RFC7624] revelations
and the IETF consensus that "Pervasive Monitoring is an Attack" and the IETF consensus that "Pervasive Monitoring is an Attack"
[RFC7258], efforts are underway to increase encryption of Internet [RFC7258], efforts are underway to increase encryption of Internet
traffic. Applying confidentiality to transport header fields would traffic. Applying confidentiality to transport header fields would
affect how protocol information is used [RFC8404]. To understand affect how protocol information is used [RFC8404]. To understand
skipping to change at page 11, line 19 skipping to change at page 9, line 27
protocol version information or connection setup information; protocol version information or connection setup information;
o The location and syntax of any observed transport headers need to o The location and syntax of any observed transport headers need to
be known. IETF transport protocols can specify this information. be known. IETF transport protocols can specify this information.
The following subsections describe various ways that observable The following subsections describe various ways that observable
transport information has been utilised. transport information has been utilised.
3.1.1. Flow Identification 3.1.1. Flow Identification
Transport protocol header information (together with information in Flow identification is a common function. For example, performed by
measurement activities, QoS classification, firewalls, Denial of
Service, DOS, prevention. This becomes more complex and less easily
achieved when multiplexing is used at or above the transport layer.
Observable transport header information (together with information in
the network header), has been used to identify a flow and the the network header), has been used to identify a flow and the
connection state of the flow, together with the protocol options connection state of the flow, together with the protocol options
being used. In some usages, a low-numbered (well-known) transport being used. In some usages, a low-numbered (well-known) transport
port number has been used to identify a protocol (although port port number has been used to identify a protocol (although port
information alone is not sufficient to guarantee identification of a information alone is not sufficient to guarantee identification of a
protocol, since applications can use arbitrary ports, multiple protocol, since applications can use arbitrary ports, multiple
sessions can be multiplexed on a single port, and ports can be re- sessions can be multiplexed on a single port, and ports can be re-
used by subsequent sessions). used by subsequent sessions).
Transport protocols, such as TCP and the Stream Control Transport Transport protocols, such as TCP and the Stream Control Transport
Protocol (SCTP) specify a standard base header that includes sequence Protocol (SCTP) specify a standard base header that includes sequence
number information and other data, with the possibility to negotiate number information and other data, with the possibility to negotiate
additional headers at connection setup, identified by an option additional headers at connection setup, identified by an option
number in the transport header. UDP-based protocols can use, but number in the transport header. UDP-based protocols can use, but
sometimes do not use, well-known port numbers. Some flows can sometimes do not use, well-known port numbers. Some flows can
instead be identified by observing signalling protocol data (e.g., instead be identified by observing signalling protocol data (e.g.,
[RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic
numbers placed in the first byte(s) of the datagram payload numbers placed in the first byte(s) of the datagram payload
[RFC7983]. [RFC7983].
Flow identification is a common function. For example, performed by Concealing transport header information can remove information used
measurement activities, QoS classification, firewalls, Denial of to classify flows by passive observers along the path and operators
Service, DOS, prevention. It becomes more complex and less easily will be unable to use this information directly. Careful use of the
achieved when multiplexing is used at or above the transport layer. network layer features can help address provide similar information
in the case where the network is unable to inspect transport protocol
headers. Operators could also turn to more ambitious ways to
collect, estimate, or infer that data (for example heuristics based
on the analysis of traffic patterns). For example, an operator no
longer has access to Session Description Protocol (SDP) session
descriptions to classify a flow carry as audio traffic. Instead, the
operator might use heuristics to infer that short UDP packets with
regular spacing carry audio traffic. Operational practices aimed at
guessing transport parameters are out of scope for this document, and
are only mentioned here to recognize that encryption does not prevent
operators from attempting to apply practices that were used with
unencrypted transport headers.
Confidentiality of the transport payload could be provided while
leaving some, or all, transport headers unencrypted (or providing
this information in a network-layer extension), possibly with
authentication. This provides many of the privacy and security
benefits while supporting operations and research, but at the cost of
ossifying the exposed headers.
3.1.2. Metrics derived from Transport Layer Headers 3.1.2. Metrics derived from Transport Layer Headers
Some actors manage their portion of the Internet by characterizing Observable transport headers enable explicit measure and analysis
the performance of link/network segments. Passive monitoring can protocol performance, network anomalies, and failure pathologies at
observe traffic that does not encrypt the transport header any point along the Internet path. Some actors manage their portion
information to make inferences from transport headers to derive these of the Internet by characterizing the performance of link/network
performance metrics. A variety of open source and commercial tools segments. Passive monitoring can observe traffic that does not
have been deployed that utilise this information. The following encrypt the transport header information to make inferences from
metrics can be derived from transport header information: transport headers to derive these performance metrics.
A variety of open source and commercial tools have been deployed that
utilise this information. The following metrics can be derived from
transport header information:
Traffic Rate and Volume: Header information (e.g., sequence number Traffic Rate and Volume: Header information (e.g., sequence number
and packet size) allows derivation of volume measures per- and packet size) allows derivation of volume measures per-
application, to characterise the traffic that uses a network application, to characterise the traffic that uses a network
segment or the pattern of network usage. This can be measured per segment or the pattern of network usage. This can be measured per
endpoint or for an aggregate of endpoints (e.g., by an operator to endpoint or for an aggregate of endpoints (e.g., to assess
assess subscriber usage). It can also be used to trigger subscriber usage). It can also be used to trigger measurement-
measurement-based traffic shaping and to implement QoS support based traffic shaping and to implement QoS support within the
within the network and lower layers. Volume measures can be network and lower layers. Volume measures can be valuable for
valuable for capacity planning and providing detail of trends, capacity planning and providing detail of trends, rather than the
rather than the volume per subscriber. volume per subscriber.
Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g.,
from transport sequence numbers) and has been used as a metric for from transport sequence numbers) and has been used as a metric for
performance assessment and to characterise transport behaviour. performance assessment and to characterise transport behaviour.
Understanding the location and root cause of loss can help an Understanding the location and root cause of loss can help an
operator determine whether this requires corrective action. operator determine whether this requires corrective action.
Network operators have used the variation in patterns of loss as a Network operators have used the variation in patterns of loss as a
key performance metric, utilising this to detect changes in the key performance metric, utilising this to detect changes in the
offered service. offered service.
There are various causes of loss, including corruption of link There are various causes of loss, including corruption of link
frames (e.g., interference on a radio link), buffer overflow frames (e.g., interference on a radio link), buffer overflow
(e.g., due to congestion), policing (traffic management), buffer (e.g., due to congestion), policing (traffic management), buffer
management (e.g., Active Queue Management, AQM [RFC7567]), and management (e.g., Active Queue Management, AQM [RFC7567]), and
inadequate provision of traffic pre-emption. Understanding flow inadequate provision of traffic preemption. Understanding flow
loss rate requires either maintaining per flow packet counters or loss rate requires either maintaining per flow packet counters or
by observing sequence numbers in transport headers. Loss can be by observing sequence numbers in transport headers. Loss can be
monitored at the interface level by devices in the network. It is monitored at the interface level by devices in the network. It is
often valuable to understand the conditions under which packet often valuable to understand the conditions under which packet
loss occurs. This usually requires relating loss to the traffic loss occurs. This usually requires relating loss to the traffic
flowing on the network node/segment at the time of loss. flowing on the network node/segment at the time of loss.
Observation of transport feedback information (e.g., RTP Control Observation of transport feedback information (e.g., RTP Control
Protocol (RTCP) reception reports [RFC3550], TCP SACK blocks) can Protocol (RTCP) reception reports [RFC3550], TCP SACK blocks) can
increase understanding of the impact of loss and help identify increase understanding of the impact of loss and help identify
cases where loss could have been wrongly identified, or the cases where loss could have been wrongly identified, or the
transport did not require the lost packet. It is sometimes more transport did not require the lost packet. It is sometimes more
helpful to understand the pattern of loss, than the loss rate, helpful to understand the pattern of loss, than the loss rate,
because losses can often occur as bursts, rather than randomly- because losses can often occur as bursts, rather than randomly-
timed events. timed events.
Throughput and Goodput: The throughput achieved by a flow can be Throughput and Goodput: The throughput achieved by a flow can be
determined even when a flow is encrypted, providing the individual determined even when transport header information is concealed,
flow can be identified. Goodput [RFC7928] is a measure of useful providing the individual flow can be identified. Goodput
data exchanged (the ratio of useful/total volume of traffic sent [RFC7928] is a measure of useful data exchanged (the ratio of
by a flow). This requires ability to differentiate loss and useful/total volume of traffic sent by a flow). This requires
retransmission of packets (e.g., by observing packet sequence ability to differentiate loss and retransmission of packets (e.g.,
numbers in the TCP or the Real-time Transport Protocol, RTP, by observing packet sequence numbers in the TCP or the Real-time
headers [RFC3550]). Transport Protocol, RTP, headers [RFC3550]).
Latency: Latency is a key performance metric that impacts Latency: Latency is a key performance metric that impacts
application response time and user-perceived response time. It application response time and user-perceived response time. It
often indirectly impacts throughput and flow completion time. often indirectly impacts throughput and flow completion time.
Latency determines the reaction time of the transport protocol Latency determines the reaction time of the transport protocol
itself, impacting flow setup, congestion control, loss recovery, itself, impacting flow setup, congestion control, loss recovery,
and other transport mechanisms. The observed latency can have and other transport mechanisms. The observed latency can have
many components [Latency]. Of these, unnecessary/unwanted queuing many components [Latency]. Of these, unnecessary/unwanted queuing
in network buffers has often been observed as a significant factor in network buffers has often been observed as a significant factor
[bufferbloat]. Once the cause of unwanted latency has been [bufferbloat]. Once the cause of unwanted latency has been
identified, this can often be eliminated. identified, this can often be eliminated.
To measure latency across a part of a path, an observation point To measure latency across a part of a path, an observation point
can measure the experienced round trip time (RTT) using packet [RFC7799] can measure the experienced round trip time (RTT) using
sequence numbers, and acknowledgements, or by observing header packet sequence numbers, and acknowledgements, or by observing
timestamp information. Such information allows an observation header timestamp information. Such information allows an
point in the network to determine not only the path RTT, but also observation point in the network to determine not only the path
to measure the upstream and downstream contribution to the RTT. RTT, but also to measure the upstream and downstream contribution
This could be used to locate a source of latency, e.g., by to the RTT. This could be used to locate a source of latency,
observing cases where the median RTT is much greater than the e.g., by observing cases where the median RTT is much greater than
minimum RTT for a part of a path. the minimum RTT for a part of a path.
The service offered by network operators can benefit from latency The service offered by network operators can benefit from latency
information to understand the impact of deployment and tune information to understand the impact of deployment and tune
deployed services. Latency metrics are key to evaluating and deployed services. Latency metrics are key to evaluating and
deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
could identify excessively large buffers, indicating where to could identify excessively large buffers, indicating where to
deploy or configure AQM. An AQM method is often deployed in deploy or configure AQM. An AQM method is often deployed in
combination with other techniques, such as scheduling [RFC7567] combination with other techniques, such as scheduling [RFC7567]
[RFC8290] and although parameter-less methods are desired [RFC8290] and although parameter-less methods are desired
skipping to change at page 14, line 38 skipping to change at page 13, line 24
maintained packet order on a packet-by-packet basis [RFC4737] and maintained packet order on a packet-by-packet basis [RFC4737] and
[RFC5236]. [RFC5236].
Techniques for measuring reordering typically observe packet Techniques for measuring reordering typically observe packet
sequence numbers. Some protocols provide in-built monitoring and sequence numbers. Some protocols provide in-built monitoring and
reporting functions. Transport fields in the RTP header [RFC3550] reporting functions. Transport fields in the RTP header [RFC3550]
[RFC4585] can be observed to derive traffic volume measurements [RFC4585] can be observed to derive traffic volume measurements
and provide information on the progress and quality of a session and provide information on the progress and quality of a session
using RTP. As with other measurement, metadata is often needed to using RTP. As with other measurement, metadata is often needed to
understand the context under which the data was collected, understand the context under which the data was collected,
including the time, observation point, and way in which metrics including the time, observation point [RFC7799], and way in which
were accumulated. The RTCP protocol directly reports some of this metrics were accumulated. The RTCP protocol directly reports some
information in a form that can be directly visible in the network. of this information in a form that can be directly visible in the
A user of summary measurement data needs to trust the source of network. A user of summary measurement data needs to trust the
this data and the method used to generate the summary information. source of this data and the method used to generate the summary
information.
The above passively monitor transport protocol headers to derive This information can support network operations, e.g. to inform
metrics about network layer performance useful for operation and capacity planning and assist in determining the need for equipment
management of a network. and/or configuration changes by network operators. It can also
inform Internet engineering activities by informing the development
of new protocols, methodologies, and procedures.
3.1.3. Transport use of Network Layer Header Fields 3.1.3. Transport use of Network Layer Header Fields
Information from the transport protocol can be used by a multi-field Information from the transport protocol can be used by a multi-field
classifier as a part of policy framework. Policies are commonly used classifier as a part of policy framework. Policies are commonly used
for management of the QoS or Quality of Experience (QoE) in resource- for management of the QoS or Quality of Experience (QoE) in resource-
constrained networks and by firewalls that use the information to constrained networks and by firewalls that use the information to
implement access rules (see also section 2.2.2 of [RFC8404]). implement access rules (see also section 2.2.2 of [RFC8404]).
Network-layer classification methods that rely on a multi-field Network-layer classification methods that rely on a multi-field
classifier (e.g. Inferring QoS from the 5-tuple or choice of classifier (e.g. Inferring QoS from the 5-tuple or choice of
skipping to change at page 16, line 40 skipping to change at page 15, line 30
observation (Section 2.5 of [RFC8087]). Interpreting the marking observation (Section 2.5 of [RFC8087]). Interpreting the marking
behaviour (i.e., assessing congestion and diagnosing faults) behaviour (i.e., assessing congestion and diagnosing faults)
requires context from the transport layer (such as path RTT). requires context from the transport layer (such as path RTT).
AQM and ECN offer a range of algorithms and configuration options. AQM and ECN offer a range of algorithms and configuration options.
Tools therefore need to be available to network operators and Tools therefore need 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].
Careful use of the network layer features can therefore help address When transport headers are concealed, operators will be unable to use
some of the reasons why the network inspects transport protocol this information directly. Careful use of the network layer features
headers. can help address provide similar information in the case where the
network is unable to inspect transport protocol headers.
3.2. Transport Measurement 3.2. Transport Measurement
The common language between network operators and application/content The common language between network operators and application/content
providers/users is packet transfer performance at a layer that all providers/users is packet transfer performance at a layer that all
can view and analyse. For most packets, this has been the transport can view and analyse. For most packets, this has been the transport
layer, until the emergence of QUIC, with the obvious exception of layer, until the emergence of QUIC, with the obvious exception of
Virtual Private Networks (VPNs) and IPsec. Virtual Private Networks (VPNs) and IPsec.
When encryption conceals more layers in each packet, people seeking When encryption conceals more layers in each packet, people seeking
skipping to change at page 17, line 21 skipping to change at page 16, line 11
access). It remains to be seen whether more complex inferences can access). It remains to be seen whether more complex inferences can
be mastered to produce the same monitoring accuracy (see section be mastered to produce the same monitoring accuracy (see section
2.1.1 of [RFC8404]). 2.1.1 of [RFC8404]).
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 required to interpret this data to answer questions about often required 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/device under
evaluation. evaluation [RFC7799].
Packet sampling techniques are used to scale the processing involved Packet sampling techniques are used to scale the processing involved
in observing packets on high rate links. This exports only the in observing packets on high rate links. This exports only the
packet header information of (randomly) selected packets. The packet header information of (randomly) selected packets. The
utility of these measurements depends on the type of bearer and utility of these measurements depends on the type of bearer and
number of mechanisms used by network devices. Simple routers are number of mechanisms used by network devices. Simple routers are
relatively easy to manage, a device with more complexity demands relatively easy to manage, 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.
skipping to change at page 18, line 34 skipping to change at page 17, line 24
the impact of changes in introducing a new transport protocol the impact of changes in introducing a new transport protocol
mechanism). This increases the dependency on other indirect sources mechanism). This increases the dependency on other indirect sources
of information to inform planning and provisioning. of information to inform planning and provisioning.
3.2.3. Service Performance Measurement 3.2.3. Service Performance Measurement
Traffic measurements (e.g., traffic volume, loss, latency) can be Traffic measurements (e.g., traffic volume, loss, latency) can be
used by various actors to help analyse the performance offered to the used by various actors to help analyse the performance offered to the
users of a network segment, and to inform operational practice. users of a network segment, and to inform operational practice.
While active measurements may be used within a network, passive While active measurements (see section 3.4 of [RFC7799]) may be used
measurements can have advantages in terms of eliminating unproductive within a network, passive measurements (see section 3.6 of [RFC7799]
test traffic, reducing the influence of test traffic on the overall ) can have advantages in terms of eliminating unproductive test
traffic, reducing the influence of test traffic on the overall
traffic mix, and the ability to choose the point of observation (see traffic mix, and the ability to choose the point of observation (see
Section 3.2.1). However, passive measurements can rely on observing Section 3.2.1). However, passive measurements can rely on observing
transport headers which is not possible if those headers are transport headers which is not possible if those headers are
encrypted. encrypted.
3.2.4. Measuring Transport to Support Network Operations 3.2.4. Measuring Transport to Support Network Operations
Information provided by tools observing transport headers can help Information provided by tools observing transport headers can help
determine whether mechanisms are needed in the network to prevent determine whether mechanisms are needed in the network to prevent
flows from acquiring excessive network capacity. Operators can flows from acquiring excessive network capacity. Operators can
skipping to change at page 20, line 47 skipping to change at page 19, line 39
rather than relying on traditional tools. This can impact the rather than relying on traditional tools. This can impact the
ability of the operator to respond to faults, it could require ability of the operator to respond to faults, it could require
reliance on endpoint diagnostic tools or user involvement in reliance on endpoint diagnostic tools or user involvement in
diagnosing and troubleshooting unusual use cases or non-trivial diagnosing and troubleshooting unusual use cases or non-trivial
problems. A key need here is for tools to provide useful information problems. A key need here is for tools to provide useful information
during network anomalies (e.g., significant reordering, high or during network anomalies (e.g., significant reordering, high or
intermittent loss). intermittent loss).
Measurements can be used to monitor the health of a portion of the Measurements can be used to monitor the health of a portion of the
Internet, to provide early warning of the need to take action. They Internet, to provide early warning of the need to take action. They
can assist in debugging and diagnosing the root causes of faults that can assist in setting buffer sizes, debugging and diagnosing the root
concern a particular user's traffic. They can also be used to causes of faults that concern a particular user's traffic. They can
support post-mortem investigation after an anomaly to determine the also be used to support post-mortem investigation after an anomaly to
root cause of a problem. determine the root cause of a problem.
In some case, measurements could involve active injection of test In some cases, measurements could involve active injection of test
traffic to perform a measurement. However, most operators do not traffic to perform a measurement. However, most operators do not
have access to user equipment, therefore the point of test is have access to user equipment, therefore the point of test is
normally different from the transport endpoint. Injection of test normally different from the transport endpoint. Injection of test
traffic can incur an additional cost in running such tests (e.g., the traffic can incur an additional cost in running such tests (e.g., the
implications of capacity tests in a mobile network are obvious). implications of capacity tests in a mobile network are obvious).
Some active measurements (e.g., response under load or particular Some active measurements [RFC7799] (e.g., response under load or
workloads) perturb other traffic, and could require dedicated access particular workloads) perturb other traffic, and could require
to the network segment. An alternative approach is to use in-network dedicated access to the network segment. An alternative approach is
techniques that observe transport packet headers added while traffic to use in-network techniques that observe transport packet headers
traverses an operational network to make the measurements. These added while traffic traverses an operational network to make the
measurements do not require the cooperation of an endpoint. measurements. These measurements do not require the cooperation of
an endpoint.
In other cases, measurement involves dissecting network traffic In other cases, measurement involves dissecting network traffic
flows. The observed transport layer information can help identify flows. The observed transport layer information can help identify
whether the link/network tuning is effective and alert to potential whether the link/network tuning is effective and alert to potential
problems that can be hard to derive from link or device measurements problems that can be hard to derive from link or device measurements
alone. The design trade-offs for radio networks are often very alone. The design trade-offs for radio networks are often very
different from those of wired networks. A radio-based network (e.g., different from those of wired networks. A radio-based network (e.g.,
cellular mobile, enterprise WiFi, satellite access/back-haul, point- cellular mobile, enterprise WiFi, satellite access/back-haul, point-
to-point radio) has the complexity of a subsystem that performs radio to-point radio) has the complexity of a subsystem that performs radio
resource management,s with direct impact on the available capacity, resource management,s with direct impact on the available capacity,
and potentially loss/reordering of packets. The impact of the and potentially loss/reordering of packets. The impact of the
pattern of loss and congestion, differs for different traffic types, pattern of loss and congestion, differs for different traffic types,
correlation with propagation and interference can all have correlation with propagation and interference can all have
significant impact on the cost and performance of a provided service. significant impact on the cost and performance of a provided service.
The need for this type of information is expected to increase as The need for this type of information is expected to increase as
operators bring together heterogeneous types of network equipment and operators bring together heterogeneous types of network equipment and
seek to deploy opportunistic methods to access radio spectrum. seek to deploy opportunistic methods to access radio spectrum.
A flow that conceals its transport header information could imply
"don't touch" to some operators. This could limit a trouble-shooting
response to "can't help, no trouble found".
3.4. Header Compression 3.4. Header Compression
Header compression saves link bandwidth by compressing network and Header compression saves link bandwidth by compressing network and
transport protocol headers on a per-hop basis. It was widely used transport protocol headers on a per-hop basis. It was widely used
with low bandwidth dial-up access links, and still finds application with low bandwidth dial-up access links, and still finds application
on wireless links that are subject to capacity constraints. Header on wireless links that are subject to capacity constraints. Header
compression has been specified for use with TCP/IP and RTP/UDP/IP compression has been specified for use with TCP/IP and RTP/UDP/IP
flows [RFC2507], [RFC2508], [RFC4995]. flows [RFC2507], [RFC2508], [RFC4995].
While it is possible to compress only the network layer headers, While it is possible to compress only the network layer headers,
skipping to change at page 30, line 29 skipping to change at page 29, line 29
At the time of writing, the additional operational cost of using At the time of writing, the additional operational cost of using
encrypted transports is not yet well understood. Design trade-offs encrypted transports is not yet well understood. Design trade-offs
could mitigate these costs by explicitly choosing to expose selected could mitigate these costs by explicitly choosing to expose selected
information (e.g., header invariants and the spin-bit in information (e.g., header invariants and the spin-bit in
QUIC[I-D.ietf-quic-transport]), the specification of common log QUIC[I-D.ietf-quic-transport]), the specification of common log
formats and development of alternative approaches. formats and development of alternative approaches.
6.5. Impact on Research, Development and Deployment 6.5. Impact on Research, Development and Deployment
Measurement has a critical role in the design of transport protocol Evolution and the ability to understand (measure) the impact need to
mechanisms and their acceptance by the wider community (e.g., as a proceed hand-in-hand. Observable transport headers can provide open
method to judge the safety for Internet deployment) and is and verifiable measurement data. Observation of pathologies has a
increasingly being used to inform design decisions in networking critical role in the design of transport protocol mechanisms and
research, during development of new mechanisms and protocols and in development of new mechanisms and protocols. This helps
standardisation. Observation of pathologies are also important in
understanding the interactions between cooperating protocols and understanding the interactions between cooperating protocols and
network mechanism, the implications of sharing capacity with other network mechanism, the implications of sharing capacity with other
traffic and the impact of different patterns of usage. 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.
Evolution and the ability to understand (measure) the impact need to In development of new transport protocol mechanisms, attention needs
proceed hand-in-hand. Attention needs to be paid to the expected to be paid to the expected scale of deployment. Whatever the
scale of deployment of new protocols and protocol mechanisms. mechanism, experience has shown that it is often difficult to
Whatever the mechanism, experience has shown that it is often correctly implement combination of mechanisms [RFC8085]. Mechanisms
difficult to correctly implement combination of mechanisms [RFC8085]. often evolve as a protocol matures, or in response to changes in
These mechanisms therefore typically evolve as a protocol matures, or network conditions, changes in network traffic or changes to
in response to changes in network conditions, changes in network application usage. Analysis is especially valuable when based on the
traffic or changes to application usage. behaviour experienced across a range of topologies, vendor equipment,
and traffic patterns.
New transport protocol formats are expected to facilitate an New transport protocol formats are expected to facilitate an
increased pace of transport evolution, and with it the possibility to increased pace of transport evolution, and with it the possibility to
experiment with and deploy a wide range of protocol mechanisms. experiment with and deploy a wide range of protocol mechanisms.
There has been recent interest in a wide range of new transport There has been recent interest in a wide range of new transport
methods, e.g., Larger Initial Window, Proportional Rate Reduction methods, e.g., Larger Initial Window, Proportional Rate Reduction
(PRR), congestion control methods based on measuring bottleneck (PRR), congestion control methods based on measuring bottleneck
bandwidth and round-trip propagation time, the introduction of AQM bandwidth and round-trip propagation time, the introduction of AQM
techniques and new forms of ECN response (e.g., Data Centre TCP, techniques and new forms of ECN response (e.g., Data Centre TCP,
DCTP, and methods proposed for L4S).The growth and diversity of DCTP, and methods proposed for L4S).The growth and diversity of
applications and protocols using the Internet also continues to applications and protocols using the Internet also continues to
expand. For each new method or application it is desirable to build expand. For each new method or application it is desirable to build
a body of data reflecting its behaviour under a wide range of a body of data reflecting its behaviour under a wide range of
deployment scenarios, traffic load, and interactions with other deployment scenarios, traffic load, and interactions with other
deployed/candidate methods. deployed/candidate methods.
Open standards motivate a desire for this evaluation to include Concealing transport header information could reduce the range of
independent observation and evaluation of performance data, which in actors that can observe useful data. This would limit the
turn suggests control over where and when measurement samples are information sources available to the Internet community to understand
collected. This requires consideration of the appropriate balance the operation of new transport protocols, reducing information to
between encrypting all and no transport information. inform design decisions and standardisation of the new protocols and
related operational practices. 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 over 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 information.
7. Conclusions 7. Conclusions
Confidentiality and strong integrity checks have properties that are Confidentiality and strong integrity checks have properties that are
being incorporated into new protocols and that have important being incorporated into new protocols and that have important
benefits. The pace of development of transports using the WebRTC benefits. The pace of development of transports using the WebRTC
data channel and the rapid deployment of the QUIC transport protocol data channel and the rapid deployment of the QUIC transport protocol
can both be attributed to using the combination of UDP as a substrate can both be attributed to using the combination of UDP as a substrate
while providing confidentiality and authentication of the while providing confidentiality and authentication of the
encapsulated transport headers and payload. encapsulated transport headers and payload.
skipping to change at page 32, line 17 skipping to change at page 31, line 39
resulting in traffic causing traffic to be treated inappropriately resulting in traffic causing traffic to be treated inappropriately
(e.g., rate limiting because of being incorrectly classified/ (e.g., rate limiting because of being incorrectly classified/
monitored). monitored).
There are benefits in exposing consistent information to the network There are benefits in exposing consistent information to the network
that avoids traffic being inappropriately classified and then that avoids traffic being inappropriately classified and then
receiving a default treatment by the network. The flow label and receiving a default treatment by the network. The flow label and
DSCP fields provide examples of how transport information can be made DSCP fields provide examples of how transport information can be made
available for network-layer decisions. Extension headers could also available for network-layer decisions. Extension headers could also
be used to carry transport information that can inform network-layer be used to carry transport information that can inform network-layer
decisions. decisions. Other information may also be useful to various
stakeholder (as described in earlier sections), however this document
does not make recommendations about what information should be
exposed, to whom it should be observable, or how this will be
achieved.
As part of a protocol's design, the community needs to weigh the To achieve stable Internet operations the IETF transport community
benefits of ossifying common headers versus the potential demerits of has to date relied heavily on measurement and insights of the network
exposing specific information that could be observed along the operations community to understand the trade-offs, and to inform
network path, to ensure network operators have appropriate tools to selection of appropriate mechanisms, to ensure a safe, reliable, and
manage their networks and enable stable operation of the Internet as robust Internet (e.g., [RFC1273],[RFC2914]).
new protocols are deployed.
There are trade-offs and implications of increased use of encryption.
Transport protocol designers have often ignored the implications of
whether the information in transport header fields can or will be
used by in-network devices, and the implications this places on
protocol evolution. This motivates a design that provides
confidentiality of the header information. It can be expected that a
lack of visibility of transport header information can impact the
ways that protocols are deployed, standardised, and their operational
support. The impact of hiding transport headers therefore needs to
be considered in the specification and development of protocols and
standards. This has a potential impact on the way in which the IRTF
and IETF develop new protocols, specifications, and guidelines:
o Coexistence of Transport and Network Device Protocols/
Configuration: Transmission Control Protocol (TCP) is currently
the predominant transport protocol used over Internet paths. Its
many variants have broadly consistent approaches to avoiding
congestion collapse, and to ensuring the stability of the
Internet. Increased use of transport layer encryption can
overcome ossification, allowing deployment of new transports and
different types of congestion control. This flexibility can be
beneficial, but it can come at the cost of fragmenting the
ecosystem. There is little doubt that developers will try to
produce high quality transports for their intended target uses,
but it is not yet clear there are sufficient incentives to ensure
good practice that benefits the wide diversity of requirements for
the Internet community as a whole.
o Supporting Common Specifications: Common open specifications can
stimulate engagement by developers, users, and researchers.
Increased diversity, and the ability to innovate without public
scrutiny, risks point solutions that optimise for specific needs,
but accidentally disrupt operations of/in different parts of the
network. The social contract that maintains the stability of the
Internet relies on accepting common interworking specifications.
o Benchmarking and Understanding Feature Interactions: An
appropriate vantage point for observation, coupled with timing
information about traffic flows, provides a valuable tool for
benchmarking network devices, endpoint stacks, functions, and/or
configurations. This can also help understand complex feature
interactions. An inability to observe transport protocol
information can limit the ability to diagnose and explore
interactions between features at different protocol layers, a
side-effect of not allowing a choice of vantage point from which
this information is observed. New approaches need to be
developed.
o Operational Practice: The network operations community relies on
being able to understand the pattern and requirements of traffic
passing over the Internet, both in aggregate and at the flow
level. These operational practices have developed based on the
information available from unencrypted transport headers. The
iETF supports this activity by developing operations and
management specifications, interface specifications, and
associated Best Current Practice (BCP) specifications. Concealing
transport header information impacts current practice and demand
new specifications.
o Research and Development: Concealing transport information can
impede independent research into new mechanisms, measurement of
behaviour, and development initiatives. Experience shows that
transport protocols are complicated to design and complex to
deploy, and that individual mechanisms need to be evaluated while
considering other mechanisms, across a broad range of network
topologies and with attention to the impact on traffic sharing the
capacity. If this results in reduced availability of open data,
it could eliminate the independent self-checks to the
standardisation process that have previously been in place from
research and academic contributors (e.g., the role of the IRTF
Internet Congestion Control Research Groups (ICCRG) and research
publications in reviewing new transport mechanisms and assessing
the impact of their experimental deployment).
The choice of whether future transport protocols encrypt their
protocol headers needs to be taken based not solely on security and
privacy considerations, but also taking into account the impact on
operations, standards, and research. As [RFC7258] notes: "Making
networks unmanageable to mitigate (pervasive monitoring) is not an
acceptable outcome, but ignoring (pervasive monitoring) would go
against the consensus documented here."
As part of a protocol's design, the community therefore needs to
weigh the benefits of ossifying common headers versus the potential
demerits of exposing specific information that could be observed
along the network path, to ensure network operators, researchers and
other stakeholders have appropriate tools to manage their networks
and enable stable operation of the Internet as new protocols are
deployed. An appropriate balance will emerge over time as real
instances of this tension are considered [RFC7258]. This balance
between information exposed and information concealed ought to be
carefully considered when specifying new transport protocols.
8. 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 in transport protocols. Issues relating to security are discussed in
the various sections of the document. the various sections of the 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
skipping to change at page 34, line 14 skipping to change at page 35, line 34
Open standards motivate a desire for this evaluation to include Open standards motivate a desire for this evaluation to include
independent observation and evaluation of performance data, which in independent observation and evaluation of performance data, which in
turn suggests control over where and when measurement samples are turn suggests control over where and when measurement samples are
collected. This requires consideration of the appropriate balance collected. This requires consideration of the appropriate balance
between encrypting all and no transport information. Open data, and between encrypting all and no transport information. Open data, and
accessibility to tools that can help understand trends in application accessibility to tools that can help understand trends in application
deployment, network traffic and usage patterns can all contribute to deployment, network traffic and usage patterns can all contribute to
understanding security challenges. understanding security challenges.
The Security and Privacy Considerations in the Framework for Large-
Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain
considerations for Active and Passive measurement techniques and
supporting material on measurement context.
9. IANA Considerations 9. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
10. 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, and other members of the TSVWG for their comments and feedback. Wood, Thomas Fossati, and other members of the 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.The research and innovation programme under grant agreement No 688421.The
opinions expressed and arguments employed reflect only the authors' opinions expressed and arguments employed reflect only the authors'
view. The European Commission is not responsible for any use that view. The European Commission is not responsible for any use that
may be made of that information. may be made of that information.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
skipping to change at page 39, line 25 skipping to change at page 40, line 43
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6 "Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872, Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016, DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>. <https://www.rfc-editor.org/info/rfc7872>.
[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and
D. Ros, "Characterization Guidelines for Active Queue D. Ros, "Characterization Guidelines for Active Queue
Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July
2016, <https://www.rfc-editor.org/info/rfc7928>. 2016, <https://www.rfc-editor.org/info/rfc7928>.
skipping to change at page 43, line 28 skipping to change at page 44, line 28
o Updated section 6 and added more explanation of impact on o Updated section 6 and added more explanation of impact on
operators. operators.
o Other comments addressed. o Other comments addressed.
-05 Editorial pass and minor corrections noted on TSVWG list. -05 Editorial pass and minor corrections noted on TSVWG list.
-06 Updated conclusions and minor corrections. Responded to request -06 Updated conclusions and minor corrections. Responded to request
to add OAM discussion to Section 6.1. to add OAM discussion to Section 6.1.
-07 Addressed feedback from Ruediger and Thomas.
Section 2 deserved some work to make it easier to read and avoid
repetition. This edit finally gets to this, and eliminates some
duplication. This also moves some of the material from section 2 to
reform a clearer conclusion. The scope remains focussed on the usage
of transport headers and the implications of encryption - not on
proposals for new techniques/specifications to be developed.
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. 64 change blocks. 
422 lines changed or deleted 508 lines changed or added

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