draft-ietf-tsvwg-transport-encrypt-07.txt		draft-ietf-tsvwg-transport-encrypt-08.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: January 5, 2020 University of Glasgow		Expires: February 24, 2020 University of Glasgow
	July 04, 2019		August 23, 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-07		draft-ietf-tsvwg-transport-encrypt-08
	Abstract		Abstract
	This document describes implications of applying end-to-end		This document describes some implications of applying end-to-end
	encryption at the transport layer. It identifies in-network uses of		encryption at the transport layer. It first identifies in-network
	transport layer header information. It then reviews the implications		uses of transport layer header information. Then, it reviews some
	of developing end-to-end transport protocols that use authentication		implications of developing end-to-end transport protocols that use
	to protect the integrity of transport information or encryption to		encryption to provide confidentiality of the transport protocol
	provide confidentiality of the transport protocol header and expected		headers, or that use authentication to protect the integrity of
	implications of transport protocol design and network operation.		transport header information. Since measurement and analysis of the
	Since transport measurement and analysis of the impact of network		impact of network characteristics on transport protocols has been
	characteristics have been important to the design of current		important to the design of current transports, it also considers the
	transport protocols, it also considers the impact on transport and		impact of transport encryption on transport and application
	application evolution.		evolution.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 5, 2020.		This Internet-Draft will expire on February 24, 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
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	1. Introduction		1. Introduction
	There is increased interest in, and deployment of, 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. Encryption can also be used to prevent unwanted		transport protocols. Encryption and authentication can also be used
	modification of transport header information by middleboxes. There		to prevent unwanted modification of transport header information by
	are also, however, some costs, in that the widespread use of		middleboxes. There are also, however, some costs, in that the
	transport encryption requires changes to network operations, and		widespread use of transport encryption requires changes to network
	complicates network measurement for research, operational, and		operations, and complicates network measurement for research,
	standardisation purposes. The direction in which the use of		operational, and standardisation purposes. The direction in which
	transport header confidentiality evolves could have significant		the use of transport header confidentiality evolves could have
	implications on the way the Internet architecture develops, and		significant implications on the way the Internet architecture
	therefore needs to be considered as a part of protocol design.		develops, and therefore needs to be considered as a part of protocol
			design.
	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 transport 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		headers, 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 some
	anticipated implications on transport and application evolution.		anticipated implications on transport and application evolution.
	Transports are also increasingly encrypting and authenticating the		Transports are also increasingly encrypting and authenticating the
	payload (i.e., the application data carried within the transport		payload (i.e., the application data carried within the transport
	connection) end-to-end. Such protection is encouraged, and the		connection) end-to-end. Such protection is encouraged, and the
	implications of protecting the payload are not further discussed in		implications of protecting the payload are not further discussed in
	this memo.		this document.
	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 (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: to discover and adapt to the Internet path that is		transport: to discover and adapt to the Internet path that is
	currently used. The design of Internet transport protocols is as		currently used. The design of Internet transport protocols is as
	much about trying to avoid the unwanted side effects of congestion on		much about trying to avoid the unwanted side effects of congestion on
	a flow and other capacity-sharing flows, avoiding congestion		a flow and other capacity-sharing flows, avoiding congestion
	collapse, adapting to changes in the path characteristics, etc., as		collapse, adapting to changes in the path characteristics, etc., as
	it is about end-to-end feature negotiation, flow control and		it is about end-to-end feature negotiation, flow control, and
	optimising for performance of a specific application.		optimising for performance of a specific 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 the insights of the		has to date relied heavily on the results of measurements and the
	network operations community to understand the trade-offs, and to		insights of the network operations community to understand the trade-
	inform selection of appropriate mechanisms, to ensure a safe,		offs, and to inform selection of appropriate mechanisms to ensure a
	reliable, and robust Internet (e.g., [RFC1273]). In turn, the		safe, reliable, and robust Internet (e.g., [RFC1273]). In turn, the
	network operator (and access provider) community has relied on being		network operator and access provider community has relied on being
	able to understand the pattern and requirements of traffic passing		able to understand the pattern and requirements of traffic passing
	over the Internet, both in aggregate and at the flow level.		over the Internet, both in aggregate and at the flow level. The
			widespread use of transport header encryption may change this.
	2.1. Use of Transport Header Information in the Network		2.1. Use of Transport Header Information in the Network
	In-network measurement of transport flow characteristics can be used		In-network measurement of transport flow characteristics can be used
	to enhance performance, and control cost and service reliability.		to enhance performance, and control cost and service reliability.
	Some operators have deployed functionality in middleboxes to both		Some operators have deployed functionality in middleboxes to both
	support network operations can be deployed to enhance performance. A		support network operations and enhance performance. This reliance on
	reliance on the presence and semantics of specific header information		the presence and semantics of specific header information leads to
	leads to ossification, where an endpoint could be required to supply		ossification, where an endpoint could be required to supply a
	a specific header to receive the network service that it desires. In		specific header to receive the network service that it desires. In
	some case this could be benign or advantageous to the protocol (e.g.,		some cases, this could be benign or advantageous to the protocol
	recognising the start of a connection, or explicitly exposing		(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 the		semantics from other flow properties). In other cases, the
	ossification could frustrate the evolution of the protocol (e.g., a		ossification could frustrate the evolution of the protocol (e.g., a
	mechanism implemented in a network device, such as a firewall, that		mechanism implemented in a network device, such as a firewall, that
	required a header field to have only a specific known set of values		required a header field to have only a specific known set of values
	would prevent the device from forwarding packets using a different		would prevent the device from forwarding packets using a different
	version of a protocol that introduces a feature that changes the		version of a protocol that introduces a feature that changes the
	value of this field).		value of this field).
	Experience developing Transport Layer Security [RFC8446], required a		As an example of ossification, consider the experience of developing
	design that recognised that deployed middleboxes relied on the		Transport Layer Security (TLS) 1.3 [RFC8446]. This required a design
	exposed information in Transport Layer Security (TLS) 1.2. Examples		that recognised that deployed middleboxes relied on the presence of
	of the impact of ossification can be found in the development of		certain header filed exposed in TLS 1.2, and failed if those headers
	Multipath TCP (MPTCP) and the TCP Fast Open option. The design of		were changed. Other examples of the impact of ossification can be
	MPTCP had to be revised to account for middleboxes, so called "TCP		found in the development of Multipath TCP (MPTCP) and the TCP Fast
	Normalizers", that monitor the evolution of the window advertised in		Open option. The design of MPTCP had to be revised to account for
	the TCP headers and that reset connections if the window does not		middleboxes, so called "TCP Normalizers", that monitor the evolution
	grow as expected. Similarly, TCP Fast Open has had issues with		of the window advertised in the TCP headers and that reset
	middleboxes that remove unknown TCP options, that drop segments with		connections if the window does not grow as expected. Similarly, TCP
	unknown TCP options, that drop segments that contain data and have		Fast Open has had issues with middleboxes that remove unknown TCP
	the SYN bit set, that drop packets with SYN/ACK that acknowledge		options, that drop segments with unknown TCP options, that drop
	data, or that disrupt connections that send data before the three-way		segments that contain data and have the SYN bit set, that drop
	handshake completes. In both cases, the issue was caused by		packets with SYN/ACK that acknowledge data, or that disrupt
	middleboxes that had a hard-coded understanding of transport		connections that send data before the three-way handshake completes.
	behaviour, and that interacted poorly with transports that tried to
	change that behaviour. Other examples have included middleboxes that		In all these cases, the issue was caused by middleboxes that had a
	rewrite TCP sequence and acknowledgement numbers but are unaware of		hard-coded understanding of transport behaviour, and that interacted
	the (newer) SACK option and don't correctly rewrite selective		poorly with transports that tried to change that behaviour. Other
	acknowledgements to match the changes made to the fixed TCP header.		examples have included middleboxes that 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.
	2.2. Encryption of Transport Header Information		2.2. Encryption of Transport Header Information
	Encryption is expected to form a basis for many future transport		Encryption is expected to form a basis for many future transport
	protocol designs. There are many motivations for deploying encrypted		protocol designs. These can be in the form of encrypted transport
	transports [RFC7624] (i.e., transport protocols that use encryption		protocols (i.e., transport protocols that use encryption to provide
	to provide confidentiality of some or all of the transport-layer		confidentiality of some or all of the transport-layer header
	header information), and encryption of transport payloads (i.e.		information), and/or the encryption of transport payloads (i.e.,
	Confidentiality of the payload data). Increasing public concerns		confidentiality of the payload data). There are many motivations for
	about interference with Internet traffic have led to a rapidly		deploying such transports, and increasing public concerns about
	expanding deployment of encryption to protect end-user privacy, e.g.,		interference with Internet traffic [RFC7624] have led to a rapidly
	QUIC [I-D.ietf-quic-transport]. Using encryption to provide		expanding deployment of encrypted transport protocols such as QUIC
			[I-D.ietf-quic-transport]. Using encryption to provide
	confidentiality of the transport layer therefore brings some well-		confidentiality of the transport layer therefore brings some well-
	known privacy and security benefits. Although it is important that		known privacy and security benefits.
	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		Authentication and the introduction of cryptographic integrity checks
	prevent undetected manipulation of the field by network devices, or		for header fields can prevent undetected manipulation of transport
	undetected addition of information to a packet. This does not		headers by network devices. This does not prevent inspection of the
	prevent inspection of the information by a device on path, and it is		information by devices on path, and it is possible that such devices
	possible that such devices could develop mechanisms that rely on the		could develop mechanisms that rely on the presence of such a field or
	presence of such a field or a known value in the field. In this		a known value in the field. In this context, specification of a non-
	context, specification of a non-encrypted transport header field		encrypted transport header field explicitly allows protocol designers
	explicitly allows protocol designers to make specific header		to make the certain header information observable by the network.
	information observable in the network. This supports other uses of		This supports use of this information by on-path devices, but at the
	this information by on-path devices, and at the same time this can be		same time can be expected to lead to ossification of the transport
	expected to lead to ossification of the transport header, because		header, because network forwarding could evolve to depend on the
	network forwarding could evolve to depend on the presence and/or		presence and/or value of these fields. To avoid unwanted inspection,
	value of these fields. To avoid unwanted inspection, a protocol		a protocol could intentionally vary the format or value of exposed
	could intentionally vary the format and/or value of exposed header		header fields [I-D.ietf-tls-grease].
	fields (sometimes known as Greasing [I-D.thomson-quic-grease]).
	A protocol design that uses header encryption with secure key		A protocol design that uses header encryption with secure key
	distribution can provide confidentiality of some or all of the		distribution can provide confidentiality for some, or all, of the
	protocol header information. This prevents an on-path device from		protocol header information. This prevents an on-path device from
	observing the header field. This prevents mechanisms being built		observing the transport headers, and stops mechanisms being built
	that directly rely on the information or seek to infer semantics of		that directly rely on transport header information, or that seek to
	an exposed header field and can therefore help reduce ossification of		infer semantics of exposed header fields. Transport header
	the transport layer. While encryption can hide transport header		encryption can therefore help reduce ossification of the transport
	information, it does not prevent ossification of the network service.		layer.
	People seeking to understand network traffic could come to rely on		While encryption can hide transport header information, it does not
	pattern inferences and other heuristics as the basis for network		prevent ossification of the network service. People seeking to
	decision and to derive measurement data, creating new dependencies on		understand network traffic could come to rely on pattern inferences
	the transport protocol (or the patterns of traffic it can generate).		and other heuristics as the basis for network decision and to derive
	This use of machine-learning methods usually demands large data sets,		measurement data. This can create new dependencies on the transport
	presenting it own requirements for collecting and distributing the		protocol, or the patterns of traffic it can generate. This use of
	data.		machine-learning methods usually demands large data sets, presenting
			it own requirements for collecting and distributing the data.
	2.3. Encryption tradeoffs		2.3. Encryption tradeoffs
	The are architectural challenges and considerations in the way		The are architectural challenges and considerations in the way
	transport protocols are designed, and the ability to characterise and		transport protocols are designed, and the ability to characterise and
	compare different transport solutions [Measure]. The decision about		compare different transport solutions [Measure]. The decision about
	which transport headers fields are made observable offers trade-offs		which transport headers fields are made observable offers trade-offs
	around authentication and confidentiality versus observability,		around authentication and confidentiality versus observability,
	network operations and management, and ossification. The impact		network operations and management, and ossification. The impact
	differs depending on the activity, for example:		differs depending on the activity, for example:
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 42 ¶
	Confidentiality of the transport payload could be provided while		Confidentiality of the transport payload could be provided while
	leaving some, or all, transport headers unencrypted (or providing		leaving some, or all, transport headers unencrypted (or providing
	this information in a network-layer extension), possibly with		this information in a network-layer extension), possibly with
	authentication. This provides many of the privacy and security		authentication. This provides many of the privacy and security
	benefits while supporting operations and research, but at the cost		benefits while supporting operations and research, but at the cost
	of ossifying the exposed headers.		of ossifying the exposed headers.
	Protection from Denial of Service: Observable transport headers		Protection from Denial of Service: Observable transport headers
	currently provide useful input to classify and detect anomalous		currently provide useful input to classify and detect anomalous
	events (e.g., changes in application behaviour, distributed denial		events, such as changes in application behaviour or distributed
	of service attacks). For this application to be effective, this		denial of service attacks. For this application to be effective,
	needs to be able to uniquely disambiguate unwanted traffic.		it needs to be possible for an operator to uniquely disambiguate
			unwanted traffic. Concealing transport header information would
	Concealing transport header information would prevent separating		prevent disambiguation based on transport information. This could
	anomalous traffic based on transport information. This could		result in less-efficient identification of unwanted traffic, the
	result in less-efficient identification of unwanted traffic or		use of heuristics to identify anomalous flows, or the introduction
	development of different methods (e.g. rate-limiting of		of rate limits for uncharacterised traffic.
	uncharacterised traffic). Additional mechanisms will need to be
	introduced, such as heuristics to disambiguate any unwanted
	traffic.
	Network Troubleshooting and Diagnostics: Observable transport		Network Troubleshooting and Diagnostics: Observable transport
	headers can be used by operators to support network		headers can be utilised by operators for network troubleshooting
	troubleshooting and diagnostics. A flow experiencing packet loss		and diagnostics. Flows experiencing packet loss or jitter are
	or jitter looks like an unaffected flow when only observing		hard to distinguish from unaffected flows when only observing
	network layer headers.		network layer headers. Effective troubleshooting often requires
			visibility into the transport layer behaviour.
	Concealing transport header information eliminates the incentive		Concealing transport header information reduces the incentive for
	for operators to troubleshoot, since they cannot interpret the		operators to troubleshoot, since they cannot interpret the data.
	data. It can limit understanding of transport dynamics, such as		It can limit understanding of transport dynamics, such as the
	the impact of packet loss or latency on the flows, or localizing		impact of packet loss or latency on the flows, or make it harder
	the network segment causing the packet loss or latency.		to localise the network segment intoducing the packet loss or
	Additional mechanisms will be needed to help reconstruct or		latency. Additional mechanisms will be needed to help reconstruct
	replace transport-level metrics for troubleshooting and		or replace transport-level metrics for troubleshooting and
	diagnostics. These can add complexity and operational costs		diagnostics. These can add complexity and operational costs
	(e.g., in deploying additional functions in equipment or adding		(e.g., in deploying additional functions in equipment or adding
	traffic overhead).		traffic overhead).
	Network Traffic Analysis: Observable transport headers can support		Network Traffic Analysis: Observable transport headers can support
	network traffic analysis to determine which transport protocols		network traffic analysis to determine which transport protocols
	and features are being used across a network segment and to		and features are being used across a network segment and to
	measure trends in the pattern of usage. For some applications		measure trends in the pattern of usage. For some applications
	end-to-end measurements/traces are sufficient, in other		end-to-end measurements/traces are sufficient, but in other
	applications it is important to relate observations to specific		applications it is important to relate observations to specific
	equipment/configurations or network segments.		equipment/configurations or particular network segments.
	Concealing transport header information can make analysis harder		Concealing transport header information can make analysis harder
	or impossible. This could impact the ability for an operator to		or impossible. This could impact the ability for an operator to
	anticipate the need for network upgrades and roll-out. It can		anticipate the need for network upgrades and roll-out. It can
	also impact the on-going traffic engineering activities performed		also impact the on-going traffic engineering activities performed
	by operators (such as determining which parts of the path		by operators, such as determining which parts of the path
	contribute delay, jitter or loss). While this impact could, in		contribute delay, jitter or loss. While this impact could, in
	many cases, be small, there are scenarios where operators directly		many cases, be small, there are scenarios where operators directly
	support particular services (e.g., to explore issues relating to		support particular services and need visibility to explore issues
	Quality of Service, QoS; the ability to perform fast re-routing of		relating to Quality of Service (QoS), the ability to perform fast
	critical traffic, or support to mitigate the characteristics of		re-routing of critical traffic, or to mitigate the characteristics
	specific radio links). The more complex the underlying		of specific radio links, and so on.
	infrastructure the more important this impact.
	Open and Verifiable Network Data: Observable transport headers can		Open and Verifiable Network Data: Observable transport headers can
	provide open and verifiable measurement data. The ability of		provide open and verifiable measurement data. The ability of
	other stake holders to review transport header traces helps		other stake holders to review transport header traces helps
	develop insight into performance and traffic contribution of		develop insight into performance and traffic contribution of
	specific variants of a protocol. Independently observed data is		specific variants of a protocol. Independently observed data is
	important to help ensure the health of the research and		important to help ensure the health of the research and
	development communities.		development communities.
	Concealing transport header information can reduce the range of		Concealing transport header information can reduce the range of
	actors that observe useful data. This would limit the information		actors that can observe useful data. This would limit the
	sources available to the Internet community to understand the		information sources available to the Internet community to
	operation of new transport protocols, reducing information to		understand the operation of new transport protocols, reducing
	inform design decisions and standardisation of the new protocols		information to inform design decisions and standardisation of the
	and related operational practices.		new protocols and related operational practices.
	Compliance: Observable transport headers coupled with published		Compliance: Observable transport headers coupled with published
	transport specifications allow operators and regulators to check		transport specifications allow operators and regulators to check
	compliance. Independently verifiable performance metrics can also		compliance. Independently verifiable performance metrics can also
	be utilised to demonstrate regulatory compliance in some		be utilised to demonstrate regulatory compliance in some
	jurisdictions, and as a basis for informing design decisions.		jurisdictions, and as a basis for informing design decisions.
	This can bring assurance to those operating networks, often		This can bring assurance to those operating networks, often
	avoiding the need to deploy complex techniques that routinely		avoiding the need to deploy complex techniques that routinely
	monitor and manage Internet traffic flows (e.g., avoiding the		monitor and manage Internet traffic flows (e.g., avoiding the
	capital and operational costs of deploying flow rate-limiting and		capital and operational costs of deploying flow rate-limiting and
	network circuit-breaker methods [RFC8084]).		network circuit-breaker methods [RFC8084]).
	When transport header information is concealed, it is not possible		When transport header information is concealed, it is not possible
	to observe transport header information. Methods are still needed		to observe transport header information. Methods are still needed
	to confirm that the traffic produced conforms to the expectations		to confirm that the traffic produced conforms to the expectations
	of the operator or developer.		of the operator or developer.
			Different parties will view the relative importance of these issues
			differently. For some, the benefits of encrypting some, or all, of
			the transport headers may outweigh the impact of doing so; others
			might make a different trade-off. The purpose of highlighting the
			trade-offs is to make such analysis possible.
	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 affects
	affect how protocol information is used [RFC8404]. To understand		how protocol information is used [RFC8404], requiring consideration
	these implications, it is first necessary to understand how transport		of the trade-offs discussed in Section 2.3. To understand the
	layer headers are currently observed and/or modified by middleboxes		implications, it is necessary to understand how transport layer
	within the network.		headers are currently observed and/or modified by middleboxes within
			the network.
	Transport protocols can be designed to encrypt or authenticate		We review some current uses in the following section. This does not
	transport header fields. Authentication at the transport layer can		consider the intentional modification of transport headers by
	be used to detect any changes to an immutable header field that were		middleboxes (such as in Network Address Translation, NAT, or
	made by a network device along a path. The intentional modification		Firewalls). Common issues concerning IP address sharing are
	of transport headers by middleboxes (such as Network Address		described in [RFC6269].
	Translation, NAT, or Firewalls) is not considered. Common issues
	concerning IP address sharing are described in [RFC6269].
	3.1. Observing Transport Information in the Network		3.1. Observing Transport Information in the Network
	If in-network observation of transport protocol headers is needed,		If in-network observation of transport protocol headers is needed,
	this requires knowledge of the format of the transport header:		this requires knowledge of the format of the transport header:
	o Flows need to be identified at the level required to perform the		o Flows need to be identified at the level required to perform the
	observation;		observation;
	o The protocol and version of the header need to be visible, e.g.,		o The protocol and version of the header need to be visible, e.g.,
	by defining the wire image [I-D.trammell-wire-image]. As		by defining the wire image [RFC8546]. As protocols evolve over
	protocols evolve over time and there could be a need to introduce		time and there could be a need to introduce new transport headers.
	new transport headers. This could require interpretation of		This could require interpretation of protocol version information
	protocol version information or connection setup 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 Using Transport Layer Headers
	Flow identification is a common function. For example, performed by		Flow identification is a common function. For example, performed by
	measurement activities, QoS classification, firewalls, Denial of		measurement activities, QoS classification, firewalls, Denial of
	Service, DOS, prevention. This becomes more complex and less easily		Service, DOS, prevention. This becomes more complex and less easily
	achieved when multiplexing is used at or above the transport layer.		achieved when multiplexing is used at or above the transport layer.
	Observable transport header information (together with information in		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 flows and their
	connection state of the flow, together with the protocol options		connection state, together with the protocol options being used.
	being used. In some usages, a low-numbered (well-known) transport
	port number has been used to identify a protocol (although port
	information alone is not sufficient to guarantee identification of a
	protocol, since applications can use arbitrary ports, multiple
	sessions can be multiplexed on a single port, and ports can be re-
	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
	number information and other data, with the possibility to negotiate		sequence number information and other data. They also have the
	additional headers at connection setup, identified by an option		possibility to negotiate additional headers at connection setup,
	number in the transport header. UDP-based protocols can use, but		identified by an option number in the transport header.
	sometimes do not use, well-known port numbers. Some flows can
	instead be identified by observing signalling protocol data (e.g.,		In some uses, a low-numbered (well-known) transport port number can
	[RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic		be used to identify the protocol, although port information alone is
	numbers placed in the first byte(s) of the datagram payload		not sufficient to guarantee identification of a protocol since
			applications can use arbitrary ports, multiple sessions can be
			multiplexed on a single port, and ports can be re-used by subsequent
			sessions.
			UDP-based protocols often do not use well-known port numbers. Some
			flows can instead be identified by observing signalling protocol data
			(e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of
			magic numbers placed in the first byte(s) of the datagram payload
	[RFC7983].		[RFC7983].
	Concealing transport header information can remove information used		Concealing transport header information can remove information used
	to classify flows by passive observers along the path and operators		to classify flows by passive observers along the path, so operators
	will be unable to use this information directly. Careful use of the		will be unable to use this information directly. Careful use of the
	network layer features can help address provide similar information		network layer features can help address provide similar information
	in the case where the network is unable to inspect transport protocol		in the case where the network is unable to inspect transport protocol
	headers. Operators could also turn to more ambitious ways to		headers. Operators could also turn to more ambitious ways to
	collect, estimate, or infer that data (for example heuristics based		collect, estimate, or infer that data, including heuristics based on
	on the analysis of traffic patterns). For example, an operator no		the analysis of traffic patterns. For example, an operator that no
	longer has access to Session Description Protocol (SDP) session		longer has access to Session Description Protocol (SDP) session
	descriptions to classify a flow carry as audio traffic. Instead, the		descriptions to classify a flow carry as audio traffic might instead
	operator might use heuristics to infer that short UDP packets with		use heuristics to infer that short UDP packets with regular spacing
	regular spacing carry audio traffic. Operational practices aimed at		carry audio traffic. Operational practices aimed at inferring
	guessing transport parameters are out of scope for this document, and		transport parameters are out of scope for this document, and are only
	are only mentioned here to recognize that encryption does not prevent		mentioned here to recognize that encryption does not prevent
	operators from attempting to apply practices that were used with		operators from attempting to apply practices that were used with
	unencrypted transport headers.		unencrypted transport headers.
	Confidentiality of the transport payload could be provided while		Confidentiality of the transport payload could be provided while
	leaving some, or all, transport headers unencrypted (or providing		leaving some, or all, transport headers unencrypted, or providing
	this information in a network-layer extension), possibly with		this information in a network-layer extension, possibly with
	authentication. This provides many of the privacy and security		authentication. This provides many of the privacy and security
	benefits while supporting operations and research, but at the cost of		benefits while supporting operations and research, but at the cost of
	ossifying the exposed headers.		ossifying the exposed headers.
	3.1.2. Metrics derived from Transport Layer Headers		3.1.2. Metrics derived from Transport Layer Headers
	Observable transport headers enable explicit measure and analysis		Observable transport headers enable explicit measurement and analysis
	protocol performance, network anomalies, and failure pathologies at		of protocol performance, network anomalies, and failure pathologies
	any point along the Internet path. Some actors manage their portion		at any point along the Internet path. Some operators manage their
	of the Internet by characterizing the performance of link/network		portion of the Internet by characterizing the performance of link/
	segments. Passive monitoring can observe traffic that does not		network segments. Passive monitoring can observe traffic that does
	encrypt the transport header information to make inferences from		not encrypt the transport header information, and make inferences
	transport headers to derive these performance metrics.		from transport headers to derive performance metrics.
	A variety of open source and commercial tools have been deployed that		A variety of open source and commercial tools have been deployed that
	utilise this information. The following metrics can be derived from		utilise transport header information in this way. The following
	transport header information:		metrics can be derived:
	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., to assess		endpoint or for an aggregate of endpoints (e.g., to assess
	subscriber usage). It can also be used to trigger measurement-		subscriber usage). It can also be used to trigger measurement-
	based traffic shaping and to implement QoS support within the		based traffic shaping, and to implement QoS support within the
	network and lower layers. Volume measures can be valuable for		network and lower layers. Volume measures can be valuable for
	capacity planning and providing detail of trends, rather than the		capacity planning and providing detail of trends, 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 preemption. Understanding flow		inadequate provision of traffic pre-emption. Understanding flow
	loss rate requires either maintaining per flow packet counters or		loss rates requires either observing sequence numbers in transport
	by observing sequence numbers in transport headers. Loss can be		headers, or maintaining per-flow packet counters (but note that
	monitored at the interface level by devices in the network. It is		flow identification often requires transport header information).
	often valuable to understand the conditions under which packet		Per-hop loss can be monitored at the interface level by devices in
	loss occurs. This usually requires relating loss to the traffic		the network. It is often valuable to understand the conditions
	flowing on the network node/segment at the time of loss.		under which packet loss occurs. This usually requires relating
			per-flow loss to the traffic 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 where 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: Throughput is the amount of data sent by a
			flow per time interval. Goodput [RFC7928] is a measure of useful
			data exchanged (the ratio of useful data to total volume of
			traffic sent by a flow). The throughput achieved by a flow can be
	determined even when transport header information is concealed,		determined even when transport header information is concealed,
	providing the individual flow can be identified. Goodput		providing the individual flow can be identified. Goodput requires
	[RFC7928] is a measure of useful data exchanged (the ratio of		ability to differentiate loss and retransmission of packets, for
	useful/total volume of traffic sent by a flow). This requires		example by observing packet sequence numbers in the TCP or the
	ability to differentiate loss and retransmission of packets (e.g.,		Real-time Transport Protocol (RTP) headers [RFC3550].
	by observing packet sequence numbers in the TCP or the Real-time
	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 and user-perceived response times. It often
	often indirectly impacts throughput and flow completion time.		indirectly impacts throughput and flow completion time. Latency
	Latency determines the reaction time of the transport protocol		determines the reaction time of the transport protocol itself,
	itself, impacting flow setup, congestion control, loss recovery,		impacting flow setup, congestion control, loss recovery, and other
	and other transport mechanisms. The observed latency can have		transport mechanisms. The observed latency can have many
	many components [Latency]. Of these, unnecessary/unwanted queuing		components [Latency]. Of these, unnecessary/unwanted queuing in
	in network buffers has often been observed as a significant factor		network buffers has often been observed as a significant factor
	[bufferbloat]. Once the cause of unwanted latency has been		[bufferbloat]. Once the cause of unwanted latency has been
	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
	[RFC7799] can measure the experienced round trip time (RTT) using		[RFC7799] can measure the experienced round trip time (RTT) using
	packet sequence numbers, and acknowledgements, or by observing		packet sequence numbers, and acknowledgements, or by observing
	header timestamp information. Such information allows an		header timestamp information. Such information allows an
	observation point in the network to determine not only the path		observation point in the network to determine not only the path
	RTT, but also to measure the upstream and downstream contribution		RTT, but also to measure the upstream and downstream contribution
	to the RTT. This could be used to locate a source of latency,		to the RTT. This could be used to locate a source of latency,
	e.g., by observing cases where the median RTT is much greater than		e.g., by observing cases where the median RTT is much greater than
	the 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 configuration changes and
	deployed services. Latency metrics are key to evaluating and		to tune deployed services. Latency metrics are key to evaluating
	deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit		and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
	Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements		Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
	could identify excessively large buffers, indicating where to		could identify excessively large buffers, indicating where to
	deploy or configure AQM. An AQM method is often deployed in		deploy or configure AQM. An AQM method is often deployed in
	combination with other techniques, such as scheduling [RFC7567]		combination with other techniques, such as scheduling [RFC7567]
	[RFC8290] and although parameter-less methods are desired		[RFC8290] and although parameter-less methods are desired
	[RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often		[RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often
	cannot scale across all possible deployment scenarios.		cannot scale across all possible deployment scenarios.
	Variation in delay: Some network applications are sensitive to small		Variation in delay: Some network applications are sensitive to
	changes in packet timing (jitter). Short and long-term delay		(small) changes in packet timing (jitter). Short and long-term
	variation can impact on the latency of a flow and hence the		delay variation can impact on the latency of a flow and hence the
	perceived quality of applications using the network (e.g., jitter		perceived quality of applications using the network. For example,
	metrics are often cited when characterising paths supporting real-		jitter metrics are often cited when characterising paths
	time traffic). To assess the performance of such applications, it		supporting real-time traffic. To assess the performance of such
	can be necessary to measure the variation in delay observed along		applications, it can be necessary to measure the variation in
	a portion of the path [RFC3393] [RFC5481]. The requirements		delay observed along a portion of the path [RFC3393] [RFC5481].
	resemble those for the measurement of latency.		The requirements for observable transport headers resemble those
			for the measurement of latency.
	Flow Reordering: Significant packet reordering within a flow can		Flow Reordering: Significant packet reordering within a flow can
	impact time-critical applications and can be interpreted as loss		impact time-critical applications and can be interpreted as loss
	by reliable transports. Many transport protocol techniques are		by reliable transports. Many transport protocol techniques are
	impacted by reordering (e.g., triggering TCP retransmission or re-		impacted by reordering (e.g., triggering TCP retransmission or re-
	buffering of real-time applications). Packet reordering can occur		buffering of real-time applications). Packet reordering can occur
	for many reasons, from equipment design to misconfiguration of		for many reasons, from equipment design to misconfiguration of
	forwarding rules. Since this impacts transport performance,		forwarding rules. Since this impacts transport performance,
	network tools are needed to detect and measure unwanted/excessive		network tools are needed to detect and measure unwanted/excessive
	reordering.		reordering.
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 35 ¶
	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 [RFC7799], and way in which		including the time, observation point [RFC7799], and way in which
	metrics were accumulated. The RTCP protocol directly reports some		metrics were accumulated. The RTCP protocol directly reports some
	of this information in a form that can be directly visible in the		of this information in a form that can be directly visible in the
	network. A user of summary measurement data needs to trust the		network. A user of summary measurement data needs to trust the
	source of this data and the method used to generate the summary		source of this data and the method used to generate the summary
	information.		information.
	This information can support network operations, e.g. to inform		This information can support network operations, inform capacity
	capacity planning and assist in determining the need for equipment		planning, and assist in determining the need for equipment and/or
	and/or configuration changes by network operators. It can also		configuration changes by network operators. It can also inform
	inform Internet engineering activities by informing the development		Internet engineering activities by informing the development of new
	of new protocols, methodologies, and procedures.		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 to implement access rules (see
	implement access rules (see also section 2.2.2 of [RFC8404]).		also section 2.2.2 of [RFC8404]). Network-layer classification
	Network-layer classification methods that rely on a multi-field		methods that rely on a multi-field classifier (e.g., inferring QoS
	classifier (e.g. Inferring QoS from the 5-tuple or choice of		from the 5-tuple or choice of application protocol) are incompatible
	application protocol) are incompatible with transport protocols that		with transport protocols that encrypt the transport information.
	encrypt the transport information. Traffic that cannot be		Traffic that cannot be classified will typically receive a default
	classified, will typically receive a default treatment.		treatment.
	Transport information can also be explicitly set in network-layer		Transport information can also be explicitly set in network-layer
	header fields that are not encrypted. This can provide information		header fields that are not encrypted. This can provide information
	to enable a different forwarding treatment by the network, even when		to enable a different forwarding treatment by the network, even when
	a transport employs encryption to protect other header information.		a transport employs encryption to protect other header information.
	On the one hand, the user of a transport that multiplexes multiple		The user of a transport that multiplexes multiple sub-flows might
	sub-flows could wish to hide the presence and characteristics of		want to hide the presence and characteristics of these sub-flows. On
	these sub-flows. On the other hand, an encrypted transport could set		the other hand, an encrypted transport could set the network-layer
	the network-layer information to indicate the presence of sub-flows		information to indicate the presence of sub-flows, and to reflect the
	and to reflect the network needs of individual sub-flows. There are		network needs of individual sub-flows. There are several ways this
	several ways this could be done:		could be done:
	IP Address: Applications expose the addresses used by endpoints, and		IP Address: Applications expose the addresses used by endpoints, and
	this is used in the forwarding decisions in network devices.		this is used in the forwarding decisions in network devices.
	Address and other protocol information can be used by a Multi-		Address and other protocol information can be used by a Multi-
	Field (MF) classifier to determine how traffic is treated		Field (MF) classifier to determine how traffic is treated
	[RFC2475], and hence the quality of experience for a flow.		[RFC2475], and hence the quality of experience for a flow.
	Using the IPv6 Network-Layer Flow Label: A number of Standards Track		Using the IPv6 Network-Layer Flow Label: A number of Standards Track
	and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437],		and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437],
	[RFC6438]) encourage endpoints to set the IPv6 Flow label field of		[RFC6438]) encourage endpoints to set the IPv6 Flow label field of
	the network-layer header. IPv6 "source nodes SHOULD assign each		the network-layer header. IPv6 "source nodes SHOULD assign each
	unrelated transport connection and application data stream to a		unrelated transport connection and application data stream to a
	new flow" [RFC6437]. A multiplexing transport could choose to use		new flow" [RFC6437]. A multiplexing transport could choose to use
	multiple Flow labels to allow the network to independently forward		multiple Flow labels to allow the network to independently forward
	subflows. RFC6437 provides further guidance on choosing a flow		subflows. RFC6437 provides further guidance on choosing a flow
	label value, stating these "should be chosen such that their bits		label value, stating these "should be chosen such that their bits
	exhibit a high degree of variability", and chosen so that "third		exhibit a high degree of variability", and chosen so that "third
	parties should be unlikely to be able to guess the next value that		parties should be unlikely to be able to guess the next value that
	a source of flow labels will choose". To promote privacy, the		a source of flow labels will choose". To promote privacy, the
	Flow Label assignment needs to avoid introducing linkability that		Flow Label assignment needs to avoid introducing linkability that
	a network device may observe. Once set, a label can provide		a network device may observe. Once set, a flow label can provide
	information that can help inform network-layer queuing and		information that can help inform network-layer queuing and
	forwarding [RFC6438](e.g. for Equal Cost Multi-Path, ECMP,		forwarding [RFC6438], for example with Equal Cost Multi-Path
	routing, and Link Aggregation, LAG) [RFC6294]. [RFC6438]		routing and Link Aggregation [RFC6294]. Considerations when using
	describes considerations when used with IPsec.		IPsec are further described in [RFC6438].
	Using the Network-Layer Differentiated Services Code Point:		Using the Network-Layer Differentiated Services Code Point:
	Applications can expose their delivery expectations to the network		Applications can expose their delivery expectations to the network
	by setting the Differentiated Services Code Point (DSCP) field of		by setting the Differentiated Services Code Point (DSCP) field of
	IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications		IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications
	identify different forwarding treatments for individual sub-flows		identify different forwarding treatments for individual sub-flows
	(audio vs. video) based on the value of the DSCP field		(audio vs. video) based on the value of the DSCP field
	[I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information		[I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information
	to inform network-layer queuing and forwarding, rather than an		to inform network-layer queuing and forwarding, rather than an
	operator inferring traffic requirements from transport and		operator inferring traffic requirements from transport and
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 15 ¶
	Since the DSCP value can impact the quality of experience for a		Since the DSCP value can impact the quality of experience for a
	flow, observations of service performance need to consider this		flow, observations of service performance need to consider this
	field when a network path has support for differentiated service		field when a network path has support for differentiated service
	treatment.		treatment.
	Using Explicit Congestion Marking: ECN [RFC3168] is a transport		Using Explicit Congestion Marking: ECN [RFC3168] is a transport
	mechanism that utilises the ECN field in the network-layer header.		mechanism that utilises the ECN field in the network-layer header.
	Use of ECN explicitly informs the network-layer that a transport		Use of ECN explicitly informs the network-layer that a transport
	is ECN-capable, and requests ECN treatment of the flow. An ECN-		is ECN-capable, and requests ECN treatment of the flow. An ECN-
	capable transport can offer benefits when used over a path with		capable transport can offer benefits when used over a path with
	equipment that implements an AQM method with Congestion		equipment that implements an AQM method with CE marking of IP
	Experienced (CE) marking of IP packets [RFC8087], since it can		packets [RFC8087], since it can react to congestion without also
	react to congestion without also having to recover from lost		having to recover from lost packets.
	packets.
	ECN exposes the presence of congestion. The reception of CE-		ECN exposes the presence of congestion. The reception of CE-
	marked packets can be used to estimate the level of incipient		marked packets can be used to estimate the level of incipient
	congestion on the upstream portion of the path from the point of		congestion on the upstream portion of the path from the point of
	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].
	When transport headers are concealed, operators will be unable to use		When transport headers are concealed, operators will be unable to use
	this information directly. Careful use of the network layer features		this information directly. Careful use of the network layer features
	can help address provide similar information in the case where the		can help address provide similar information in the case where the
	skipping to change at page 15, line 44 ¶		skipping to change at page 15, line 46 ¶
	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
	understanding of the network operation rely more on pattern		understanding of the network operation rely more on pattern inference
	inferences and other heuristics reliance on pattern inferences and		and other heuristics. It remains to be seen whether more complex
	accuracy suffers. For example, the traffic patterns between server		inferences can be mastered to produce the same monitoring accuracy
	and browser are dependent on browser supplier and version, even when		(see section 2.1.1 of [RFC8404]).
	the sessions use the same server application (e.g., web e-mail
	access). It remains to be seen whether more complex inferences can
	be mastered to produce the same monitoring accuracy (see section
	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 [RFC7799].		evaluation [RFC7799].
	Packet sampling techniques are used to scale the processing involved		Packet sampling techniques are used to scale the processing involved
	skipping to change at page 16, line 50 ¶		skipping to change at page 16, line 47 ¶
	Sometimes multiple on-path observation points are needed. By		Sometimes multiple on-path observation points are needed. By
	correlating observations of headers at multiple points along the path		correlating observations of headers at multiple points along the path
	(e.g., at the ingress and egress of a network segment), an observer		(e.g., at the ingress and egress of a network segment), an observer
	can determine the contribution of a portion of the path to an		can determine the contribution of a portion of the path to an
	observed metric, to locate a source of delay, jitter, loss,		observed metric, to locate a source of delay, jitter, loss,
	reordering, congestion marking, etc.		reordering, congestion marking, etc.
	3.2.2. Use by Operators to Plan and Provision Networks		3.2.2. Use by Operators to Plan and Provision Networks
	Traffic measurements (e.g., traffic volume, loss, latency) is used by		Traffic measurements (e.g., traffic volume, loss, latency) are used
	operators to help plan deployment of new equipment and configuration		by operators to help plan deployment of new equipment and
	in their networks. Data is also valuable to equipment vendors who		configuration in their networks. Data is also valuable to equipment
	want to understand traffic trends and patterns of usage as inputs to		vendors who want to understand traffic trends and patterns of usage
	decisions about planning products and provisioning for new		as inputs to decisions about planning products and provisioning for
	deployments. This measurement information can also be correlated		new deployments. This measurement information can also be correlated
	with billing information when this is also collected by an operator.		with billing information when this is also collected by an operator.
	A network operator supporting traffic that uses transport header		A network operator supporting traffic that uses transport header
	encryption might not have access to per-flow measurement data.		encryption might not have access to per-flow measurement data.
	Trends in aggregate traffic can be observed and can be related to the		Trends in aggregate traffic can be observed and can be related to the
	endpoint addresses being used, but it may be impossible to correlate		endpoint addresses being used, but it may be impossible to correlate
	patterns in measurements with changes in transport protocols (e.g.,		patterns in measurements with changes in transport protocols (e.g.,
	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 (see section 3.4 of [RFC7799]) may be used		While active measurements (see section 3.4 of [RFC7799]) may be used
	within a network, passive measurements (see section 3.6 of [RFC7799]		within a network, passive measurements (see section 3.6 of [RFC7799])
	) can have advantages in terms of eliminating unproductive test		can have advantages in terms of eliminating unproductive test
	traffic, reducing the influence of test traffic on the overall		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
	skipping to change at page 18, line 25 ¶		skipping to change at page 18, line 21 ¶
	impact of specific transport protocols (or protocol mechanisms) on		impact of specific transport protocols (or protocol mechanisms) on
	the other traffic that shares a network. An observation in the		the other traffic that shares a network. An observation in the
	network can gain an understanding of the dynamics of a flow and		network can gain an understanding of the dynamics of a flow and
	its congestion control behaviour. Analysing observed flows can		its congestion control behaviour. Analysing observed flows can
	help to build confidence that an application flow backs-off its		help to build confidence that an application flow backs-off its
	share of the network load in the face of persistent congestion,		share of the network load in the face of persistent congestion,
	and hence to understand whether the behaviour is appropriate for		and hence to understand whether the behaviour is appropriate for
	sharing limited network capacity. For example, it is common to		sharing limited network capacity. For example, it is common to
	visualise plots of TCP sequence numbers versus time for a flow to		visualise plots of TCP sequence numbers versus time for a flow to
	understand how a flow shares available capacity, deduce its		understand how a flow shares available capacity, deduce its
	dynamics in response to congestion, etc. The ability to identify		dynamics in response to congestion, etc.
	sources that contribute to persistent congestion is important to
	safe operation of network infrastructure, and mechanisms can		The ability to identify sources that contribute to persistent
	inform configuration of network devices to complement the endpoint		congestion is important to safe operation of network
	congestion avoidance mechanisms [RFC7567] [RFC8084] to avoid a		infrastructure, and mechanisms can inform configuration of network
	portion of the network being driven into congestion collapse		devices to complement the endpoint congestion avoidance mechanisms
	[RFC2914].		[RFC7567] [RFC8084] to avoid a portion of the network being driven
			into congestion collapse [RFC2914].
	Congestion Control Compliance for UDP traffic: UDP provides a		Congestion Control Compliance for UDP traffic: UDP provides a
	minimal message-passing datagram transport that has no inherent		minimal message-passing datagram transport that has no inherent
	congestion control mechanisms. Because congestion control is		congestion control mechanisms. Because congestion control is
	critical to the stable operation of the Internet, applications and		critical to the stable operation of the Internet, applications and
	other protocols that choose to use UDP as a transport are required		other protocols that choose to use UDP as a transport are required
	to employ mechanisms to prevent congestion collapse, avoid		to employ mechanisms to prevent congestion collapse, avoid
	unacceptable contributions to jitter/latency, and to establish an		unacceptable contributions to jitter/latency, and to establish an
	acceptable share of capacity with concurrent traffic [RFC8085].		acceptable share of capacity with concurrent traffic [RFC8085].
	A network operator needs tools to understand if datagram flows		A network operator needs tools to understand if datagram flows
	comply with congestion control expectations and therefore whether		(e.g., using UDP) comply with congestion control expectations and
	there is a need to deploy methods such as rate-limiters, transport		therefore whether there is a need to deploy methods such as rate-
	circuit breakers or other methods to enforce acceptable usage for		limiters, transport circuit breakers, or other methods to enforce
	the offered service.		acceptable usage for the offered service.
	UDP flows that expose a well-known header by specifying the format		UDP flows that expose a well-known header by specifying the format
	of header fields can allow information to be observed to gain		of header fields can allow information to be observed to gain
	understanding of the dynamics of a flow and its congestion control		understanding of the dynamics of a flow and its congestion control
	behaviour. For example, tools exist to monitor various aspects of		behaviour. For example, tools exist to monitor various aspects of
	the RTP and RTCP header information of real-time flows (see		RTP and RTCP header information for real-time flows (see
	Section 3.1.2, and the Secure RTP extensions [RFC3711] were		Section 3.1.2). The Secure RTP extensions [RFC3711] were
	explicitly designed to expose header information to enable such		explicitly designed to expose some header information to enable
	observation.		such observation, while protecting the payload data.
	3.3. Use for Network Diagnostics and Troubleshooting		3.3. Use for Network Diagnostics and Troubleshooting
	Transport header information can be useful for a variety of		Transport header information can be useful for a variety of
	operational tasks [RFC8404]: to diagnose network problems, assess		operational tasks [RFC8404]: to diagnose network problems, assess
	network provider performance, evaluate equipment/protocol		network provider performance, evaluate equipment/protocol
	performance, capacity planning, management of security threats		performance, capacity planning, management of security threats
	(including denial of service), and responding to user performance		(including denial of service), and responding to user performance
	questions. Sections 3.1.2 and 5 of [RFC8404] provide further		questions. Section 3.1.2 and Section 5 of [RFC8404] provide further
	examples. These tasks seldom involve the need to determine the		examples. These tasks seldom involve the need to determine the
	contents of the transport payload, or other application details.		contents of the transport payload, or other application details.
	A network operator supporting traffic that uses transport header		A network operator supporting traffic that uses transport header
	encryption can see only encrypted transport headers. This prevents		encryption can see only encrypted transport headers. This prevents
	deployment of performance measurement tools that rely on transport		deployment of performance measurement tools that rely on transport
	protocol information. Choosing to encrypt all the information		protocol information. Choosing to encrypt all the information
	reduces the ability of an operator to observe transport performance		reduces the ability of an operator to observe transport performance
	and could limit the ability of network operators to trace problems,		and could limit the ability of network operators to trace problems,
	make appropriate QoS decisions, or response to other queries about		make appropriate QoS decisions, or response to other queries about
	skipping to change at page 20, line 18 ¶		skipping to change at page 20, line 17 ¶
	an endpoint.		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, 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		A flow that conceals its transport header information could imply
	"don't touch" to some operators. This could limit a trouble-shooting		"don't touch" to some operators. This could limit a trouble-shooting
	response to "can't help, no trouble found".		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 capacity by compressing network and
	transport protocol headers on a per-hop basis. It was widely used		transport protocol headers on a per-hop basis. It was widely used
	with low bandwidth dial-up access links, and still finds application		with low bandwidth dial-up access links, and still finds application
	on wireless links that are subject to capacity constraints. Header		on wireless links that are subject to capacity constraints. 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,
	significant bandwidth savings can be made if both the network and		significant savings can be made if both the network and transport
	transport layer headers are compressed together as a single unit.		layer headers are compressed together as a single unit. The Secure
	The Secure RTP extensions [RFC3711] were explicitly designed to leave		RTP extensions [RFC3711] were explicitly designed to leave the
	the transport protocol headers unencrypted, but authenticated, since		transport protocol headers unencrypted, but authenticated, since
	support for header compression was considered important. Encrypting		support for header compression was considered important. Encrypting
	the transport protocol headers does not break such header		the transport protocol headers does not break such header
	compression, but does cause it to fall back to compressing only the		compression, but does cause it to fall back to compressing only the
	network layer headers, with a significant reduction in efficiency.		network layer headers, with a significant reduction in efficiency.
	This may have operational impact.		This can impact the efficiency of a link/path.
	4. Encryption and Authentication of Transport Headers		4. Encryption and Authentication of Transport Headers
	End-to-end encryption can be applied at various protocol layers. It		End-to-end encryption can be applied at various protocol layers. It
	can be applied above the transport to encrypt the transport payload.		can be applied above the transport to encrypt the transport payload.
	Encryption methods can hide information from an eavesdropper in the		Encryption methods can hide information from an eavesdropper in the
	network. Encryption can also help protect the privacy of a user, by		network. Encryption can also help protect the privacy of a user, by
	hiding data relating to user/device identity or location. Neither an		hiding data relating to user/device identity or location. Neither an
	integrity check nor encryption methods prevent traffic analysis, and		integrity check nor encryption methods prevent traffic analysis, and
	usage needs to reflect that profiling of users, identification of		usage needs to reflect that profiling of users, identification of
	location and fingerprinting of behaviour can take place even on		location and fingerprinting of behaviour can take place even on
	encrypted traffic flows. Any header information that has a clear		encrypted traffic flows. Any header information that has a clear
	definition in the protocol's message format(s), or is implied by that		definition in the protocol's message format(s), or is implied by that
	definition, and is not cryptographically confidentiality-protected		definition, and is not cryptographically confidentiality-protected
	can be unambiguously interpreted by on-path observers		can be unambiguously interpreted by on-path observers [RFC8546].
	[I-D.trammell-wire-image].
	There are several motivations:		There are several motivations for encryption:
	o One motive to use encryption is a response to perceptions that the		o One motive to use encryption is a response to perceptions that the
	network has become ossified by over-reliance on middleboxes that		network has become ossified by over-reliance on middleboxes that
	prevent new protocols and mechanisms from being deployed. This		prevent new protocols and mechanisms from being deployed. This
	has lead to a perception that there is too much "manipulation" of		has lead to a perception that there is too much "manipulation" of
	protocol headers within the network, and that designing to deploy		protocol headers within the network, and that designing to deploy
	in such networks is preventing transport evolution. In the light		in such networks is preventing transport evolution. In the light
	of this, a method that authenticates transport headers may help		of this, a method that authenticates transport headers could help
	improve the pace of transport development, by eliminating the need		improve the pace of transport development, by eliminating the need
	to always consider deployed middleboxes		to always consider deployed middleboxes
	[I-D.trammell-plus-abstract-mech], or potentially to only		[I-D.trammell-plus-abstract-mech], or potentially to only
	explicitly enable middlebox use for particular paths with		explicitly enable use by middleboxes for particular paths with
	particular middleboxes that are deliberately deployed to realise a		particular middleboxes that are deliberately deployed to realise a
	useful function for the network and/or users[RFC3135].		useful function for the network and/or users[RFC3135].
	o Another motivation stems from increased concerns about privacy and		o Another motivation stems from increased concerns about privacy and
	surveillance. Some Internet users have valued the ability to		surveillance. Some Internet users have valued the ability to
	protect identity, user location, and defend against traffic		protect identity, user location, and defend against traffic
	analysis, and have used methods such as IPsec Encapsulated		analysis, and have used methods such as IPsec Encapsulated
	Security Payload (ESP), Virtual Private Networks (VPNs) and other		Security Payload (ESP), VPNs and other encrypted tunnel
	encrypted tunnel technologies. Revelations about the use of		technologies. Revelations about the use of pervasive surveillance
	pervasive surveillance [RFC7624] have, to some extent, eroded		[RFC7624] have, to some extent, eroded trust in the service
	trust in the service offered by network operators, and following		offered by network operators, and following the Snowden revelation
	the Snowden revelation in the USA in 2013 has led to an increased		in the USA in 2013 has led to an increased desire for people to
	desire for people to employ encryption to avoid unwanted		employ encryption to avoid unwanted "eavesdropping" on their
	"eavesdropping" on their communications. Concerns have also been		communications. Concerns have also been voiced about the addition
	voiced about the addition of information to packets by third		of information to packets by third parties to provide analytics,
	parties to provide analytics, customization, advertising, cross-		customization, advertising, cross-site tracking of users, to bill
	site tracking of users, to bill the customer, or to selectively		the customer, or to selectively allow or block content. Whatever
	allow or block content. Whatever the reasons, there are now		the reasons, there are now activities in the IETF to design new
	activities in the IETF to design new protocols that could include		protocols that could include some form of transport header
	some form of transport header encryption (e.g., QUIC		encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement
	[I-D.ietf-quic-transport]).		the already widespread payload encryption.
	Authentication methods (that provide integrity checks of protocols		Authentication methods that provide integrity checks of protocols
	fields) have also been specified at the network layer, and this also		fields have also been specified at the network layer, and this also
	protects transport header fields. The network layer itself carries		protects transport header fields. The network layer itself carries
	protocol header fields that are increasingly used to help forwarding		protocol header fields that are increasingly used to help forwarding
	decisions reflect the need of transport protocols, such as the IPv6		decisions reflect the need of transport protocols, such as the IPv6
	Flow Label [RFC6437], DSCP, and ECN fields.		Flow Label [RFC6437], DSCP, and ECN fields.
	The use of transport layer authentication and encryption exposes a		The use of transport layer authentication and encryption exposes a
	tussle between middlebox vendors, operators, applications developers		tussle between middlebox vendors, operators, applications developers
	and users.		and users:
	o On the one hand, future Internet protocols that enable large-scale		o On the one hand, future Internet protocols that enable large-scale
	encryption assist in the restoration of the end-to-end nature of		encryption assist in the restoration of the end-to-end nature of
	the Internet by returning complex processing to the endpoints,		the Internet by returning complex processing to the endpoints,
	since middleboxes cannot modify what they cannot see.		since middleboxes cannot modify what they cannot see.
	o On the other hand, encryption of transport layer header		o On the other hand, encryption of transport layer header
	information has implications for people who are responsible for		information has implications for people who are responsible for
	operating networks and researchers and analysts seeking to		operating networks and researchers and analysts seeking to
	understand the dynamics of protocols and traffic patterns.		understand the dynamics of protocols and traffic patterns.
	Whatever the motives, a decision to use pervasive transport header		Whatever the motives, a decision to use pervasive transport header
	encryption will have implications on the way in which design and		encryption will have implications on the way in which design and
	evaluation is performed, and which can in turn impact the direction		evaluation is performed. This can, in turn, impact the direction of
	of evolution of the transport protocol stack. While the IETF can		evolution of the transport protocol stack. While the IETF can
	specify protocols, the success in actual deployment is often		specify protocols, the success in actual deployment is often
	determined by many factors [RFC5218] that are not always clear at the		determined by many factors [RFC5218] that are not always clear at the
	time when protocols are being defined.		time when protocols are being defined.
	The following briefly reviews some security design options for		The following briefly reviews some security design options for
	transport protocols. A Survey of Transport Security Protocols		transport protocols. A Survey of Transport Security Protocols
	[I-D.ietf-taps-transport-security] provides more details concerning		[I-D.ietf-taps-transport-security] provides more details concerning
	commonly used encryption methods at the transport layer.		commonly used encryption methods at the transport layer.
	Authenticating the Transport Protocol Header: Transport layer header		Authenticating the Transport Protocol Header: Transport layer header
	information can be authenticated. An integrity check that		information can be authenticated. An integrity check that
	protects the immutable transport header fields, but can still		protects the immutable transport header fields, but can still
	expose the transport protocol header information in the clear,		expose the transport protocol header information in the clear,
	allowing in-network devices to observe these fields. An integrity		allows in-network devices to observe these fields. An integrity
	check is not able to prevent in-network modification, but can		check is not able to prevent in-network modification, but can
	prevent a receiving from accepting changes and avoid impact on the		prevent a receiving from accepting changes and avoid impact on the
	transport protocol operation.		transport protocol operation.
	An example transport authentication mechanism is TCP-		An example transport authentication mechanism is TCP-
	Authentication (TCP-AO) [RFC5925]. This TCP option authenticates		Authentication (TCP-AO) [RFC5925]. This TCP option authenticates
	the IP pseudo header, TCP header, and TCP data. TCP-AO protects		the IP pseudo header, TCP header, and TCP data. TCP-AO protects
	the transport layer, preventing attacks from disabling the TCP		the transport layer, preventing attacks from disabling the TCP
	connection itself and provides replay protection. TCP-AO may		connection itself and provides replay protection. TCP-AO may
	interact with middleboxes, depending on their behaviour [RFC3234].		interact with middleboxes, depending on their behaviour [RFC3234].
	The IPsec Authentication Header (AH) [RFC4302] was designed to		The IPsec Authentication Header (AH) [RFC4302] was designed to
	work at the network layer and authenticate the IP payload. This		work at the network layer and authenticate the IP payload. This
	approach authenticates all transport headers, and verifies their		approach authenticates all transport headers, and verifies their
	integrity at the receiver, preventing in-network modification.		integrity at the receiver, preventing in-network modification.
	Secure RTP [RFC3711] is another example of a transport protocol		Secure RTP [RFC3711] is another example of a transport protocol
	that allows header authentication.		that allows header authentication.
	Greasing: Transport layer header information that is observable can		Greasing: Protocols often provide extensibility features, reserving
	be observed in the network. Protocols often provide extensibility		fields or values for use by future versions of a specification.
	features, reserving fields or values for use by future versions of		The specification of receivers has traditionally ignored
	a specification. The specification of receivers has traditionally		unspecified values, however in-network devices have emerged that
	ignored unspecified values, however in-network devices have		ossify to require a certain value in a field, or re-use a field
	emerged that ossify to require a certain value in a field, or re-		for another purpose. When the specification is later updated, it
	use a field for another purpose. When the specification is later		is impossible to deploy the new use of the field, and forwarding
	updated, it is impossible to deploy the new use of the field, and		of the protocol could even become conditional on a specific header
	forwarding of the protocol could even become conditional on a		field value.
	specific header field value.
	A protocol can intentionally vary the value, format, and/or		A protocol can intentionally vary the value, format, and/or
	presence of observable transport header fields. This behaviour,		presence of observable transport header fields. This behaviour,
	known as GREASE (Generate Random Extensions And Sustain		known as GREASE (Generate Random Extensions And Sustain
	Extensibility), is designed to avoid a network device ossifying		Extensibility) is designed to avoid a network device ossifying the
	the use of a specific observable field. Greasing seeks to ease		use of a specific observable field. Greasing seeks to ease
	deployment of new methods. It can also prevent in-network devices		deployment of new methods. It can also prevent in-network devices
	utilising the information in a transport header, or can make an		utilising the information in a transport header, or can make an
	observation robust to a set of changing values, rather than a		observation robust to a set of changing values, rather than a
	specific set of values.		specific set of values.
	Encrypting the Transport Payload: The transport layer payload can be		Encrypting the Transport Payload: The transport layer payload can be
	encrypted to protect the content of transport segments. This		encrypted to protect the content of transport segments. This
	leaves transport protocol header information in the clear. The		leaves transport protocol header information in the clear. The
	integrity of immutable transport header fields could be protected		integrity of immutable transport header fields could be protected
	by combining this with an integrity check.		by combining this with an integrity check.
	Examples of encrypting the payload include Transport Layer		Examples of encrypting the payload include Transport Layer
	Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS)		Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS)
	over UDP [RFC6347] [RFC7525], Secure RTP [RFC3711], and TCPcrypt		over UDP [RFC6347] [RFC7525], Secure RTP [RFC3711], and TCPcrypt
	[I-D.ietf-tcpinc-tcpcrypt] which permits opportunistic encryption		[RFC8548] which permits opportunistic encryption of the TCP
	of the TCP transport payload.		transport payload.
	Encrypting the Transport Headers and Payload: The network layer		Encrypting the Transport Headers and Payload: The network layer
	payload could be encrypted (including the entire transport header		payload could be encrypted (including the entire transport header
	and the payload). This method provides confidentiality of the		and the payload). This method provides confidentiality of the
	entire transport packet. It therefore does not expose any		entire transport packet. It therefore does not expose any
	transport information to devices in the network, which also		transport information to devices in the network, which also
	prevents modification along a network path.		prevents modification along a network path.
	One example of encryption at the network layer is use of IPsec		One example of encryption at the network layer is the use of IPsec
	Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode.		Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode.
	This encrypts and authenticates all transport headers, preventing		This encrypts and authenticates all transport headers, preventing
	visibility of the transport headers by in-network devices. Some		visibility of the transport headers by in-network devices. Some
	Virtual Private Network (VPN) methods also encrypt these headers.		VPN methods also encrypt these headers.
	Selectively Encrypting Transport Headers and Payload: A transport		Selectively Encrypting Transport Headers and Payload: A transport
	protocol design can encrypt selected header fields, while also		protocol design can encrypt selected header fields, while also
	choosing to authenticate the entire transport header. This allows		choosing to authenticate the entire transport header. This allows
	specific transport header fields to be made observable by network		specific transport header fields to be made observable by network
	devices. End-to end integrity checks can prevent an endpoint from		devices. End-to end integrity checks can prevent an endpoint from
	undetected modification of the immutable transport headers.		undetected modification of the immutable transport headers.
	Mutable fields in the transport header provide opportunities for		Mutable fields in the transport header provide opportunities for
	middleboxes to modify the transport behaviour (e.g., the extended		middleboxes to modify the transport behaviour (e.g., the extended
	skipping to change at page 24, line 45 ¶		skipping to change at page 24, line 44 ¶
	fields. Instead, fields of a specific type ought to always be		fields. Instead, fields of a specific type ought to always be
	sent with the same level of confidentiality or integrity		sent with the same level of confidentiality or integrity
	protection.		protection.
	As seen, different transports use encryption to protect their header		As seen, different transports use encryption to protect their header
	information to varying degrees. There is, however, a trend towards		information to varying degrees. There is, however, a trend towards
	increased protection with newer transport protocols.		increased protection with newer transport protocols.
	5. Addition of Transport Information to Network-Layer Protocol Headers		5. Addition of Transport Information to Network-Layer Protocol Headers
	Some measurements can be made by adding additional protocol headers		An on-path device can make measurements by appending additional
	carrying operations, administration and management (OAM) information		protocol headers carrying operations, administration and management
	to packets at the ingress to a maintenance domain (e.g., an Ethernet		(OAM) information to packets at the ingress to a maintenance domain
	protocol header with timestamps and sequence number information using		(e.g., an Ethernet protocol header with timestamps and sequence
	a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data])		number information using a method such as 802.11ag or in-situ OAM
	and removing the additional header at the egress of the maintenance		[I-D.ietf-ippm-ioam-data]) and removing the additional header at the
	domain. This approach enables some types of measurements, but does		egress of the maintenance domain. This approach enables some types
	not cover the entire range of measurements described in this		of measurements, but does not cover the entire range of measurements
	document. In some cases, it can be difficult to position measurement		described in this document. In some cases, it can be difficult to
	tools at the required segments/nodes and there can be challenges in		position measurement tools at the required segments/nodes and there
	correlating the downsream/upstream information when in-band OAM data		can be challenges in correlating the downsream/upstream information
	is inserted by an on-path device. This has the advantage that a		when in-band OAM data is inserted by an on-path device. This has the
	single header can support all transport protocols, but there could		advantage that a single header can support all transport protocols,
	also be less desirable implications of separating the operation of		but there could also be less desirable implications of separating the
	the transport protocol from the measurement framework.		operation of the transport protocol from the measurement framework.
	Another example of a network-layer approach is the IPv6 Performance		Another example of a network-layer approach is the IPv6 Performance
	and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This		and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This
	allows a sender to optionally include a destination option that		allows a sender to optionally include a destination option that
	caries header fields that can be used to observe timestamps and		caries header fields that can be used to observe timestamps and
	packet sequence numbers. This information could be authenticated by		packet sequence numbers. This information could be authenticated by
	receiving transport endpoints when the information is added at the		receiving transport endpoints when the information is added at the
	sender and visible at the receiving endpoint, although methods to do		sender and visible at the receiving endpoint, although methods to do
	this have not currently been proposed. This method needs to be		this have not currently been proposed. This method needs to be
	explicitly enabled at the sender.		explicitly enabled at the sender.
	Current measurements suggest it can be undesirable to rely on methods		Current measurement results suggest that it can be undesirable to
	requiring the presence of network options or extension headers. IPv4		rely on methods requiring end to end support of network options or
	network options are often not supported (or are carried on a slower		extension headers across the Internet. IPv4 network options are
	processing path) and some IPv6 networks are also known to drop		often not supported (or are carried on a slower processing path) and
	packets that set an IPv6 header extension (e.g., [RFC7872]). Another		some IPv6 networks have been observed to drop packets that set an
	disadvantage is that protocols that separately expose header		IPv6 header extension (e.g., results from 2016 in [RFC7872]).
	information do not necessarily have an incentive to expose the		Another possibility is that protocols that separately expose header
	information that is utilised by the protocol itself, and could		information do not necessarily have an incentive to expose the actual
	manipulate the exposed header information to gain an advantage from		information that is utilised by the protocol itself and could
	the network.		therefore manipulate the exposed header information to gain an
			advantage from the network. The incentive to reflect actual
			transport information needs to be considered when proposing a method
			that selectively exposes header information.
	6. Implications of Protecting the Transport Headers		6. Implications of Protecting the Transport Headers
	The choice of which fields to expose and which to encrypt is a design		The choice of which fields to expose and which to encrypt is a design
	choice for the transport protocol. Any selective encryption method		choice for the transport protocol. Any selective encryption method
	requires trading two conflicting goals for a transport protocol		requires trading two conflicting goals for a transport protocol
	designer to decide which header fields to encrypt. Security work		designer to decide which header fields to encrypt. Security work
	typically employs a design technique that seeks to expose only what		typically employs a design technique that seeks to expose only what
	is needed. This approach provides incentives to not reveal any		is needed. This approach provides incentives to not reveal any
	information that is not necessary for the end-to-end communication.		information that is not necessary for the end-to-end communication.
	However, there can be performance and operational benefits in		However, there can be performance and operational benefits in
	exposing selected information to network tools.		exposing selected information to network tools.
	This section explores key implications of working with encrypted		This section explores key implications of working with encrypted
	transport protocols.		transport protocols.
	6.1. Independent Measurement		6.1. Independent Measurement
	Independent observation by multiple actors is important for		Independent observation by multiple actors is important if the
	scientific analysis. Encrypting transport header encryption changes		transport community is to maintain an accurate understanding of the
	the ability for other actors to collect and independently analyse		network. Encrypting transport header encryption changes the ability
	data. Internet transport protocols employ a set of mechanisms. Some		to collect and independently analyse data. Internet transport
	of these need to work in cooperation with the network layer - loss		protocols employ a set of mechanisms. Some of these need to work in
	detection and recovery, congestion detection and congestion control,		cooperation with the network layer for loss detection and recovery,
	some of these need to work only end-to-end (e.g., parameter		congestion detection and congestion control. Others need to work
	negotiation, flow-control).		only end-to-end (e.g., parameter negotiation, flow-control).
	The majority of present Internet applications use two well-known		The majority of present Internet applications use two well-known
	transport protocols, TCP and UDP. Although TCP represents the		transport protocols, TCP and UDP. Although TCP represents the
	majority of current traffic, some real-time applications use UDP, and		majority of current traffic, many real-time applications use UDP, and
	much of this traffic utilises RTP format headers in the payload of		much of this traffic utilises RTP format headers in the payload of
	the UDP datagram. Since these protocol headers have been fixed for		the UDP datagram. Since these protocol headers have been fixed for
	decades, a range of tools and analysis methods have became common and		decades, a range of tools and analysis methods have became common and
	well-understood.		well-understood.
	Protocols that expose the state information used by the transport		Protocols that expose the state information used by the transport
	protocol in their header information (e.g., timestamps used to		protocol in their header information (e.g., timestamps used to
	calculate the RTT, packet numbers used to asses congestion and		calculate the RTT, packet numbers used to asses congestion and
	requests for retransmission) provide an incentive for the sending		requests for retransmission) provide an incentive for the sending
	endpoint to provide correct information, increasing confidence that		endpoint to provide correct information, since the protocol will not
	the observer understands the transport interaction with the network.		work otherwise. This increases confidence that the observer
	For example, when TCP is used over an unencrypted network path (i.e.,		understands the transport interaction with the network. For example,
	one that does not use IPsec or other encryption below the transport),		when TCP is used over an unencrypted network path (i.e., one that
	it implicitly exposes header information that can be used for		does not use IPsec or other encryption below the transport), it
			implicitly exposes header information that can be used for
	measurement at any point along the path. This information is		measurement at any point along the path. This information is
	necessary for the protocol's correct operation, therefore there is no		necessary for the protocol's correct operation, therefore there is no
	incentive for a TCP implementation to put incorrect information in		incentive for a TCP implementation to put incorrect information in
	this transport header. A network device can have confidence that the		this transport header. A network device can have confidence that the
	well-known (and ossified) transport information represents the actual		well-known (and ossified) transport information represents the actual
	state of the endpoints.		state of the endpoints.
	When encryption is used to conceal some or all of the transport		When encryption is used to conceal some or all of the transport
	headers, the transport protocol choose what information to reveal to		headers, the transport protocol choose what information to reveal to
	the network about its internal state, what information to leave		the network about its internal state, what information to leave
	skipping to change at page 27, line 9 ¶		skipping to change at page 27, line 10 ¶
	explicitly reveal a session's RTT [I-D.ietf-quic-spin-exp]).		explicitly reveal a session's RTT [I-D.ietf-quic-spin-exp]).
	When providing or using such information, it becomes important to		When providing or using such information, it becomes important to
	consider the privacy of the user and their incentive for providing		consider the privacy of the user and their incentive for providing
	accurate and detailed information. Protocols that selectively reveal		accurate and detailed information. Protocols that selectively reveal
	some transport state or measurement signals are choosing to establish		some transport state or measurement signals are choosing to establish
	a trust relationship with the network operators. There is no		a trust relationship with the network operators. There is no
	protocol mechanism that can guarantee that the information provided		protocol mechanism that can guarantee that the information provided
	represents the actual transport state of the endpoints, since those		represents the actual transport state of the endpoints, since those
	endpoints can always send additional information in the encrypted		endpoints can always send additional information in the encrypted
	part of the header, to update to replace whatever they reveal. This		part of the header, to update or replace whatever they reveal. This
	reduces the ability to independently measure and verify that a		reduces the ability to independently measure and verify that a
	protocol is behaving as expected. Some operational uses need the		protocol is behaving as expected. Some operational uses need the
	information to contain sufficient detail to understand, and possibly		information to contain sufficient detail to understand, and possibly
	reconstruct, the network traffic pattern for further testing; such		reconstruct, the network traffic pattern for further testing; such
	operators must gain the trust of transport protocol implementers if		operators must gain the trust of transport protocol implementers if
	they are to correctly reveal such information.		they are to correctly reveal such information.
	OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a		OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a
	variety of encapsulation methods at different layers to support the		variety of encapsulation methods at different layers to support the
	goals of a specific operational domain. OAM-related metadata can		goals of a specific operational domain. OAM-related metadata can
	support functions such as performance evaluation, path-tracing, path		support functions such as performance evaluation, path-tracing, path
	verification information, classification and a diversity of other		verification information, classification and a diversity of other
	uses. When encryption is used to conceal some or all of the		uses. When encryption is used to conceal some or all of the
	transport headers, analysis will require coordination between actors		transport headers, analysis will require coordination between actors
	at different layers to successfully characterise flows and correlate		at different layers to successfully characterise flows and correlate
	the performance or behavior of a specific mechanism with the		the performance or behaviour of a specific mechanism with the
	configuration and traffic using operational equipment (e.g.		configuration and traffic using operational equipment (e.g.,
	Combining transport and network measurements to explore congestion		combining transport and network measurements to explore congestion
	control dynamics or the implications of active queue management).		control dynamics, the implications of designs for active queue
			management or circuit breakers).
	For some usage a standardised endpoint-based logging format (e.g.,		For some usage a standardised endpoint-based logging format (e.g.,
	based onQuic-Trace [Quic-Trace]) could offer an alternative to in-		based on Quic-Trace [Quic-Trace]) could offer an alternative for some
	network measurement. Such information will have a diversity of uses		in-network measurement. Such information will have a diversity of
	- examples include developers wishing to debug/understand the		uses, including developers wishing to debug/understand the transport/
	transport/applictaion protocols with which they work, to researchers		application protocols with which they work, researchers seeking to
	seeking to spot trends, anomalies and to characterise variants of		spot trends and anomalies, and to characterise variants of protocols.
	protocols. This use will need to establish the validity and		Measurments based on logging will need to establish the validity and
	provenance of the logging information (e.g., to establish how and		provenance of the logged information to establish how and when traces
	when traces were captured).		were captured.
	However, endpoint logs do not provide equivalent information to in-		However, endpoint logs do not provide equivalent information to in-
	network measurements. In particular, endpoint logs contain only a		network measurements. In particular, endpoint logs contain only a
	part of the information needed to understand the operation of network		part of the information needed to understand the operation of network
	devices and identify issues such as link performance or capacity		devices and identify issues such as link performance or capacity
	sharing between multiple flows. Additional information is needed to		sharing between multiple flows. Additional information is needed to
	determine which equipment/links are used and the configuration of		determine which equipment/links are used and the configuration of
	equipment along the network paths being measured.		equipment along the network paths being measured.
	6.2. Characterising "Unknown" Network Traffic		6.2. Characterising "Unknown" Network Traffic
	skipping to change at page 29, line 23 ¶		skipping to change at page 29, line 23 ¶
	Each change can introduce associated costs, including the cost of		Each change can introduce associated costs, including the cost of
	collecting data, and the tooling needed to handle multiple formats		collecting data, and the tooling needed to handle multiple formats
	(possibly as these co-exist in the network, when measurements need to		(possibly as these co-exist in the network, when measurements need to
	span time periods during which changes are deployed, or to compare		span time periods during which changes are deployed, or to compare
	with historical data). These costs are incurred by an operator to		with historical data). These costs are incurred by an operator to
	manage the service and debug network issues.		manage the service and debug network issues.
	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
	QUIC[I-D.ietf-quic-transport]), the specification of common log		[I-D.ietf-quic-transport]), the specification of common log formats,
	formats and development of alternative approaches.		and development of alternative approaches.
	6.5. Impact on Research, Development and Deployment		6.5. Impact on Research, Development and Deployment
	Evolution and the ability to understand (measure) the impact need to		Evolution and the ability to understand (measure) the impact need to
	proceed hand-in-hand. Observable transport headers can provide open		proceed hand-in-hand. Observable transport headers can provide open
	and verifiable measurement data. Observation of pathologies has a		and verifiable measurement data. Observation of pathologies has a
	critical role in the design of transport protocol mechanisms and		critical role in the design of transport protocol mechanisms and
	development of new mechanisms and protocols. This helps		development of new mechanisms and protocols. This helps
	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. The ability		traffic and the impact of different patterns of usage. The ability
	of other stake holders to review transport header traces helps		of other stake holders to review transport header traces helps
	develop insight into performance and traffic contribution of specific		develop insight into performance and traffic contribution of specific
	variants of a protocol.		variants of a protocol.
	In development of new transport protocol mechanisms, attention needs		In development of new transport protocol mechanisms, attention needs
	to be paid to the expected scale of deployment. Whatever the		to be paid to the expected scale of deployment. Whatever the
	mechanism, experience has shown that it is often difficult to		mechanism, experience has shown that it is often difficult to
	correctly implement combination of mechanisms [RFC8085]. Mechanisms		correctly implement combinations of mechanisms [RFC8085]. Mechanisms
	often evolve as a protocol matures, or in response to changes in		often evolve as a protocol matures, or in response to changes in
	network conditions, changes in network traffic or changes to		network conditions, changes in network traffic, or changes to
	application usage. Analysis is especially valuable when based on the		application usage. Analysis is especially valuable when based on the
	behaviour experienced across a range of topologies, vendor equipment,		behaviour experienced across a range of topologies, vendor equipment,
	and traffic patterns.		and traffic patterns.
	New transport protocol formats are expected to facilitate an		New transport protocol formats are expected to facilitate an
	increased pace of transport evolution, and with it the possibility to		increased pace of transport evolution, and with it the possibility to
	experiment with and deploy a wide range of protocol mechanisms.		experiment with and deploy a wide range of protocol mechanisms.
	There has been recent interest in a wide range of new transport		There has been recent interest in a wide range of new transport
	methods, e.g., Larger Initial Window, Proportional Rate Reduction		methods, e.g., Larger Initial Window, Proportional Rate Reduction
	(PRR), congestion control methods based on measuring bottleneck		(PRR), congestion control methods based on measuring bottleneck
	skipping to change at page 30, line 47 ¶		skipping to change at page 30, line 47 ¶
	performance data, which in turn demands control over where and when		performance data, which in turn demands control over where and when
	measurement samples are collected. This requires consideration of		measurement samples are collected. This requires consideration of
	the methods used to observe data and the appropriate balance between		the methods used to observe data and the appropriate balance between
	encrypting all and no transport information.		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
	can both be attributed to using the combination of UDP as a substrate		protocol, can both be attributed to using the combination of UDP as a
	while providing confidentiality and authentication of the		substrate while providing confidentiality and authentication of the
	encapsulated transport headers and payload.		encapsulated transport headers and payload.
			To achieve stable Internet operations, the IETF transport community
			has, to date, relied heavily on measurement and insights of the
			network operations community to understand the trade-offs, and to
			inform selection of appropriate mechanisms, to ensure a safe,
			reliable, and robust Internet (e.g., [RFC1273],[RFC2914]).
	The traffic that can be observed by on-path network devices is a		The traffic that can be observed by on-path network devices is a
	function of transport protocol design/options, network use,		function of transport protocol design/options, network use,
	applications, and user characteristics. In general, when only a		applications, and user characteristics. In general, when only a
	small proportion of the traffic has a specific (different)		small proportion of the traffic has a specific (different)
	characteristic, such traffic seldom leads to operational concern,		characteristic, such traffic seldom leads to operational concern,
	although the ability to measure and monitor it is less. The desire		although the ability to measure and monitor it is less. The desire
	to understand the traffic and protocol interactions typically grows		to understand the traffic and protocol interactions typically grows
	as the proportion of traffic increases in volume. The challenges		as the proportion of traffic increases in volume. The challenges
	increase when multiple instances of an evolving protocol contribute		increase when multiple instances of an evolving protocol contribute
	to the traffic that share network capacity.		to the traffic that share network capacity.
	An increased pace of evolution therefore needs to be accompanied by		An increased pace of evolution therefore needs to be accompanied by
	methods that can be successfully deployed and used across operational		methods that can be successfully deployed and used across operational
	networks. This leads to a need for network operators (at various		networks. This leads to a need for network operators at various
	level (ISPs, enterprises, firewall maintainer, etc) to identify		levels (ISPs, enterprises, firewall maintainer, etc.) to identify
	appropriate operational support functions and procedures.		appropriate operational support functions and procedures.
	Protocols that change their transport header format (wire format) or		Protocols that change their transport header format (wire format) or
	their behaviour (e.g., algorithms that are needed to classify and		their behaviour (e.g., algorithms that are needed to classify and
	characterise the protocol), will require new tooling to be developed		characterise the protocol), will require new tooling to be developed
	to catch-up with the change. If the currently deployed tools and		to catch-up with the change. If the currently deployed tools and
	methods are no longer relevant then it may no longer be possible to		methods are no longer relevant, then it may no longer be possible to
	correctly measure performance. This can increase the response-time		correctly measure performance. This can increase the response-time
	after faults, and can impact the ability to manage the network		after faults, and can impact the ability to manage the network
	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. Other information may also be useful to various		decisions. Other information may also be useful to various
	stakeholder (as described in earlier sections), however this document		stakeholders, however this document does not make recommendations
	does not make recommendations about what information should be		about what information should be exposed, to whom it should be
	exposed, to whom it should be observable, or how this will be		observable, or how this will be achieved.
	achieved.
	To achieve stable Internet operations the IETF transport community
	has to date relied heavily on measurement and insights of the network
	operations community to understand the trade-offs, and to inform
	selection of appropriate mechanisms, to ensure a safe, reliable, and
	robust Internet (e.g., [RFC1273],[RFC2914]).
	There are trade-offs and implications of increased use of encryption.		There are trade-offs and implications of increased use of encryption
	Transport protocol designers have often ignored the implications of		when designing a protocol. Transport protocol designers have often
	whether the information in transport header fields can or will be		ignored the implications of whether the information in transport
	used by in-network devices, and the implications this places on		header fields can or will be used by in-network devices, and the
	protocol evolution. This motivates a design that provides		implications this places on protocol evolution. This motivates a
	confidentiality of the header information. It can be expected that a		design that provides confidentiality of header information. This
	lack of visibility of transport header information can impact the		lack of visibility of transport header information can be expected to
	ways that protocols are deployed, standardised, and their operational		impact the ways that protocols are deployed, standardised, and their
	support. The impact of hiding transport headers therefore needs to		operational support. The impact of hiding transport headers
	be considered in the specification and development of protocols and		therefore needs to be considered in the specification and development
	standards. This has a potential impact on the way in which the IRTF		of protocols and standards. This has a potential impact on the way
	and IETF develop new protocols, specifications, and guidelines:		in which the IRTF and IETF develop new protocols, specifications, and
			guidelines:
	o Coexistence of Transport and Network Device Protocols/		o Coexistence of Transport and Network Device Protocols/
	Configuration: Transmission Control Protocol (TCP) is currently		Configuration: Transmission Control Protocol (TCP) is currently
	the predominant transport protocol used over Internet paths. Its		the predominant transport protocol used over Internet paths. Its
	many variants have broadly consistent approaches to avoiding		many variants have broadly consistent approaches to avoiding
	congestion collapse, and to ensuring the stability of the		congestion collapse, and to ensuring the stability of the
	Internet. Increased use of transport layer encryption can		Internet. Increased use of transport layer encryption can
	overcome ossification, allowing deployment of new transports and		overcome ossification, allowing deployment of new transports and
	different types of congestion control. This flexibility can be		different types of congestion control. This flexibility can be
	beneficial, but it can come at the cost of fragmenting the		beneficial, but it could come at the cost of fragmenting the
	ecosystem. There is little doubt that developers will try to		ecosystem. There is little doubt that developers will try to
	produce high quality transports for their intended target uses,		produce high quality transports for their intended target uses,
	but it is not yet clear there are sufficient incentives to ensure		but it is not yet clear there are sufficient incentives to ensure
	good practice that benefits the wide diversity of requirements for		good practice that benefits the wide diversity of requirements for
	the Internet community as a whole.		the Internet community as a whole.
	o Supporting Common Specifications: Common open specifications can		o Supporting Common Specifications: Common open specifications can
	stimulate engagement by developers, users, and researchers.		stimulate engagement by developers, users, and researchers.
	Increased diversity, and the ability to innovate without public		Increased diversity, and the ability to innovate without public
	scrutiny, risks point solutions that optimise for specific needs,		scrutiny, risks point solutions that optimise for specific needs,
	skipping to change at page 33, line 7 ¶		skipping to change at page 33, line 7 ¶
	interactions between features at different protocol layers, a		interactions between features at different protocol layers, a
	side-effect of not allowing a choice of vantage point from which		side-effect of not allowing a choice of vantage point from which
	this information is observed. New approaches need to be		this information is observed. New approaches need to be
	developed.		developed.
	o Operational Practice: The network operations community relies on		o Operational Practice: The network operations community relies on
	being able to understand the pattern and requirements of traffic		being able to understand the pattern and requirements of traffic
	passing over the Internet, both in aggregate and at the flow		passing over the Internet, both in aggregate and at the flow
	level. These operational practices have developed based on the		level. These operational practices have developed based on the
	information available from unencrypted transport headers. The		information available from unencrypted transport headers. The
	iETF supports this activity by developing operations and		IETF supports this activity by developing operations and
	management specifications, interface specifications, and		management specifications, interface specifications, and
	associated Best Current Practice (BCP) specifications. Concealing		associated Best Current Practice (BCP) specifications. Concealing
	transport header information impacts current practice and demand		transport header information impacts current practice and demand
	new specifications.		new specifications.
	o Research and Development: Concealing transport information can		o Research and Development: Concealing transport information can
	impede independent research into new mechanisms, measurement of		impede independent research into new mechanisms, measurement of
	behaviour, and development initiatives. Experience shows that		behaviour, and development initiatives. Experience shows that
	transport protocols are complicated to design and complex to		transport protocols are complicated to design and complex to
	deploy, and that individual mechanisms need to be evaluated while		deploy, and that individual mechanisms need to be evaluated while
	skipping to change at page 33, line 31 ¶		skipping to change at page 33, line 31 ¶
	it could eliminate the independent self-checks to the		it could eliminate the independent self-checks to the
	standardisation process that have previously been in place from		standardisation process that have previously been in place from
	research and academic contributors (e.g., the role of the IRTF		research and academic contributors (e.g., the role of the IRTF
	Internet Congestion Control Research Groups (ICCRG) and research		Internet Congestion Control Research Groups (ICCRG) and research
	publications in reviewing new transport mechanisms and assessing		publications in reviewing new transport mechanisms and assessing
	the impact of their experimental deployment).		the impact of their experimental deployment).
	The choice of whether future transport protocols encrypt their		The choice of whether future transport protocols encrypt their
	protocol headers needs to be taken based not solely on security and		protocol headers needs to be taken based not solely on security and
	privacy considerations, but also taking into account the impact on		privacy considerations, but also taking into account the impact on
	operations, standards, and research. As [RFC7258] notes: "Making		operations, standards and research. As [RFC7258] notes: "Making
	networks unmanageable to mitigate (pervasive monitoring) is not an		networks unmanageable to mitigate (pervasive monitoring) is not an
	acceptable outcome, but ignoring (pervasive monitoring) would go		acceptable outcome, but ignoring (pervasive monitoring) would go
	against the consensus documented here."		against the consensus documented here."
	As part of a protocol's design, the community therefore needs to		As part of a protocol's design, the community therefore needs to
	weigh the benefits of ossifying common headers versus the potential		weigh the benefits of ossifying common headers versus the potential
	demerits of exposing specific information that could be observed		demerits of exposing specific information that could be observed
	along the network path, to ensure network operators, researchers and		along the network path, to ensure network operators, researchers and
	other stakeholders have appropriate tools to manage their networks		other stakeholders have appropriate tools to manage their networks
	and enable stable operation of the Internet as new protocols are		and enable stable operation of the Internet as new protocols are
	deployed. An appropriate balance will emerge over time as real		deployed. An appropriate balance will emerge over time as real
	instances of this tension are considered [RFC7258]. This balance		instances of this tension are analysed [RFC7258]. This balance
	between information exposed and information concealed ought to be		between information exposed and information concealed ought to be
	carefully considered when specifying new transport protocols.		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
	the various sections of the document.		throughout this document.
	Authentication, confidentiality protection, and integrity protection		Authentication, confidentiality protection, and integrity protection
	are identified as Transport Features by [RFC8095]. As currently		are identified as Transport Features by [RFC8095]. As currently
	deployed in the Internet, these features are generally provided by a		deployed in the Internet, these features are generally provided by a
	protocol or layer on top of the transport protocol		protocol or layer on top of the transport protocol
	[I-D.ietf-taps-transport-security].		[I-D.ietf-taps-transport-security].
	Confidentiality and strong integrity checks have properties that can		Confidentiality and strong integrity checks have properties that can
	also be incorporated into the design of a transport protocol.		also be incorporated into the design of a transport protocol.
	Integrity checks can protect an endpoint from undetected modification		Integrity checks can protect an endpoint from undetected modification
	skipping to change at page 34, line 34 ¶		skipping to change at page 34, line 34 ¶
	A protocol design that uses header encryption can provide		A protocol design that uses header encryption can provide
	confidentiality of some or all of the protocol header information.		confidentiality of some or all of the protocol header information.
	This prevents an on-path device from knowledge of the header field.		This prevents an on-path device from knowledge of the header field.
	It therefore prevents mechanisms being built that directly rely on		It therefore prevents mechanisms being built that directly rely on
	the information or seeks to infer semantics of an exposed header		the information or seeks to infer semantics of an exposed header
	field. Hiding headers can limit the ability to measure and		field. Hiding headers can limit the ability to measure and
	characterise traffic.		characterise traffic.
	Exposed transport headers are sometimes utilised as a part of the		Exposed transport headers are sometimes utilised as a part of the
	information to detect anomalies in network traffic. This can be used		information to detect anomalies in network traffic. This can be used
	as the first line of defence yo identify potential threats from DOS		as the first line of defence to identify potential threats from DOS
	or malware and redirect suspect traffic to dedicated nodes		or malware and redirect suspect traffic to dedicated nodes
	responsible for DOS analysis, malware detection, or to perform packet		responsible for DOS analysis, malware detection, or to perform packet
	"scrubbing" (the normalization of packets so that there are no		"scrubbing" (the normalization of packets so that there are no
	ambiguities in interpretation by the ultimate destination of the		ambiguities in interpretation by the ultimate destination of the
	packet). These techniques are currently used by some operators to		packet). These techniques are currently used by some operators to
	also defend from distributed DOS attacks.		also defend from distributed DOS attacks.
	Exposed transport header fields are sometimes also utilised as a part		Exposed transport header fields are sometimes also utilised as a part
	of the information used by the receiver of a transport protocol to		of the information used by the receiver of a transport protocol to
	protect the transport layer from data injection by an attacker. In		protect the transport layer from data injection by an attacker. In
	skipping to change at page 35, line 20 ¶		skipping to change at page 35, line 20 ¶
	One mitigation to off-path attack is to deny knowledge of what header		One mitigation to off-path attack is to deny knowledge of what header
	information is accepted by a receiver or obfuscate the accepted		information is accepted by a receiver or obfuscate the accepted
	header information, e.g., setting a non-predictable initial value for		header information, e.g., setting a non-predictable initial value for
	a sequence number during a protocol handshake, as in [RFC3550] and		a sequence number during a protocol handshake, as in [RFC3550] and
	[RFC6056], or a port value that can not be predicted (see section 5.1		[RFC6056], or a port value that can not be predicted (see section 5.1
	of [RFC8085]). A receiver could also require additional information		of [RFC8085]). A receiver could also require additional information
	to be used as a part of a validation check before accepting packets		to be used as a part of a validation check before accepting packets
	at the transport layer (e.g., utilising a part of the sequence number		at the transport layer (e.g., utilising a part of the sequence number
	space that is encrypted; or by verifying an encrypted token not		space that is encrypted; or by verifying an encrypted token not
	visible to an attacker). This would also mitigate on-path attacks.		visible to an attacker). This would also mitigate against on-path
	An additional processing cost can be incurred when decryption needs		attacks. An additional processing cost can be incurred when
	to be attempted before a receiver is able to discard injected		decryption needs to be attempted before a receiver is able to discard
	packets.		injected packets.
	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.
	skipping to change at page 36, line 6 ¶		skipping to change at page 36, line 6 ¶
	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, Thomas Fossati, and other members of the TSVWG for their		Wood, Thomas Fossati, and other members of the TSVWG for their
	comments and feedback.		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,
	opinions expressed and arguments employed reflect only the authors'		and the EU Stand ICT Call 4. The opinions expressed and arguments
	view. The European Commission is not responsible for any use that		employed reflect only the authors' view. The European Commission is
	may be made of that information.		not responsible for any use that 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.
	11. Informative References		11. Informative References
	[bufferbloat]		[bufferbloat]
	Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in		Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in
	the Internet. Communications of the ACM, 55(1):57-65",		the Internet. Communications of the ACM, 55(1):57-65",
	January 2012.		January 2012.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,		Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
	Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,		Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
	P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,		P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
	"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-		"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
	data-03 (work in progress), June 2018.		data-06 (work in progress), July 2019.
	[I-D.ietf-quic-spin-exp]		[I-D.ietf-quic-spin-exp]
	Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin		Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin
	Bit", draft-ietf-quic-spin-exp-01 (work in progress),		Bit", draft-ietf-quic-spin-exp-01 (work in progress),
	October 2018.		October 2018.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-14 (work		and Secure Transport", draft-ietf-quic-transport-22 (work
	in progress), August 2018.		in progress), July 2019.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-19		Browser-based Applications", draft-ietf-rtcweb-overview-19
	(work in progress), November 2017.		(work in progress), November 2017.
	[I-D.ietf-taps-transport-security]		[I-D.ietf-taps-transport-security]
	Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey		Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K.
	of Transport Security Protocols", draft-ietf-taps-		Rose, "A Survey of Transport Security Protocols", draft-
	transport-security-02 (work in progress), June 2018.		ietf-taps-transport-security-08 (work in progress), August
			2019.
	[I-D.ietf-tcpinc-tcpcrypt]		[I-D.ietf-tls-grease]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		Benjamin, D., "Applying GREASE to TLS Extensibility",
	Q., and E. Smith, "Cryptographic protection of TCP Streams		draft-ietf-tls-grease-04 (work in progress), August 2019.
	(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in
	progress), June 2018.
	[I-D.ietf-tsvwg-rtcweb-qos]		[I-D.ietf-tsvwg-rtcweb-qos]
	Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP		Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
	Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-		Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
	qos-18 (work in progress), August 2016.		qos-18 (work in progress), August 2016.
	[I-D.thomson-quic-grease]
	Thomson, M., "More Apparent Randomization for QUIC",
	draft-thomson-quic-grease-00 (work in progress), December
	2017.
	[I-D.trammell-plus-abstract-mech]		[I-D.trammell-plus-abstract-mech]
	Trammell, B., "Abstract Mechanisms for a Cooperative Path		Trammell, B., "Abstract Mechanisms for a Cooperative Path
	Layer under Endpoint Control", draft-trammell-plus-		Layer under Endpoint Control", draft-trammell-plus-
	abstract-mech-00 (work in progress), September 2016.		abstract-mech-00 (work in progress), September 2016.
	[I-D.trammell-wire-image]
	Trammell, B. and M. Kuehlewind, "The Wire Image of a
	Network Protocol", draft-trammell-wire-image-04 (work in
	progress), April 2018.
	[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of		[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of
	Techniques and Their Merits, IEEE Comm. Surveys &		Techniques and Their Merits, IEEE Comm. Surveys &
	Tutorials. 26;18(3) p2149-2196", November 2014.		Tutorials. 26;18(3) p2149-2196", November 2014.
	[Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement-		[Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement-
	based Protocol Design, Eur. Conf. on Networks and		based Protocol Design, Eur. Conf. on Networks and
	Communications, Oulu, Finland.", June 2017.		Communications, Oulu, Finland.", June 2017.
	[Quic-Trace]		[Quic-Trace]
	"https:QUIC trace utilities //github.com/google/quic-		"https:QUIC trace utilities //github.com/google/quic-
	skipping to change at page 43, line 5 ¶		skipping to change at page 42, line 30 ¶
	[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of		[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
	Pervasive Encryption on Operators", RFC 8404,		Pervasive Encryption on Operators", RFC 8404,
	DOI 10.17487/RFC8404, July 2018,		DOI 10.17487/RFC8404, July 2018,
	<https://www.rfc-editor.org/info/rfc8404>.		<https://www.rfc-editor.org/info/rfc8404>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
			Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
			2019, <https://www.rfc-editor.org/info/rfc8546>.
			[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
			Q., and E. Smith, "Cryptographic Protection of TCP Streams
			(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
			<https://www.rfc-editor.org/info/rfc8548>.
	Appendix A. Revision information		Appendix A. Revision information
	-00 This is an individual draft for the IETF community.		-00 This is an individual draft for the IETF community.
	-01 This draft was a result of walking away from the text for a few		-01 This draft was a result of walking away from the text for a few
	days and then reorganising the content.		days and then reorganising the content.
	-02 This draft fixes textual errors.		-02 This draft fixes textual errors.
	-03 This draft follows feedback from people reading this draft.		-03 This draft follows feedback from people reading this draft.
	skipping to change at page 44, line 37 ¶		skipping to change at page 44, line 37 ¶
	-07 Addressed feedback from Ruediger and Thomas.		-07 Addressed feedback from Ruediger and Thomas.
	Section 2 deserved some work to make it easier to read and avoid		Section 2 deserved some work to make it easier to read and avoid
	repetition. This edit finally gets to this, and eliminates some		repetition. This edit finally gets to this, and eliminates some
	duplication. This also moves some of the material from section 2 to		duplication. This also moves some of the material from section 2 to
	reform a clearer conclusion. The scope remains focussed on the usage		reform a clearer conclusion. The scope remains focussed on the usage
	of transport headers and the implications of encryption - not on		of transport headers and the implications of encryption - not on
	proposals for new techniques/specifications to be developed.		proposals for new techniques/specifications to be developed.
			-08 Addressed feedback and completed editorial work, including
			updating the text referring to RFC7872, in preparation for a WGLC.
	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. 114 change blocks.
	458 lines changed or deleted		466 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/