draft-fairhurst-tsvwg-transport-encrypt-07.txt		draft-fairhurst-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.S. Perkins		Intended status: Informational C.S. Perkins
	Expires: October 10, 2018 University of Glasgow		Expires: November 21, 2018 University of Glasgow
	April 10, 2018		May 22, 2018
	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-fairhurst-tsvwg-transport-encrypt-07		draft-fairhurst-tsvwg-transport-encrypt-08
	Abstract		Abstract
	This document describes implications of applying end-to-end		This document describes implications of applying end-to-end
	encryption at the transport layer. It identifies in-network uses of		encryption at the transport layer. It identifies in-network uses of
	transport layer header information. It then reviews the implications		transport layer header information. It then reviews the implications
	of developing end-to-end transport protocols that use encryption to		of developing end-to-end transport protocols that use authentication
			to protect the integrity of transport information or encryption to
	provide confidentiality of the transport protocol header and expected		provide confidentiality of the transport protocol header and expected
	implications of transport protocol design and network operation.		implications of transport protocol design and network operation.
	Since transport measurement and analysis of the impact of network		Since transport measurement and analysis of the impact of network
	characteristics have been important to the design of current		characteristics have been important to the design of current
	transport protocols, it also considers the impact on transport and		transport protocols, it also considers the impact on transport and
	application evolution.		application 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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 10, 2018.		This Internet-Draft will expire on November 21, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Current uses of Transport Headers within the Network . . . . . 8		2. Current uses of Transport Headers within the Network . . . . . 8
	2.1. Observing Transport Information in the Network . . . . . . 9		2.1. Observing Transport Information in the Network . . . . . . 9
	2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9		2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9
	2.1.2. Metrics derived from Transport Layer Headers . . . . . 10		2.1.2. Metrics derived from Transport Layer Headers . . . . . 10
	2.1.3. Metrics derived from Network Layer Headers . . . . . . 12		2.1.3. Metrics derived from Network Layer Headers . . . . . . 13
	2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14		2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14
	2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 14		2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 15
	2.2.2. Use by Operators to Plan and Provision Networks . . . 15		2.2.2. Use by Operators to Plan and Provision Networks . . . 15
	2.2.3. Service Performance Measurement . . . . . . . . . . . 15		2.2.3. Service Performance Measurement . . . . . . . . . . . 16
	2.2.4. Measuring Transport to Support Network Operations . . 16		2.2.4. Measuring Transport to Support Network Operations . . 16
	2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17		2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17
	2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18		2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18
	2.4. Observing Headers to Implement Network Policy . . . . . . 19		2.4. Observing Headers to Implement Network Policy . . . . . . 19
	3. Encryption and Authentication of Transport Headers . . . . . . 19		3. Encryption and Authentication of Transport Headers . . . . . . 19
	3.1. Authenticating the Transport Protocol Header . . . . . . . 21		3.1. Authenticating the Transport Protocol Header . . . . . . . 21
	3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21		3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21
	3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21		3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21
	3.4. Authenticating Transport Information and Selectively		3.4. Authenticating Transport Information and Selectively
	Encrypting the Transport Header . . . . . . . . . . . . . 22		Encrypting the Transport Header . . . . . . . . . . . . . 22
	3.5. Optional Encryption of Header Information . . . . . . . . 22		3.5. Optional Encryption of Header Information . . . . . . . . 22
	4. Addition of Transport Information to Network-Layer Protocol		4. Addition of Transport Information to Network-Layer Protocol
	Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5. Implications of Protecting the Transport Headers . . . . . . . 23		5. Implications of Protecting the Transport Headers . . . . . . . 23
	5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23		5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23
	5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24		5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24
	5.3. Accountability and Internet Transport Protocols . . . . . 24		5.3. Accountability and Internet Transport Protocols . . . . . 25
	5.4. Impact on Research, Development and Deployment . . . . . . 25		5.4. Impact on Research, Development and Deployment . . . . . . 25
	6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26		6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 29		8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.1. Normative References . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . 30
	10.2. Informative References . . . . . . . . . . . . . . . . . 29		10.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. Revision information . . . . . . . . . . . . . . . . . 34		Appendix A. Revision information . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	This document describes implications of applying end-to-end		This document describes implications of applying end-to-end
	encryption at the transport layer. It reviews the implications of		encryption at the transport layer. It reviews the implications of
	developing end-to-end transport protocols that use encryption to		developing end-to-end transport protocols that use encryption to
	provide confidentiality of the transport protocol header and expected		provide confidentiality of the transport protocol header and expected
	implications of transport protocol design and network operation. It		implications of transport protocol design and network operation. It
	also considers anticipated implications on transport and application		also considers anticipated implications on transport and application
	evolution.		evolution.
	The transport layer provides the first end-to-end interactions across		The transport layer provides end-to-end interactions between
	the Internet. Transport protocols layer directly over the network-		endpoints (processes) using an Internet path. Transport protocols
	layer service and are sent in the payload of network-layer packets.		layer directly over the network-layer service and are sent in the
	They support end-to-end communication between applications, supported		payload of network-layer packets. They support end-to-end
	by higher-layer protocols, running on the end systems (or transport		communication between applications, supported by higher-layer
	endpoints). This simple architectural view hides one of the core		protocols, running on the end systems (or transport endpoints). This
	functions of the transport, however, to discover and adapt to the		simple architectural view hides one of the core functions of the
	properties of the Internet path that is currently being used. The		transport, however, to discover and adapt to the properties of the
	design of Internet transport protocols is as much about trying to		Internet path that is currently being used. The design of Internet
	avoid the unwanted side effects of congestion on a flow and other		transport protocols is as much about trying to avoid the unwanted
	capacity-sharing flows, avoiding congestion collapse, adapting to		side effects of congestion on a flow and other capacity-sharing
	changes in the path characteristics, etc., as it is about end-to-end		flows, avoiding congestion collapse, adapting to changes in the path
	feature negotiation, flow control and optimising for performance of a		characteristics, etc., as it is about end-to-end feature negotiation,
	specific application.		flow control and 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 insights of the network		has to date relied heavily on measurement and insights of the network
	operations community to understand the trade-offs, and to inform		operations community to understand the trade-offs, and to inform
	selection of appropriate mechanisms, to ensure a safe, reliable, and		selection of appropriate mechanisms, to ensure a safe, reliable, and
	robust Internet (e.g., [RFC1273]). In turn, the network operations		robust Internet (e.g., [RFC1273]). In turn, the network operations
	community relies on being able to understand the pattern and		community relies on being able to understand the pattern and
	requirements of traffic passing over the Internet, both in aggregate		requirements of traffic passing over the Internet, both in aggregate
	and at the flow level.		and at the flow level.
	There are many motivations for deploying encrypted transports (i.e.,		There are many motivations for deploying encrypted transports
	transport protocols that use encryption to provide confidentiality of		[RFC7624] (i.e., transport protocols that use encryption to provide
	some or all of the transport-layer header information), and		confidentiality of some or all of the transport-layer header
	encryption of transport payloads (i.e. confidentiality of the		information), and encryption of transport payloads (i.e.
	payload data). The increasing public concerns about the interference		confidentiality of the payload data). The increasing public concerns
	with Internet traffic have led to a rapidly expanding deployment of		about the interference with Internet traffic have led to a rapidly
	encryption to protect end-user privacy, in protocols like QUIC [I-D		expanding deployment of encryption to protect end-user privacy, in
	.ietf-quic-transport], but also expected to form a basis of future		protocols like QUIC [I-D.ietf-quic-transport], but also expected to
	protocol designs.		form a basis of future protocol designs.
	Implementations of network devices are encouraged to avoid side-		Some network operators and access providers, have come to rely on the
	effects when protocols are updated. Introducing cryptographic		in-network measurement of transport properties and the functionality
	integrity checks to header fields can also prevent undetected		provided by middleboxes to both support network operations and
	manipulation of the field by network devices, or undetected addition		enhance performance. There can therefore be implications when
	of information to a packet. However, this does not prevent		working with encrypted transport protocols that hide transport header
	inspection of the information by a device on path, and it is possible		information from the network. These present architectural challenges
	that such devices could develop mechanisms that rely on the presence		and considerations in the way transport protocols are designed, and
	of such a field, or a known value in the field. Reliance on the		ability to characterise and compare different transport solutions
	presence and semantics of packet headers leads to ossification: An		[Measure], Section 2.2. Implementations of network devices are
	endpoint could be required to supply a specific header to receive the		encouraged to avoid side-effects when protocols are updated.
	network service that it desires. In some cases, this could be benign		Introducing cryptographic integrity checks to header fields can also
	to the protocol (e.g., recognising the start of a connection), but		prevent undetected manipulation of the field by network devices, or
	not in all cases (e.g., a mechanism implemented in a network device,		undetected addition of information to a packet. However, this does
	such as a firewall, could require a header field to have only a		not prevent inspection of the information by a device on path, and it
	specific known set of values could prevent the device from forwarding		is possible that such devices could develop mechanisms that rely on
	packets using a different version of a protocol that introduces a new		the presence of such a field, or a known value in the field.
	feature that changes the value present in this field).
	A protocol design can use header encryption to provide		Reliance on the presence and semantics of specific header information
			leads to ossification: An endpoint could be required to supply a
			specific header to receive the network service that it desires. In
			some cases, this could be benign or advantageous to the protocol
			(e.g., recognising the start of a connection, or explicitly exposing
			protocol information can be expected to provide more consistent
			decisions by on-path devices than the use of diverse methods to infer
			semantics from other flow properties). In some cases, this is not
			beneficial (e.g., a mechanism implemented in a network device, such
			as a firewall, that required a header field to have only a specific
			known set of values could prevent the device from forwarding packets
			using a different version of a protocol that introduces a new feature
			that changes the value present in this field, preventing evolution of
			the protocol).
			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 imply semantics of an exposed header		the information or seeks to imply semantics of an exposed header
	field. Using encryption to provide confidentiality of the transport		field. Using encryption to provide confidentiality of the transport
	layer brings some well-known privacy and security benefits and can		layer brings some well-known privacy and security benefits and can
	therefore help reduce ossification of the transport layer. In		therefore help reduce ossification of the transport layer. In
	particular, it is important that protocols either do not expose		particular, it is important that protocols either do not expose
	information where the usage may change in future protocols, or that		information where the usage may change in future protocols, or that
	methods that utilise the information are robust to potential changes		methods that utilise the information are robust to potential changes
	as protocols evolve over time. To avoid unwanted inspection, a		as protocols evolve over time. To avoid unwanted inspection, a
	protocol could also intentionally vary the format and value of header		protocol could also intentionally vary the format and value of header
	fields (sometimes known as Greasing [I-D.thomson-quic-grease]).		fields (sometimes known as Greasing [I-D.thomson-quic-grease]).
	At the same time, some network operators and access providers, have		However, while encryption hides the protocol header information, it
	come to rely on the in-network measurement of transport properties		does not prevent ossification of the network service: People seeking
	and the functionality provided by middleboxes to both support network		understanding of network traffic could come to rely on pattern
	operations and enhance performance. There can therefore be		inferences and other heuristics as the basis for network decision and
	implications when working with encrypted transport protocols that		to derive measurement data, creating new dependencies on the
	hide transport header information from the network. This present		transport protocol.
	architectural challenges and considerations in the way transport
	protocols are designed, and ability to characterise and compare
	different transport solutions [Measure].
	A level of ossification of the header can be advantageous in terms of		A level of ossification of the transport header can offer trade-offs
	providing a set of specified header fields that become observable by		around authentication, and confidentiality of transport protocol
	in-network devices. This results in trade-offs around		headers and has the potential to explicitly support for other uses of
	authentication, and confidentiality of transport protocol headers and		this header information. For example, a design that provides
	the potential support for other uses of this header information. For		confidentiality of protocol header information can impact the
	example, a design that provides confidentiality of protocol header		following activities that rely on measurement and analysis of traffic
	information can impact the following activities that rely on		flows:
	measurement and analysis of traffic flows:
	Network Operations and Research: Observable transport headers enable		Network Operations and Research: Observable transport headers enable
	both operators and the research community to measure and analyse		both operators and the research community to measure and analyse
	protocol performance, network anomalies, and failure pathologies.		protocol performance, network anomalies, and failure pathologies.
	This information can help inform capacity planning, and assist in		This information can help inform capacity planning, and assist in
	determining the need for equipment and/or configuration changes by		determining the need for equipment and/or configuration changes by
	network operators.		network operators.
	The data can also inform Internet engineering research, and help		The data can also inform Internet engineering research, and help
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	Transport protocols can be designed to encrypt or authenticate		Transport protocols can be designed to encrypt or authenticate
	transport header fields. Authentication at the transport layer can		transport header fields. Authentication at the transport layer can
	be used to detect any changes to an immutable header field that were		be used to detect any changes to an immutable header field that were
	made by a network device along a path. The intentional modification		made by a network device along a path. The intentional modification
	of transport headers by middleboxes (such as Network Address		of transport headers by middleboxes (such as Network Address
	Translation, NAT, or Firewalls) is not considered. Common issues		Translation, NAT, or Firewalls) is not considered. Common issues
	concerning IP address sharing are described in [RFC6269].		concerning IP address sharing are described in [RFC6269].
	2.1. Observing Transport Information in the Network		2.1. Observing Transport Information in the Network
	In-network observation of transport protocol headers requires		If in-network observation of transport protocol headers is needed,
	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 for monitoring;		o Flows need to be identified at the level required to perform the
			observation;
	o The protocol and version of the header need to be observable. As		o The protocol and version of the header need to be visible. As
	protocols evolve over time and there may be a need to introduce		protocols evolve over time and there may be a need to introduce
	new transport headers. This may require interpretation of		new transport headers. This may require interpretation of
	protocol version information or connection setup information;		protocol version information or connection setup information;
	o Location and syntax of any transport headers needs to be known to		o The location and syntax of any observed transport headers needs to
	be observed. IETF transport protocols 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 may be utilised.		transport information has been utilised.
	2.1.1. Flow Identification		2.1.1. Flow Identification
	Transport protocol header information (together with information in		Transport protocol header information (together with information in
	the network header), can identify a flow and the connection state of		the network header), has been used to identify a flow and the
	the flow, together with the protocol options being used. In some		connection state of the flow, together with the protocol options
	usages, a low-numbered (well-known) transport port number can		being used. In some usages, a low-numbered (well-known) transport
	identify a protocol (although port information alone is not		port number has been used to identify a protocol (although port
	sufficient to guarantee identification of a protocol). Transport		information alone is not sufficient to guarantee identification of a
	protocols, such as TCP and Stream Control Transport Protocol (SCTP)		protocol). Transport protocols, such as TCP and Stream Control
	specify a standard base header that includes sequence number		Transport Protocol (SCTP) specify a standard base header that
	information and other data, with the possibility to negotiate		includes sequence number information and other data, with 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. UDP-based
	sometimes do not use, well-known port numbers. Some can instead be		protocols can use, but sometimes do not use, well-known port numbers.
	identified by signalling protocols or through the use of magic		Some can instead be identified by signalling protocols or through the
	numbers placed in the first byte(s) of the datagram payload.		use of magic numbers placed in the first byte(s) of the datagram
			payload.
	Flow identification is more complex and less easily achieved when		Flow identification is more complex and less easily achieved when
	multiplexing is used at or above the transport layer.		multiplexing is used at or above the transport layer.
	2.1.2. Metrics derived from Transport Layer Headers		2.1.2. Metrics derived from Transport Layer Headers
	Some actors manage their portion of the Internet by characterizing		Some actors manage their portion of the Internet by characterizing
	the performance of link/network segments. Passive monitoring uses		the performance of link/network segments. Passive monitoring uses
	observed traffic to makes inferences from transport headers to derive		observed traffic to makes inferences from transport headers to derive
	these measurements. A variety of open source and commercial tools		these measurements. A variety of open source and commercial tools
	have been deployed that utilise this information. The following		have been deployed that utilise this information. The following
	metrics can be derived from transport header information:		metrics can be derived from transport header information:
	Traffic Rate and Volume: Header information e.g., (sequence number,		Traffic Rate and Volume: Header information e.g., (sequence number,
	length) may allow derivation of volume measures per-application,		length) allows derivation of volume measures per-application, to
	to characterise the traffic that uses a network segment or the		characterise the traffic that uses a network segment or the
	pattern of network usage. This may be measured per endpoint or		pattern of network usage. This may be measured per endpoint or
	for an aggregate of endpoints (e.g., by an operator to assess		for an aggregate of endpoints (e.g., by an operator 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 (providing detail of trends rather than the		capacity planning (providing detail of trends rather than the
	volume per subscriber).		volume per subscriber).
	Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from		Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from
	sequence number) and is often used as a metric for performance		sequence number) and has been used as a metric for performance
	assessment and to characterise transport behaviour. Understanding		assessment and to characterise transport behaviour. Understanding
	the root cause of loss can help an operator determine whether this		the root cause of loss can help an operator determine whether this
	requires corrective action. Network operators may also use the		requires corrective action. Network operators have used the
	variation in patterns of loss as a key performance metric,		variation in patterns of loss as a key performance metric,
	utilising this to detect changes in the offered service.		utilising this to detect changes in the 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), inadequate		management (e.g., Active Queue Management, AQM), inadequate
	provision of traffic preemption. Understanding flow loss rate		provision of traffic preemption. Understanding flow loss rate
	requires either maintaining per flow packet counters or by		requires either maintaining per flow packet counters or by
	observing sequence numbers in transport headers. Loss can be		observing sequence numbers in transport headers. Loss can be
	skipping to change at page 11, line 39 ¶		skipping to change at page 12, line 5 ¶
	network buffers has often been observed as a significant factor.		network buffers has often been observed as a significant factor.
	Once the cause of unwanted latency has been identified, this can		Once the cause of unwanted latency has been identified, this can
	often be eliminated.		often be eliminated.
	To measure latency across a part of a path, an observation point		To measure latency across a part of a path, an observation point
	can measure the experienced round trip time (RTT) using packet		can measure the experienced round trip time (RTT) using packet
	sequence numbers, and acknowledgements, or by observing header		sequence numbers, and acknowledgements, or by observing header
	timestamp information. Such information allows an observation		timestamp information. Such information allows an observation
	point in the network to determine not only the path RTT, but also		point in the network to determine not only the path RTT, but also
	to measure the upstream and downstream contribution to the RTT.		to measure the upstream and downstream contribution to the RTT.
	This can be used to locate a source of latency, e.g., by observing		This has been used to locate a source of latency, e.g., by
	cases where the ratio of median to minimum RTT is large for a part		observing cases where the ratio of median to minimum RTT is large
	of a path.		for a part of a path.
	The service offered by operators can benefit from latency		The service offered by operators can benefit from latency
	information to understand the impact of deployment and tune		information to understand the impact of deployment and tune
	deployed services. Latency metrics are key to evaluating and		deployed services. Latency metrics are key to evaluating and
	deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit		deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
	Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements		Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
	could identify excessively large buffers, indicating where to		could identify excessively large buffers, indicating where to
	deploy or configure AQM. An AQM method is often deployed in		deploy or configure AQM. An AQM method is often deployed in
	combination with other techniques, such as scheduling [RFC7567]		combination with other techniques, such as scheduling [RFC7567]
	[I-D.ietf-aqm-fq-codel] and although parameter-less methods are		[I-D.ietf-aqm-fq-codel] and although parameter-less methods are
	skipping to change at page 12, line 54 ¶		skipping to change at page 13, line 21 ¶
	context under which the data was collected, including the time,		context under which the data was collected, including the time,
	observation point, and way in which metrics were accumulated. The		observation point, and way in which metrics were accumulated. The
	RTCP protocol directly reports some of this information in a form		RTCP protocol directly reports some of this information in a form
	that can be directly visible in the network. A user of summary		that can be directly visible in the network. A user of summary
	measurement data needs to trust the source of this data and the		measurement data needs to trust the source of this data and the
	method used to generate the summary information.		method used to generate the summary information.
	2.1.3. Metrics derived from Network Layer Headers		2.1.3. Metrics derived from Network Layer Headers
	Some transport information is made visible in the network-layer		Some transport information is made visible in the network-layer
	protocol header. These header fields are not encrypted and can be		protocol header. These header fields are not encrypted and have been
	utilised to make flow observations.		utilised to make flow observations.
	Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose		Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose
	flow information in the IPv6 Flow Label field of the network-layer		flow information in the IPv6 Flow Label field of the network-layer
	header (e.g., [RFC8085]). This can be used to inform network-layer		header (e.g., [RFC8085]). This can be used to inform network-layer
	queuing, forwarding (e.g., for equal cost multi-path, ECMP,		queuing, forwarding (e.g., for equal cost multi-path, ECMP,
	routing, and Link Aggregation, LAG). This can provide useful		routing, and Link Aggregation, LAG). This can provide useful
	information to assign packets to flows in the data collected by		information to assign packets to flows in the data collected by
	measurement campaigns. Although important to characterising a		measurement campaigns. Although important to characterising a
	path, it does not directly provide performance data.		path, it does not directly provide performance data.
	skipping to change at page 14, line 34 ¶		skipping to change at page 15, line 7 ¶
	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
	inferences and other heuristics reliance on pattern inferences and		inferences and other heuristics reliance on pattern inferences and
	accuracy suffers. For example, the traffic patterns between server		accuracy suffers. For example, the traffic patterns between server
	and browser are dependent on browser supplier and version, even when		and browser are dependent on browser supplier and version, even when
	the sessions use the same server application (e.g., web e-mail		the sessions use the same server application (e.g., web e-mail
	access). It remains to be seen whether more complex inferences can be		access). It remains to be seen whether more complex inferences can be
	mastered to produce the same monitoring accuracy [I-D.mm-wg-effect-		mastered to produce the same monitoring accuracy (see section 2.1.1
	encrypt].		of [I-D.mm-wg-effect-encrypt]).
	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. Collecting and coordinating		often required to interpret this data. Collecting and coordinating
	such metadata is more difficult when the observation point is at a		such metadata is more difficult when the observation point is at a
	different location to the bottleneck/device under evaluation.		different location to the bottleneck/device under evaluation.
	Packet sampling techniques can be used to scale the processing		Packet sampling techniques can be used to scale the processing
	involved in observing packets on high rate links. This exports only		involved in observing packets on high rate links. This exports only
	the packet header information of (randomly) selected packets. The		the packet header information of (randomly) selected packets. The
	skipping to change at page 17, line 39 ¶		skipping to change at page 18, line 4 ¶
	the offered service.		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		the RTP and RTCP header information of real-time flows (see
	Section 2.1.2.		Section 2.1.2.
	2.3. Use for Network Diagnostics and Troubleshooting		2.3. Use for Network Diagnostics and Troubleshooting
			Transport header information can be useful for a variety of
	Transport header information is useful for a variety of operational		operational tasks [I-D.mm-wg-effect-encrypt]: to diagnose network
	tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems,		problems, assess network provider performance, evaluate equipment/
	assess performance, capacity planning, management of denial of		protocol performance, capacity planning, management of security
	service threats, and responding to user performance questions. These		threats (including denial of service), and responding to user
	tasks seldom involve the need to determine the contents of the		performance questions. Sections 3.1.2 and 5 of [I-D.mm-wg-effect-
	transport payload, or other application details.		encrypt] provide further examples. These tasks seldom involve the
			need to determine the 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 information may reduce		protocol information. Choosing to encrypt all the information
	the ability for networks to "help" (e.g., in response to tracing		reduces the operator's ability to observe transport performance, and
	issues, making appropriate QoS decisions). For some this will be		may limit the ability of network operators to trace problems, make
	blessing, for others it may be a curse. For example, operational		appropriate QoS decisions, or response to other queries about the
	performance data about encrypted flows needs to be determined by		network service. For some this will be blessing, for others it may
	traffic pattern analysis, rather than relying on traditional tools.		be a curse. For example, operational performance data about
	This can impact the ability of the operator to respond to faults, it		encrypted flows needs to be determined by traffic pattern analysis,
	could require reliance on endpoint diagnostic tools or user		rather than relying on traditional tools. This can impact the
	involvement in diagnosing and troubleshooting unusual use cases or		ability of the operator to respond to faults, it could require
	non-trivial problems. A key need here is for tools to provide useful		reliance on endpoint diagnostic tools or user involvement in
	information during network anomalies (e.g., significant reordering,		diagnosing and troubleshooting unusual use cases or non-trivial
	high or intermittent loss). Although many network operators utilise		problems. A key need here is for tools to provide useful information
	transport information as a part of their operational practice, the		during network anomalies (e.g., significant reordering, high or
	network will not break because transport headers are encrypted, and		intermittent loss). Although many network operators utilise transport
	this may require alternative tools may need to be developed and		information as a part of their operational practice, the network will
	deployed.		not break because transport headers are encrypted, and this may
			require alternative tools may need to be developed and deployed.
	2.3.1. Examples of measurements		2.3.1. Examples of measurements
	Measurements can be used to monitor the health of a portion of the		Measurements can be used to monitor the health of a portion of the
	Internet, to provide early warning of the need to take action. They		Internet, to provide early warning of the need to take action. They
	can assist in debugging and diagnosing the root causes of faults that		can assist in debugging and diagnosing the root causes of faults that
	concern a particular user's traffic. They can also be used to		concern a particular user's traffic. They can also be used to
	support post-mortem inverstigation after an anompoly to determine the		support post-mortem investigation after an anomaly to determine the
	root cause of a problem.		root cause of a problem.
	In some case, measurements may involve active injection of test		In some case, measurements may involve active injection of test
	traffic to complete a measurement. However, most operators do not		traffic to complete a measurement. However, most operators do not
	have access to user equipment, and injection of test traffic may be		have access to user equipment, and injection of test traffic may be
	associated with costs in running such tests (e.g., the implications		associated with costs in running such tests (e.g., the implications
	of bandwidth tests in a mobile network are obvious). Some active		of bandwidth tests in a mobile network are obvious). Some active
	measurements (e.g., response under load or particular workloads)		measurements (e.g., response under load or particular workloads)
	perturb other traffic, and could require dedicated access to the		perturb other traffic, and could require dedicated access to the
	network segment. An alternative approach is to use in-network		network segment. An alternative approach is to use in-network
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 28 ¶
	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.
	2.4. Observing Headers to Implement Network Policy		2.4. Observing Headers to Implement Network Policy
	Information from the transport protocol can be used by a multi-field		Information from the transport protocol can be used by a multi-field
	classifier as a part of policy framework. Policies are commonly used		classifier as a part of policy framework. Policies are commonly used
	for management of the QoS or Quality of Experience (QoE) in resource-		for management of the QoS or Quality of Experience (QoE) in resource-
	constrained networks and by firewalls that use the information to		constrained networks and by firewalls that use the information to
	implement access rules. Traffic that cannot be classified, will		implement access rules (see also section 2.2.2 of [I-D.mm-wg-effect-
	typically receive a default treatment.		encrypt]). Traffic that cannot be classified, will typically receive
			a default treatment.
	3. Encryption and Authentication of Transport Headers		3. 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
	skipping to change at page 20, line 13 ¶		skipping to change at page 20, line 22 ¶
	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 [I-D.trammell-plus-		to always consider deployed middleboxes [I-D.trammell-plus-
	abstract-mech], or potentially to only explicitly enable middlebox		abstract-mech], or potentially to only explicitly enable middlebox
	use for particular paths with particular middleboxes that are		use for particular paths with particular middleboxes that are
	deliberately deployed to realise a useful function for the network		deliberately deployed to realise a useful function for the network
	and/or users[RFC3135].		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 ESP. Revelations		analysis, and have used methods such as IPsec Encapsulated
	about the use of pervasive surveillance [RFC7624] have, to some		Security Payload (ESP), Virtual Private Networks (VPNs) and other
	extent, eroded trust in the service offered by network operators,		encrypted tunnel technologies. Revelations about the use of
	and following the Snowden revelation in the USA in 2013 has led to		pervasive surveillance [RFC7624] have, to some extent, eroded
	an increased desire for people to employ encryption to avoid		trust in the service offered by network operators, and following
	unwanted "eavesdropping" on their communications. Concerns have		the Snowden revelation in the USA in 2013 has led to an increased
	also been voiced about the addition of information to packets by		desire for people to employ encryption to avoid unwanted
	third parties to provide analytics, customization, advertising,		"eavesdropping" on their communications. Concerns have also been
	cross-site tracking of users, to bill the customer, or to		voiced about the addition of information to packets by third
	selectively allow or block content. Whatever the reasons, there		parties to provide analytics, customization, advertising, cross-
	are now activities in the IETF to design new protocols that may		site tracking of users, to bill the customer, or to selectively
	include some form of transport header encryption (e.g., QUIC [I-D		allow or block content. Whatever the reasons, there are now
	.ietf-quic-transport]).		activities in the IETF to design new protocols that may include
			some form of transport header encryption (e.g., QUIC [I-D.ietf-
			quic-transport]).
	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], the DSCP and ECN.		Flow Label [RFC6437], the DSCP and ECN.
	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
	skipping to change at page 20, line 51 ¶		skipping to change at page 21, line 9 ¶
	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 of transport header		Whatever the motives, a decision to use pervasive of 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, and which can in turn impact the direction
	of evolution of the TCP/IP stack.		of evolution of the TCP/IP stack. While the IETF can specify
			protocols, the success in actual deployment is often determined by
			many factors [RFC5218] that are not always clear at the time when
			protocols are being defined.
	The next subsections briefly review some security design options for		The next subsections briefly review some security design options for
	transport protocols.		transport protocols. A Survey of Transport Security Protocols [I-D
			.ietf-taps-transport-security] provides more details concerning
			commonly used encryption methods at the transport layer.
	3.1. Authenticating the Transport Protocol Header		3.1. Authenticating the Transport Protocol Header
	Transport layer header information can be authenticated. An		Transport layer header information can be authenticated. An
	integrity check that protects the immutable transport header fields,		integrity check that protects the immutable transport header fields,
	but can still expose the transport protocol header information in the		but can still expose the transport protocol header information in the
	clear, allowing in-network devices to observes these fields. An		clear, allowing in-network devices to observes these fields. An
	integrity check can not prevent in-network modification, but can		integrity check can not prevent in-network modification, but can
	avoid a receiving accepting changes and avoid impact on the transport		avoid a receiving accepting changes and avoid impact on the transport
	protocol operation.		protocol operation.
	An example transport authentication mechanism is TCP-Authentication		An example transport authentication mechanism is TCP-Authentication
	(TCP-AO) [RFC5925]. This TCP option authenticates TCP segments,		(TCP-AO) [RFC5925]. This TCP option authenticates the IP pseudo
	including the IP pseudo header, TCP header, and TCP data. TCP-AO		header, TCP header, and TCP data. TCP-AO protects the transport
	protects the transport layer, preventing attacks from disabling the		layer, preventing attacks from disabling the TCP connection itself
	TCP connection itself. TCP-AO may interact with middleboxes,		and provides replay protection. TCP-AO may interact with
	depending on their behaviour [RFC3234].		middleboxes, depending on their behaviour [RFC3234].
	The IPsec Authentication Header (AH) [RFC4302] was designed to work		The IPsec Authentication Header (AH) [RFC4302] was designed to work
	at the network layer and authenticate the IP payload. This approach		at the network layer and authenticate the IP payload. This approach
	authenticates all transport headers, and verifies their integrity at		authenticates all transport headers, and verifies their integrity at
	the receiver, preventing in-network modification.		the receiver, preventing in-network modification.
	3.2. Encrypting the Transport Payload		3.2. Encrypting the Transport Payload
	The transport layer payload can be encrypted to protect the content		The transport layer payload can be encrypted to protect the content
	of transport segments. This leaves transport protocol header		of transport segments. This leaves transport protocol header
	information in the clear. The integrity of immutable transport		information in the clear. The integrity of immutable transport
	header fields could be protected by combining this with an integrity		header fields could be protected by combining this with an integrity
	check (Section 3.1).		check (Section 3.1).
	Examples of encrypting the payload include Transport Layer Security		Examples of encrypting the payload include Transport Layer Security
	(TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP		(TLS) over TCP [RFC5246] [RFC7525], Datagram TLS (DTLS) over UDP
	[RFC6347] [RFC7525].		[RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which
			permits opportunistic encryption of the TCP transport payload.
	3.3. Encrypting the Transport Header		3.3. Encrypting the Transport Header
	The network layer payload could be encrypted (including the entire		The network layer payload could be encrypted (including the entire
	transport header and payload). This method does not expose any		transport header and the payload). This method provides
	transport information to devices in the network, which also prevents		confidentiality of the entire transport packet. It therefore does
	modification along a network path.		not expose any transport information to devices in the network, which
			also prevents modification along a network path.
	The IPsec Encapsulating Security Payload (ESP) [RFC4303] is an		One example of encryption at the network layer is use of IPsec
	example of encryption at the network layer, it encrypts and		Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This
	authenticates all transport headers, preventing visibility of the		encrypts and authenticates all transport headers, preventing
	headers by in-network devices. Some Virtual Private Network (VPN)		visibility of the transport headers by in-network devices. Some
	methods also encrypt these headers.		Virtual Private Network (VPN) methods also encrypt these headers.
	3.4. Authenticating Transport Information and Selectively Encrypting		3.4. Authenticating Transport Information and Selectively Encrypting
	the Transport Header		the Transport Header
	A transport protocol design can encrypt selected header fields, while		A transport protocol design can encrypt selected header fields, while
	also choosing to authenticate fields in the transport header. This		also choosing to authenticate fields in the transport header. This
	allows specific transport header fields to be made observable by		allows specific transport header fields to be made observable by
	network devices. End-to end integrity checks can prevent an endpoint		network devices. End-to end integrity checks can prevent an endpoint
	from undetected modification of the immutable transport headers.		from undetected modification of the immutable transport headers.
	skipping to change at page 24, line 48 ¶		skipping to change at page 25, line 4 ¶
	of the traffic aggregate passing through a network device or segment		of the traffic aggregate passing through a network device or segment
	of the network the path, the dynamics of the uncharacterised traffic		of the network the path, the dynamics of the uncharacterised traffic
	may not have a significant collateral impact on the performance of		may not have a significant collateral impact on the performance of
	other traffic that shares this network segment. Once the proportion		other traffic that shares this network segment. Once the proportion
	of this traffic increases, the need to monitor the traffic and		of this traffic increases, the need to monitor the traffic and
	determine if appropriate safety measures need to be put in place.		determine if appropriate safety measures need to be put in place.
	Tracking the impact of new mechanisms and protocols requires traffic		Tracking the impact of new mechanisms and protocols requires traffic
	volume to be measured and new transport behaviours to be identified.		volume to be measured and new transport behaviours to be identified.
	This is especially true of protocols operating over a UDP substrate.		This is especially true of protocols operating over a UDP substrate.
	The level and style of encryption needs to be considered in		The level and style of encryption needs to be considered in
	determining how this activity is performed. On a shorter timescale,		determining how this activity is performed. On a shorter timescale,
	information may also need to be collected to manage denial of service		information may also need to be collected to manage denial of service
	attacks against the infrastructure.		attacks against the infrastructure.
	5.3. Accountability and Internet Transport Protocols		5.3. Accountability and Internet Transport Protocols
	Information provided by tools observing transport headers can help		Information provided by tools observing transport headers can be used
	determine whether mechanisms are needed in the network to prevent		to classify traffic, and to limit the network capacity used by
	flows from acquiring excessive network capacity, and where needed to		certain flows. Operators can potentially use this information to
	deploy appropriate tools Section 2.2.4. Obfuscating or hiding this		prioritise or de-prioritise certain flows or classes of flow, with
			potential implications for network neutrality, or to rate limit
			malicious or otherwise undesirable flows (e.g., for DDoS protection,
			or to ensure compliance with a traffic profile Section 2.2.4).
			Equally, operators could use analysis of transport headers and
			transport flow state to demonstrate that they are not providing
			differential treatment to certain flows. Obfuscating or hiding this
	information using encryption is expected to lead operators and		information using encryption is expected to lead operators and
	maintainers of middleboxes (firewalls, etc.) to seek other methods to		maintainers of middleboxes (firewalls, etc.) to seek other methods to
	classify and mechanisms to condition network traffic.		classify, and potentially other mechanisms to condition, network
			traffic.
	A lack of data reduces the level of precision with which mechanisms		A lack of data reduces the level of precision with which flows can be
	are applied, and this needs to be considered when evaluating the		classified and conditioning mechanisms are applied (e.g., rate
	impact of designs for transport encryption. This could lead to		limiting, circuit breaker techniques [RFC8084], or blocking of
	increased use of rate limiting, circuit breaker techniques [RFC8084],		uncharacterised traffic), and this needs to be considered when
	or even blocking of uncharacterised traffic. This would hinder		evaluating the impact of designs for transport encryption [RFC5218].
	deployment of new mechanisms and/or protocols.
	5.4. Impact on Research, Development and Deployment		5.4. Impact on Research, Development and Deployment
	The majority of present Internet applications use two well-known		The majority of present Internet applications use two well-known
	transport protocols: e.g., TCP and UDP. Although TCP represents the		transport protocols: e.g., TCP and UDP. Although TCP represents the
	majority of current traffic, some important real-time applications		majority of current traffic, some important real-time applications
	use UDP, and much of this traffic utilises RTP format headers in the		use UDP, and much of this traffic utilises RTP format headers in the
	payload of the UDP datagram. Since these protocol headers have been		payload of the UDP datagram. Since these protocol headers have been
	fixed for decades, a range of tools and analysis methods have became		fixed for decades, a range of tools and analysis methods have became
	common and well-understood. Over this period, the transport protocol		common and well-understood. Over this period, the transport protocol
	headers have mostly changed slowly, and so also the need to develop		headers have mostly changed slowly, and so also the need to develop
	tools track new versions of the protocol.		tools track new versions of the protocol.
	Looking ahead, there will be a need to update these protocols and to		Looking ahead, there will be a need to update these protocols and to
	develop and deploy new transport mechanisms and protocols. There are		develop and deploy new transport mechanisms and protocols. There are
	both opportunities and also challenges to the design, evaluation and		both opportunities and also challenges to the design, evaluation and
	deployment of new transport protocol mechanisms.		deployment of new transport protocol mechanisms.
	Integrity checks can undetected modification of protocol fields by		Integrity checks can protect an endpoint from undetected modification
	network devices, whereas encryption and obfuscation can further		of protocol fields by network devices, whereas encryption and
	prevent these headers being utilised by network devices. Hiding		obfuscation can further prevent these headers being utilised by
	headers can therefore provide the opportunity for greater freedom to		network devices. Hiding headers can therefore provide the
	update the protocols and can ease experimentation with new techniques		opportunity for greater freedom to update the protocols and can ease
	and their final deployment in endpoints.		experimentation with new techniques and their final deployment in
			endpoints.
	Hiding headers can limit the ability to measure and characterise		Hiding headers can limit the ability to measure and characterise
	traffic. Measurement data is increasingly being used to inform		traffic. Measurement data is increasingly being used to inform
	design decisions in networking research, during development of new		design decisions in networking research, during development of new
	mechanisms and protocols and in standardisation. Measurement has a		mechanisms and protocols and in standardisation. Measurement has a
	critical role in the design of transport protocol mechanisms and		critical role in the design of transport protocol mechanisms and
	their acceptance by the wider community (e.g., as a method to judge		their acceptance by the wider community (e.g., as a method to judge
	the safety for Internet deployment). Observation of pathologies are		the safety for Internet deployment). Observation of pathologies are
	also important in understanding the interactions between cooperating		also important in understanding the interactions between cooperating
	protocols and network mechanism, the implications of sharing capacity		protocols and network mechanism, the implications of sharing capacity
	skipping to change at page 27, line 12 ¶		skipping to change at page 27, line 30 ¶
	transport protocol headers have mostly changed slowly, and so also		transport protocol headers have mostly changed slowly, and so also
	the need to develop tools track new versions of the protocol.		the need to develop tools track new versions of the protocol.
	Confidentiality and strong integrity checks have properties that are		Confidentiality and strong integrity checks have properties that are
	being incorporated into new protocols and which have important		being incorporated into new protocols and which 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 QUIC prototype transports		data channel and the rapid deployment of QUIC prototype transports
	can both be attributed to using a combination of UDP transport and		can both be attributed to using a combination of UDP transport and
	confidentiality of the UDP payload.		confidentiality of the UDP payload.
	The traffic that can be observed by devices in a network 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 small		applications and user characteristics. In general, when only a small
	proportion of the traffic has a specific (different) characteristic.		proportion of the traffic has a specific (different) characteristic.
	Such traffic seldom leads to an operational issue although the		Such traffic seldom leads to an operational issue although the
	ability to measure and monitor it is less. The desire to understand		ability to measure and monitor it is less. The desire to understand
	the traffic and protocol interactions typically grows as the		the traffic and protocol interactions typically grows as the
	proportion of traffic increases in volume. The challenges increase		proportion of traffic increases in volume. The challenges increase
	when multiple instances of an evolving protocol contribute to the		when multiple instances of an evolving protocol contribute to the
	traffic that share network capacity.		traffic that share network capacity.
	skipping to change at page 27, line 42 ¶		skipping to change at page 28, line 18 ¶
	developed to catch-up with the changes. If the currently deployed		developed to catch-up with the changes. If the currently deployed
	tools and methods are no longer relevant and performance may not be		tools and methods are no longer relevant and performance may not be
	correctly measured. This can increase the response-time after		correctly measured. This can increase the response-time after
	faults, and can impact the ability to manage the network resulting in		faults, and can impact the ability to manage the network resulting in
	traffic causing traffic to be treated inappropriately (e.g., rate		traffic causing traffic to be treated inappropriately (e.g., rate
	limiting because of being incorrectly classified/monitored). There		limiting because of being incorrectly classified/monitored). There
	are benefits in exposing consistent information to the network that		are benefits in exposing consistent information to the network that
	avoids traffic being mis-classified and then receiving a default		avoids traffic being mis-classified and then receiving a default
	treatment by the network.		treatment by the network.
	A protocol specification therefore needs to weigh the benefits of		As a part of its design a new protocol specification therefore needs
	ossifying common headers, versus the potential demerits of exposing		to weigh the benefits of ossifying common headers, versus the
	specific information that could be observed along the network path to		potential demerits of exposing specific information that could be
	provide tools to manage new variants of protocols. Several scenarios		observed along the network path to provide tools to manage new
	to illustrate different ways this could evolve are provided below:		variants of protocols. Several scenarios to illustrate different
			ways this could evolve are provided below:
	o One scenario is when transport protocols provide consistent		o One scenario is when transport protocols provide consistent
	information to the network by intentionally exposing a part of the		information to the network by intentionally exposing a part of the
	transport header. The design fixes the format of this information		transport header. The design fixes the format of this information
	between versions of the protocol. This level of ossification		between versions of the protocol. This ossification of the
	allows an operator to establish tooling and procedures that allow		transport header allows an operator to establish tooling and
	it to provide consistent traffic management as the protocol		procedures that enable it to provide consistent traffic management
	evolves. In contrast to TCP (where all protocol information is		as the protocol evolves. In contrast to TCP (where all protocol
	exposed), evolution of the transport is facilitated by providing		information is exposed), evolution of the transport is facilitated
	cryptographic integrity checks of the transport header fields		by providing cryptographic integrity checks of the transport
	(preventing undetected middlebox changes) and encryption of other		header fields (preventing undetected middlebox changes) and
	protocol information (preventing observation within the network).		encryption of other protocol information (preventing observation
	The transport information can be used by operators to provide		within the network, or incentivising the use of the exposed
	troubleshooting, easement and any necessary functions for the		information, rather than inferring information from other
	class of traffic (priority, retransmission, reordering, circuit		characteristics of the flow traffic). The exposed transport
			information can be used by operators to provide troubleshooting,
			measurement and any necessary functions appropriate to the class
			of traffic (priority, retransmission, reordering, circuit
	breakers, etc).		breakers, etc).
	o An alternative scenario adopts different design goals, with a		o An alternative scenario adopts different design goals, with a
	different outcome. A protocol that encrypts all header		different outcome. A protocol that encrypts all header
	information forces network operators to act independently from		information forces network operators to act independently from
	apps/transport developments to provide the transport information		apps/transport developments to provide the transport information
	they need. A range of approaches may proliferate, as in current		they need. A range of approaches may proliferate, as in current
	networks, operators can add a shim header to each packet as a flow		networks, operators can add a shim header to each packet as a flow
	as it crosses the network; other operators/managers could develop		as it crosses the network; other operators/managers could develop
	heuristics and pattern recognition to derive information that		heuristics and pattern recognition to derive information that
	classifies flows and estimates quality metrics for the service		classifies flows and estimates quality metrics for the service
	being used; some could decide to rate-limit or block traffic until		being used; some could decide to rate-limit or block traffic until
	new tooling is in place. In many cases, the derived information		new tooling is in place. In many cases, the derived information
	can be used by operators to provide necessary functions		can be used by operators to provide necessary functions
	appropriate to the class of traffic (priority, retransmission,		appropriate to the class of traffic (priority, retransmission,
	reordering, circuit breakers, etc). Troubleshooting, and		reordering, circuit breakers, etc). Troubleshooting, and
	measurement becomes more difficult, and more diverse. This could		measurement becomes more difficult, and more diverse. This could
	require additional information beyond that visible in the packet		require additional information beyond that visible in the packet
	header and. In some cases, operators might need access to keying		header and when this information is used to inform decisions by
			on-path devices it can lead to dependency on other characteristics
			of the flow. In some cases, operators might need access to keying
	information to interpret encrypted data that they observe. Some		information to interpret encrypted data that they observe. Some
	use cases could demand use of transports that do not use		use cases could demand use of transports that do not use
	encryption.		encryption.
	The outcome could have significant implications on the way the		The outcome could have significant implications on the way the
	Internet architecture develops. It exposes a risk that significant		Internet architecture develops. It exposes a risk that significant
	actors (e.g., developers and transport designers) achieve more		actors (e.g., developers and transport designers) achieve more
	control of the way in which the Internet architecture develops.In		control of the way in which the Internet architecture develops.In
	particular, there is a possibility that designs could evolve to		particular, there is a possibility that designs could evolve to
	significantly benefit of customers for a specific vendor, and that		significantly benefit of customers for a specific vendor, and that
	skipping to change at page 30, line 39 ¶		skipping to change at page 31, line 34 ¶
	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", Internet-Draft draft-ietf-		"Data Fields for In-situ OAM", Internet-Draft draft-ietf-
	ippm-ioam-data-02, March 2018.		ippm-ioam-data-02, March 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", Internet-Draft draft-ietf-quic-		and Secure Transport", Internet-Draft draft-ietf-quic-
	transport-03, May 2017.		transport-03, May 2017.
			[I-D.ietf-taps-transport-security]
			Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of
			Transport Security Protocols", Internet-Draft draft-ietf-
			taps-transport-security-01, May 2018.
			[I-D.ietf-tcpinc-tcpcrypt]
			Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
			Q. and E. Smith, "Cryptographic protection of TCP Streams
			(tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11,
			November 2017.
	[I-D.ietf-tcpm-accurate-ecn]		[I-D.ietf-tcpm-accurate-ecn]
	Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More		Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More
	Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-		Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-
	tcpm-accurate-ecn-06, March 2018.		tcpm-accurate-ecn-06, March 2018.
	[I-D.ietf-tsvwg-l4s-arch]		[I-D.ietf-tsvwg-l4s-arch]
	Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency,		Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency,
	Low Loss, Scalable Throughput (L4S) Internet Service:		Low Loss, Scalable Throughput (L4S) Internet Service:
	Architecture", Internet-Draft draft-ietf-tsvwg-l4s-		Architecture", Internet-Draft draft-ietf-tsvwg-l4s-
	arch-01, October 2017.		arch-01, October 2017.
	skipping to change at page 32, line 43 ¶		skipping to change at page 33, line 47 ¶
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
	10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/		10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/
	info/rfc4585>.		info/rfc4585>.
	[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.		[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.
	and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI		and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI
	10.17487/RFC4737, November 2006, <http://www.rfc-		10.17487/RFC4737, November 2006, <http://www.rfc-
	editor.org/info/rfc4737>.		editor.org/info/rfc4737>.
			[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
			Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
			<https://www.rfc-editor.org/info/rfc5218>.
	[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R.		[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R.
	Whitner, "Improved Packet Reordering Metrics", RFC 5236,		Whitner, "Improved Packet Reordering Metrics", RFC 5236,
	DOI 10.17487/RFC5236, June 2008, <http://www.rfc-		DOI 10.17487/RFC5236, June 2008, <http://www.rfc-
	editor.org/info/rfc5236>.		editor.org/info/rfc5236>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/		(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
	RFC5246, August 2008, <http://www.rfc-editor.org/info/		RFC5246, August 2008, <http://www.rfc-editor.org/info/
	rfc5246>.		rfc5246>.
	skipping to change at page 35, line 8 ¶		skipping to change at page 36, line 21 ¶
	-05 Corrections received and helpful inputs from Mohamed Boucadair.		-05 Corrections received and helpful inputs from Mohamed Boucadair.
	-06 Updated following comments from Stephen Farrell, and feedback via		-06 Updated following comments from Stephen Farrell, and feedback via
	email. Added a draft conclusion section to sketch some strawman		email. Added a draft conclusion section to sketch some strawman
	scenarios that could emerge.		scenarios that could emerge.
	-07 Updated following comments from Al Morton, Chris Seal, and other		-07 Updated following comments from Al Morton, Chris Seal, and other
	feedback via email.		feedback via email.
			-08 Updated to address comments sent to the TSVWG mailing list by
			Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 11/05/
			2018, and Spencer Dawkins.
	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. 53 change blocks.
	198 lines changed or deleted		256 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/