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/