draft-ietf-tsvwg-transport-encrypt-11.txt   draft-ietf-tsvwg-transport-encrypt-12.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: August 3, 2020 University of Glasgow Expires: August 29, 2020 University of Glasgow
January 31, 2020 February 26, 2020
Considerations around Transport Header Confidentiality, Network Considerations around Transport Header Confidentiality, Network
Operations, and the Evolution of Internet Transport Protocols Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-11 draft-ietf-tsvwg-transport-encrypt-12
Abstract Abstract
To protect user data and privacy, Internet transport protocols have To protect user data and privacy, Internet transport protocols have
supported payload encryption and authentication for some time. Such supported payload encryption and authentication for some time. Such
encryption and authentication is now also starting to be applied to encryption and authentication is now also starting to be applied to
the transport protocol headers. This helps avoid transport protocol the transport protocol headers. This helps avoid transport protocol
ossification by middleboxes, while also protecting metadata about the ossification by middleboxes, while also protecting metadata about the
communication. Current operational practice in some networks inspect communication. Current operational practice in some networks inspect
transport header information within the network, but this is no transport header information within the network, but this is no
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 3, 2020. This Internet-Draft will expire on August 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4. Encryption and Authentication of Transport Headers . . . . . 24 4. Encryption and Authentication of Transport Headers . . . . . 24
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Approaches to Transport Header Protection . . . . . . . . 25 4.2. Approaches to Transport Header Protection . . . . . . . . 25
5. Addition of Transport Information to Network-Layer Headers . 27 5. Addition of Transport Information to Network-Layer Headers . 27
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 27 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 27
6. Implications of Protecting the Transport Headers . . . . . . 28 6. Implications of Protecting the Transport Headers . . . . . . 28
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 29 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 29
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 31 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 31
6.3. Accountability and Internet Transport Protocols . . . . . 31 6.3. Accountability and Internet Transport Protocols . . . . . 31
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 32 6.4. Impact on Network Operations . . . . . . . . . . . . . . 32
6.5. Impact on Research, Development and Deployment . . . . . 32 6.5. Impact on Research, Development and Deployment . . . . . 32
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
11. Informative References . . . . . . . . . . . . . . . . . . . 39 11. Informative References . . . . . . . . . . . . . . . . . . . 39
Appendix A. Revision information . . . . . . . . . . . . . . . . 46 Appendix A. Revision information . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Transport protocols have supported end-to-end encryption of payload Transport protocols have supported end-to-end encryption of payload
data for many years. Examples include Transport Layer Security (TLS) data for many years. Examples include Transport Layer Security (TLS)
over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure
RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic
encryption of the TCP transport payload. Some of these also provide encryption of the TCP transport payload. Some of these also provide
integrity protection of all or part of the transport header. integrity protection of all or part of the transport header.
This end-to-end transport payload encryption brings many benefits in This end-to-end transport payload encryption brings many benefits in
terms of providing confidentiality and protecting user privacy. The terms of providing confidentiality and protecting user privacy. The
benefits have been widely discussed, for example in [RFC7258] and benefits have been widely discussed, for example in [RFC7624]. This
[RFC7624]. This document strongly supports and encourages increased document supports and encourages increased use of end-to-end payload
use of end-to-end payload encryption in transport protocols. The encryption in transport protocols. The implications of protecting
implications of protecting the transport payload data are therefore the transport payload data are therefore not further discussed in
not further discussed in this document. this document.
A further level of protection can be achieved by encrypting the A further level of protection can be achieved by encrypting the
entire network layer payload, including both the transport headers entire network layer payload, including both the transport headers
and the payload. This does not expose any transport information to and the transport payload data. This does not expose any transport
devices in the network, and therefore also prevents modification information to devices in the network, and therefore also prevents
along a network path. An example of encryption at the network layer modification along a network path. An example of encryption at the
is the IPsec Encapsulating Security Payload (ESP) [RFC4303] in tunnel network layer is the IPsec Encapsulating Security Payload (ESP)
mode. Virtual Private Networks (VPNs) typically also operate in this [RFC4303] in tunnel mode. Virtual Private Networks (VPNs) typically
way. This form of encryption is not further discussed in this also operate in this way. This form of encryption is not further
document. discussed in this document.
There is also a middle ground, comprising transport protocols that There is also a middle ground, comprising transport protocols that
encrypt some, or all, of the transport layer header information, in encrypt some, or all, of the transport layer header information, in
addition to encrypting the payload. An example of such a protocol, addition to encrypting the transport payload data. An example of
that is now seeing widespread interest and deployment, is the QUIC such a protocol, that is now seeing widespread interest and
transport protocol [I-D.ietf-quic-transport]. The encryption and deployment, is the QUIC transport protocol [I-D.ietf-quic-transport].
authentication of transport header information can prevent unwanted The encryption and authentication of transport header information can
modification of transport header information by middleboxes, reducing prevent unwanted modification of transport header information by
the risk of protocol ossification. It also reduces the amount of middleboxes, reducing the risk of protocol ossification. It also
metadata about the progress of the transport connection that is reduces the amount of metadata about the progress of the transport
visible to the network [RFC8558]. connection that is visible to the network [RFC8558].
There are also, however, some costs, in that the widespread use of There is also, however, some impact, in that the widespread use of
transport encryption requires changes to network operations and other transport encryption requires changes to network operations and other
practises. Operators could choose to do nothing special with practises. Operators could choose to do nothing special with
encrypted traffic. In some cases, encryption could drive changes to encrypted traffic. In some cases, encryption could drive changes to
the design of network measurement for research, operational, and the design of network measurement for research, operational, and
standardisation purposes. standardisation purposes.
The direction in which the use of transport header confidentiality The direction in which the use of transport header confidentiality
evolves could have significant implications on the way the Internet evolves could have significant implications on the way the Internet
architecture develops, and therefore needs to be considered as a part architecture develops, and therefore needs to be considered as a part
of protocol design. This include considering whether the endpoints of protocol design. This include considering whether the endpoints
permit network devices to observe a specific field of the transport permit network devices to observe a specific field of the transport
header; whether the devices could modify that field; and whether any header; whether the devices could modify that field; and whether any
modification can be detected by the receiving endpoint. modification can be detected by the receiving endpoint.
As discussed in [RFC7258], Pervasive Monitoring (PM) is a technical As discussed in [RFC7258], the IETF has concluded that Pervasive
attack that needs to be mitigated in the design of IETF protocols. Monitoring (PM) is a technical attack that needs to be mitigated in
This document supports that conclusion and the use of transport the design of IETF protocols, but RFC7528 also notes that "Making
header encryption to protect against pervasive monitoring. RFC 7258 networks unmanageable to mitigate PM is not an acceptable outcome,
also notes, though, that "Making networks unmanageable to mitigate PM but ignoring PM would go against the consensus documented here. An
is not an acceptable outcome, but ignoring PM would go against the appropriate balance will emerge over time as real instances of this
consensus documented here. An appropriate balance will emerge over tension are considered". In support of achieving that balance, this
time as real instances of this tension are considered". document discusses design and deployment considerations for use of
transport header encryption to protect against pervasive monitoring.
The transport protocols developed for the Internet are used across a The transport protocols developed for the Internet are used across a
wide range of paths across network segments with many different wide range of paths across network segments with many different
regulatory, commercial, and engineering considerations. This regulatory, commercial, and engineering considerations. This
document considers some of the costs and changes to network document considers some of the costs and changes to network
management and research that are implied by widespread use of management and research that are implied by widespread use of
transport protocols that encrypt their transport header information. transport protocols that encrypt their transport header information.
It reviews the implications of developing transport protocols that It reviews the implications of developing transport protocols that
use end-to-end encryption to provide confidentiality of their use end-to-end encryption to provide confidentiality of their
transport layer headers, and considers the effect of such changes on transport layer headers, and considers the effect of such changes on
skipping to change at page 6, line 8 skipping to change at page 6, line 8
limit the information available to network observers. The widespread limit the information available to network observers. The widespread
use of transport header encryption would therefore limit such use of transport header encryption would therefore limit such
observations in future. It is important to understand how transport observations in future. It is important to understand how transport
header information is used in the network, to allow future protocol header information is used in the network, to allow future protocol
designs to make an informed choice on what, if any, headers to expose designs to make an informed choice on what, if any, headers to expose
to the network. to the network.
2.1. Use of Transport Header Information in the Network 2.1. Use of Transport Header Information in the Network
In-network measurement of transport flow characteristics can be used In-network measurement of transport flow characteristics can be used
to enhance performance, and control cost and service reliability. To to enhance performance, control cost and improve service reliability.
support network operations and enhance performance, some operators To support network operations and enhance performance, some operators
have deployed functionality that utilises on-path observations of the have deployed functionality that utilises on-path observations of the
transport headers of packets passing through their network. transport headers of packets passing through their network.
When network devices rely on the presence of a header field or the When network devices rely on the presence of a header field or the
semantics of specific header information, this can lead to semantics of specific header information, this can lead to
ossification where an endpoint has to supply a specific header to ossification where an endpoint has to supply a specific header to
receive the network service that it desires. receive the network service that it desires.
In some cases, network-layer use of transport header information can In some cases, network-layer use of transport header information can
be benign or advantageous to the protocol (e.g., recognising the be benign or advantageous to the protocol (e.g., recognising the
skipping to change at page 7, line 45 skipping to change at page 7, line 45
in time resulting in ossification of the service. in time resulting in ossification of the service.
2.2. Authentication of Transport Header Information 2.2. Authentication of Transport Header Information
The designers of a transport protocol decide whether to encrypt all, The designers of a transport protocol decide whether to encrypt all,
or a part of, the transport header information. Section 4 of RFC8558 or a part of, the transport header information. Section 4 of RFC8558
states: "Anything exposed to the path should be done with the intent states: "Anything exposed to the path should be done with the intent
that it be used by the network elements on the path" [RFC8558]. New that it be used by the network elements on the path" [RFC8558]. New
protocol designs can decide not to encrypt certain transport header protocol designs can decide not to encrypt certain transport header
fields, making those fields observable in the network. Where fields fields, making those fields observable in the network. Where fields
are intended to immutable (i.e., observable but not modifiable by the are intended to immutable (i.e., can be observed, but not modified by
network), the endpoints are encouraged to use authentication to a network device), the endpoints are encouraged to use authentication
provide a cryptographic integrity check that includes these immutable to provide a cryptographic integrity check that includes these
fields to detect any manipulation by network devices. immutable fields to detect any manipulation by network devices.
Making part of a transport header observable can lead to ossification Making part of a transport header observable can lead to ossification
of that part of a header, as middleboxes come to rely on observations of that part of a header, as middleboxes come to rely on observations
of the exposed fields. A protocol design that provides an observable of the exposed fields. A protocol design that provides an observable
field might want to avoid inspection restricting the choice of usable field might want to avoid inspection restricting the choice of usable
values in the field by intentionally varying the format and/or value values in the field by intentionally varying the format and/or value
of the field to reduce the chance of ossification (see Section 4). of the field to reduce the chance of ossification (see Section 4).
2.3. Perspectives on Observable Transport Header Fields 2.3. Perspectives on Observable Transport Header Fields
Transport headers fields have been observed within the network for a Transport headers fields have been observed within the network for a
variety of purposes. Some of these are related to network management variety of purposes. Some of these are related to network management
and operations. The lists below, and in the following section, seek and operations. The lists below, and in the following section, seek
to identify some of these uses and the implications of the increased to identify some of these uses and the implications of the increased
use of transport header encryption. This analysis does not judge use of transport header encryption. This analysis does not judge
whether specific practises are necessary, or endorse the use of any whether specific practises are necessary, or endorse the use of any
specific approach. specific approach.
Network Operations: Observable transport headers enable explicit Network Operations: A transport protocol with observable header
measurement and analysis of protocol performance, information can enable explicit measurement and
network anomalies, and failure pathologies at any analysis of protocol performance, network
point along the Internet path. In many cases, it anomalies, and failure pathologies at any point
is important to relate observations to specific along the Internet path. In many cases, it is
important to relate observations to specific
equipment/configurations, to a specific network equipment/configurations, to a specific network
segment, or sometimes to a specific protocol or segment, or sometimes to a specific protocol or
application. application.
When transport header information is not When transport header information is not
observable, it cannot be used by network observable, it cannot be used by network
operators. Some operators might work without operators. Some operators might work without
that information, or some might turn to more that information, or some might turn to more
ambitious ways to collect, estimate, or infer ambitious ways to collect, estimate, or infer
this data. (Operational practises aimed at this data. (Operational practises aimed at
guessing transport parameters are out of scope guessing transport parameters are out of scope
for this document, and are only mentioned here to for this document, and are only mentioned here to
recognize that encryption does not stop operators recognize that encryption does not stop operators
from attempting to apply practises that have been from attempting to apply practises that have been
used with unencrypted transport headers.) used with unencrypted transport headers.)
See also Section 3, Section 5, Section 6.4 and s See also Section 3, Section 5, Section 6.4 and s
(Section 6.5). (Section 6.5).
Analysis of Aggregate Traffic: Observable transport headers have Analysis of Aggregate Traffic: Observable transport headers have
been used to determine which transport protocols been utilised to determine which transport
and features are being used across a network protocols and features are being used across a
segment, and to measure trends in the pattern of network segment, and to measure trends in the
usage. For some use cases, end-to-end pattern of usage. For some use cases, end-to-end
measurements/traces are sufficient and can assist measurements/traces are sufficient and can assist
in developing and debugging new transports and in developing and debugging new transports and
analysing their deployment. In other uses, it is analysing their deployment. In other uses, it is
important to relate observations to specific important to relate observations to specific
equipment/configurations or particular network equipment/configurations or particular network
segments. segments.
This information can help anticipate the demand This information can help anticipate the demand
for network upgrades and roll-out, or affect on- for network upgrades and roll-out, or affect on-
going traffic engineering activities performed by going traffic engineering activities performed by
skipping to change at page 9, line 29 skipping to change at page 9, line 29
relating to Quality of Service (QoS), to perform relating to Quality of Service (QoS), to perform
fast re-routing of critical traffic, to mitigate fast re-routing of critical traffic, to mitigate
the characteristics of specific radio links, and the characteristics of specific radio links, and
so on. so on.
See also Section 3.1 to Section 3.2 and See also Section 3.1 to Section 3.2 and
Section 5. Section 5.
Troubleshooting: Observable transport headers have been utilised Troubleshooting: Observable transport headers have been utilised
by operators as a part of network troubleshooting by operators as a part of network troubleshooting
and diagnostics. Metrics can help localise the and diagnostics. Metrics derived from this
observed header information can help localise the
network segment introducing the loss or latency. network segment introducing the loss or latency.
Effective troubleshooting often requires Effective troubleshooting often requires
understanding of transport behaviour. Flows understanding of transport behaviour. Flows
experiencing packet loss or jitter are hard to experiencing packet loss or jitter are hard to
distinguish from unaffected flows when only distinguish from unaffected flows when only
observing network layer headers. observing network layer headers.
Observable transport feedback information (e.g., Observable transport feedback information (e.g.,
RTP Control Protocol (RTCP) reception reports RTP Control Protocol (RTCP) reception reports
[RFC3550]) can explicitly make loss metrics [RFC3550]) can explicitly make loss metrics
skipping to change at page 10, line 23 skipping to change at page 10, line 25
Where flows cannot be disambiguated based on Where flows cannot be disambiguated based on
transport information, this could result in less- transport information, this could result in less-
efficient identification of unwanted traffic, the efficient identification of unwanted traffic, the
introduction of rate limits for uncharacterised introduction of rate limits for uncharacterised
traffic, or the use of heuristics to identify traffic, or the use of heuristics to identify
anomalous flows. anomalous flows.
See also Section 6.2 and Section 6.3. See also Section 6.2 and Section 6.3.
Verifiable Data: Observable transport headers can provide open and Verifiable Data: Observable transport headers can be used to
verifiable measurements to support operations, provide open and verifiable measurements to
research, and protocol development. The ability support operations, research, and protocol
of multiple stake holders to review transport development. The ability of multiple stake
header traces helps develop insight into holders to review transport header traces helps
performance and traffic contribution of specific develop insight into performance and traffic
variants of a protocol. Independently observed contribution of specific variants of a protocol.
data is important to help ensure the health of Independently observed data is important to help
the research and development communities. ensure the health of the research and development
communities.
When transport header information can not be When transport header information can not be
observed, this can reduce the range of actors observed, this can reduce the range of actors
that can observe data. This limits the that can observe data. This limits the
information sources available to the Internet information sources available to the Internet
community to understand the operation of new community to understand the operation of new
transport protocols, reducing information to transport protocols, reducing information to
inform design decisions and standardisation of inform design decisions and standardisation of
the new protocols and related operational the new protocols and related operational
practises practises
skipping to change at page 12, line 19 skipping to change at page 12, line 21
In-network observation of transport protocol headers requires In-network observation of transport protocol headers requires
knowledge of the format of the transport header: knowledge of the format of the transport header:
o Flows have to be identified at the level where observation is o Flows have to be identified at the level where observation is
performed. This implies visibility of the protocol and version of performed. This implies visibility of the protocol and version of
the header, e.g., by defining the wire image [RFC8546]. As the header, e.g., by defining the wire image [RFC8546]. As
protocols evolve over time, new transport headers could be protocols evolve over time, new transport headers could be
introduced. Detecting this could require interpretation of introduced. Detecting this could require interpretation of
protocol version information or connection setup information; protocol version information or connection setup information;
o Observing transport information depends on knowing the location o Observing transport header information depends on the observer
and syntax of the observed transport headers. IETF transport knowing the location and the syntax of the observable transport
protocols can specify this information. headers. IETF transport protocols can specify this information.
The following subsections describe various ways that observable The following subsections describe various ways that observable
transport information has been utilised. transport information has been utilised.
3.1.1. Flow Identification Using Transport Layer Headers 3.1.1. Flow Identification Using Transport Layer Headers
Flow/Session identification [RFC8558] is a common function. For Flow/Session identification [RFC8558] is a common function. For
example, performed by measurement activities, QoS classification, example, performed by measurement activities, QoS classification,
firewalls, Denial of Service, DOS, prevention. firewalls, Denial of Service, DOS, prevention.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
descriptions to classify a flow as audio traffic, might instead use descriptions to classify a flow as audio traffic, might instead use
(possibly less-reliable) heuristics to infer that short UDP packets (possibly less-reliable) heuristics to infer that short UDP packets
with regular spacing carry audio traffic. Operational practises with regular spacing carry audio traffic. Operational practises
aimed at inferring transport parameters are out of scope for this aimed at inferring transport parameters are out of scope for this
document, and are only mentioned here to recognize that encryption document, and are only mentioned here to recognize that encryption
does not prevent operators from attempting to apply practises that does not prevent operators from attempting to apply practises that
were used with unencrypted transport headers. The IAB have provided were used with unencrypted transport headers. The IAB have provided
a summary of expected implications of increased encryption on network a summary of expected implications of increased encryption on network
functions that use the observable headers [RFC8546] and describe the functions that use the observable headers [RFC8546] and describe the
expected benefits of designs that explicitly declare protocol expected benefits of designs that explicitly declare protocol
invarient header information that can be used for this purpose. invariant header information that can be used for this purpose.
3.1.2. Metrics derived from Transport Layer Headers 3.1.2. Metrics derived from Transport Layer Headers
Observable transport headers enable explicit measurement and analysis Observable transport headers enable explicit measurement and analysis
of protocol performance, network anomalies, and failure pathologies of protocol performance, network anomalies, and failure pathologies
at any point along the Internet path. Some operators use passive at any point along the Internet path. Some operators use passive
monitoring to manage their portion of the Internet by characterizing monitoring to manage their portion of the Internet by characterizing
the performance of link/network segments. Inferences from transport the performance of link/network segments. Inferences from transport
headers are used to derive performance metrics. A variety of open headers are used to derive performance metrics. A variety of open
source and commercial tools have been deployed that utilise transport source and commercial tools have been deployed that utilise transport
header information in this way to derive the following metrics: header information in this way to derive the following metrics:
Traffic Rate and Volume: Volume measures per-application can be used Traffic Rate and Volume: Volume measures per-application can be used
to characterise the traffic that uses a network segment or the to characterise the traffic that uses a network segment or the
pattern of network usage. Observing the protocol sequence number pattern of network usage. Observing the protocol sequence number
and packet size offers one way to meausre this (e.g., measurements and packet size offers one way to measure this (e.g., measurements
observing counters in periodic reports such as RTCP; or observing counters in periodic reports such as RTCP; or
measurements observing protocol sequence numbers in statistical measurements observing protocol sequence numbers in statistical
samples of packet flows, or specific control packets, such as samples of packet flows, or specific control packets, such as
those observed at the start and end of a flow). Measurements can those observed at the start and end of a flow). Measurements can
be per endpoint or for an endpoint aggregate (e.g., to assess be per endpoint or for an endpoint aggregate (e.g., to assess
subscriber usage). Measurements can also be used to trigger subscriber usage). Measurements can also be used to trigger
traffic shaping, and to associate QoS support within the network traffic shaping, and to associate QoS support within the network
and lower layers. Volume measures can also be valuable for and lower layers. Volume measures can also be valuable for
capacity planning and providing detail of trends in usage. The capacity planning and providing detail of trends in usage. The
traffic rate and volume can be determined providing that the traffic rate and volume can be determined providing that the
skipping to change at page 32, line 5 skipping to change at page 32, line 5
(firewalls, etc.) to seek other methods to classify, and potentially (firewalls, etc.) to seek other methods to classify, and potentially
other mechanisms to condition, network traffic. other mechanisms to condition, network traffic.
A lack of data that reduces the level of precision with which flows A lack of data that reduces the level of precision with which flows
can be classified also reduces the design space for conditioning can be classified also reduces the design space for conditioning
mechanisms (e.g., rate limiting, circuit breaker techniques mechanisms (e.g., rate limiting, circuit breaker techniques
[RFC8084], or blocking of uncharacterised traffic), and this has to [RFC8084], or blocking of uncharacterised traffic), and this has to
be considered when evaluating the impact of designs for transport be considered when evaluating the impact of designs for transport
encryption [RFC5218]. encryption [RFC5218].
6.4. Impact on Operational Cost 6.4. Impact on Network Operations
Some network operators currently use observed transport header Some network operators currently use observed transport header
information as a part of their operational practice, and have information as a part of their operational practice, and have
developed tools and techniques that use information observed in developed tools and techniques that use information observed in
currently deployed transports and their applications. A variety of currently deployed transports and their applications. A variety of
open source and proprietary tools have been deployed that use this open source and proprietary tools have been deployed that use this
information for a variety of short and long term measurements. information for a variety of short and long term measurements.
Encryption of the transport information prevents tooling from Encryption of the transport information prevents tooling from
observing the header information, limiting its utility. observing the header information, limiting its utility.
skipping to change at page 32, line 28 skipping to change at page 32, line 28
deployed. Introducing a new protocol or application might then deployed. Introducing a new protocol or application might then
require these tool chains and practises to be updated, and could in require these tool chains and practises to be updated, and could in
turn impact operational mechanisms, and policies. Each change can turn impact operational mechanisms, and policies. Each change can
introduce associated costs, including the cost of collecting data, introduce associated costs, including the cost of collecting data,
and the tooling to handle multiple formats (possibly as these co- and the tooling to handle multiple formats (possibly as these co-
exist in the network, when measurements span time periods during exist in the network, when measurements span time periods during
which changes are deployed, or to compare with historical data). which changes are deployed, or to compare with historical data).
These costs are incurred by an operator to manage the service and These costs are incurred by an operator to manage the service and
debug network issues. debug network issues.
At the time of writing, the additional operational cost of using At the time of writing, the overall operational impact of using
encrypted transports is not yet well understood. Design trade-offs encrypted transports is not yet well understood. Design trade-offs
could mitigate these costs by explicitly choosing to expose selected could mitigate these costs by explicitly choosing to expose selected
information (e.g., header invariants and the spin-bit in QUIC information (e.g., header invariants and the spin-bit in QUIC
[I-D.ietf-quic-transport]), the specification of common log formats, [I-D.ietf-quic-transport]), the specification of common log formats,
and development of alternative approaches. and development of alternative approaches.
6.5. Impact on Research, Development and Deployment 6.5. Impact on Research, Development and Deployment
Transport protocol evolution, and the ability to measure and Transport protocol evolution, and the ability to measure and
understand the impact of protocol changes, have to proceed hand-in- understand the impact of protocol changes, have to proceed hand-in-
hand. Observable transport headers can provide open and verifiable hand. A transport protocol that provides observable headers can be
measurement data. Observation of pathologies has a critical role in used to provide open and verifiable measurement data. Observation of
the design of transport protocol mechanisms and development of new pathologies has a critical role in the design of transport protocol
mechanisms and protocols. This helps understanding the interactions mechanisms and development of new mechanisms and protocols. This
between cooperating protocols and network mechanism, the implications helps understanding the interactions between cooperating protocols
of sharing capacity with other traffic and the impact of different and network mechanism, the implications of sharing capacity with
patterns of usage. The ability of other stake holders to review other traffic and the impact of different patterns of usage. The
transport header traces helps develop insight into performance and ability of other stake holders to review transport header traces
traffic contribution of specific variants of a protocol. helps develop insight into performance and traffic contribution of
specific variants of a protocol.
Development of new transport protocol mechanisms has to consider the Development of new transport protocol mechanisms has to consider the
scale of deployment and the range of environments in which the scale of deployment and the range of environments in which the
transport is used. Experience has shown that it is often difficult transport is used. Experience has shown that it is often difficult
to correctly implement new mechanisms [RFC8085], and that mechanisms to correctly implement new mechanisms [RFC8085], and that mechanisms
often evolve as a protocol matures, or in response to changes in often evolve as a protocol matures, or in response to changes in
network conditions, changes in network traffic, or changes to network conditions, changes in network traffic, or changes to
application usage. Analysis is especially valuable when based on the application usage. Analysis is especially valuable when based on the
behaviour experienced across a range of topologies, vendor equipment, behaviour experienced across a range of topologies, vendor equipment,
and traffic patterns. and traffic patterns.
skipping to change at page 36, line 14 skipping to change at page 36, line 20
considering other mechanisms, across a broad range of network considering other mechanisms, across a broad range of network
topologies and with attention to the impact on traffic sharing the topologies and with attention to the impact on traffic sharing the
capacity. If increased use of transport header encryption results capacity. If increased use of transport header encryption results
in reduced availability of open data, it could eliminate the in reduced availability of open data, it could eliminate the
independent self-checks to the standardisation process that have independent self-checks to the standardisation process that have
previously been in place from research and academic contributors previously been in place from research and academic contributors
(e.g., the role of the IRTF Internet Congestion Control Research (e.g., the role of the IRTF Internet Congestion Control Research
Group (ICCRG) and research publications in reviewing new transport Group (ICCRG) and research publications in reviewing new transport
mechanisms and assessing the impact of their deployment). mechanisms and assessing the impact of their deployment).
Observable transport information information might be useful to Observable transport information might be useful to various
various stakeholders. Other stakeholders have incentives to limit stakeholders. Other stakeholders have incentives to limit what can
what can be observed. This document does not make recommendations be observed. This document does not make recommendations about what
about what information ought to be exposed, to whom it ought to be information ought to be exposed, to whom it ought to be observable,
observable, or how this will be achieved. There are also design or how this will be achieved. There are also design choices about
choices about where observable fields are placed. For example, one where observable fields are placed. For example, one location could
location could be a part of the transport header outside of the be a part of the transport header outside of the encryption envelope,
encryption envelope, another alternative is to carry the information another alternative is to carry the information in a network-layer
in a network-layer extension header. New transport protocol designs extension header. New transport protocol designs ought to explicitly
ought to explicitly identify any fields that are intended to be identify any fields that are intended to be observed, consider if
observed, consider if there are alternative ways of providing the there are alternative ways of providing the information, and reflect
information, and reflect on the implications of observable fields on the implications of observable fields being used by network
being used by in-network devices, and how this might impact user devices, and how this might impact user privacy and protocol
privacy and protocol evolution when these fields become ossified. evolution when these fields become ossified.
As [RFC7258] notes, "Making networks unmanageable to mitigate As [RFC7258] notes, "Making networks unmanageable to mitigate
(pervasive monitoring) is not an acceptable outcome, but ignoring (pervasive monitoring) is not an acceptable outcome, but ignoring
(pervasive monitoring) would go against the consensus documented (pervasive monitoring) would go against the consensus documented
here." Providing explicit information can help avoid traffic being here." Providing explicit information can help avoid traffic being
inappropriately classified, impacting application performance. An inappropriately classified, impacting application performance. An
appropriate balance will emerge over time as real instances of this appropriate balance will emerge over time as real instances of this
tension are analysed [RFC7258]. This balance between information tension are analysed [RFC7258]. This balance between information
exposed and information hidden ought to be carefully considered when exposed and information hidden ought to be carefully considered when
specifying new transport protocols. specifying new transport protocols.
skipping to change at page 39, line 10 skipping to change at page 39, line 16
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Mohamed Boucadair, Spencer Dawkins, The authors would like to thank Mohamed Boucadair, Spencer Dawkins,
Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen
Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris
Wood, Thomas Fossati, Martin Thomson, and other members of the TSVWG Wood, Thomas Fossati, Martin Thomson, David Black, and other members
for their comments and feedback. of the TSVWG for their comments and feedback.
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 688421, research and innovation programme under grant agreement No 688421,
and the EU Stand ICT Call 4. The opinions expressed and arguments and the EU Stand ICT Call 4. The opinions expressed and arguments
employed reflect only the authors' view. The European Commission is employed reflect only the authors' view. The European Commission is
not responsible for any use that might be made of that information. not responsible for any use that might be made of that information.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
skipping to change at page 48, line 10 skipping to change at page 48, line 10
-10 Updated following additional feedback from 1st WGLC. Comments -10 Updated following additional feedback from 1st WGLC. Comments
from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter
Gutmann; Ekr; and many others via the TSVWG list. Some people Gutmann; Ekr; and many others via the TSVWG list. Some people
thought that "needed" and "need" could represent requirements in the thought that "needed" and "need" could represent requirements in the
document, etc. this has been clarified. document, etc. this has been clarified.
-11 Updated following additional feedback from Martin Thomson, and -11 Updated following additional feedback from Martin Thomson, and
corrections from other reviewers. corrections from other reviewers.
-11 Updated following additional feedback from reviewers.
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. 26 change blocks. 
93 lines changed or deleted 100 lines changed or added

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