draft-ietf-tsvwg-transport-encrypt-10.txt   draft-ietf-tsvwg-transport-encrypt-11.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: July 12, 2020 University of Glasgow Expires: August 3, 2020 University of Glasgow
January 9, 2020 January 31, 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-10 draft-ietf-tsvwg-transport-encrypt-11
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
longer possible when those transport headers are encrypted. This longer possible when those transport headers are encrypted. This
document discusses the possible impact when network traffic uses a document discusses the possible impact when network traffic uses a
protocol with an encrypted transport header. It suggests issues to protocol with an encrypted transport header. It suggests issues to
consider when designing new transport protocols, to account for consider when designing new transport protocols, to account for
network operations, prevent network ossification, and enable network operations, prevent network ossification, enable transport
transport evolution, while still respecting user privacy. evolution, and respect user privacy.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2020. This Internet-Draft will expire on August 3, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4
2.1. Use of Transport Header Information in the Network . . . 5 2.1. Use of Transport Header Information in the Network . . . 6
2.2. Authentication of Transport Header Information . . . . . 7 2.2. Authentication of Transport Header Information . . . . . 7
2.3. Observable Transport Header Fields . . . . . . . . . . . 7 2.3. Perspectives on Observable Transport Header Fields . . . 8
3. Current uses of Transport Headers within the Network . . . . 10 3. Current uses of Transport Headers within the Network . . . . 11
3.1. Observing Transport Information in the Network . . . . . 11 3.1. Observing Transport Information in the Network . . . . . 12
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 18 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 19
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 21 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 22
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 23 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 24
4. Encryption and Authentication of Transport Headers . . . . . 23 4. Encryption and Authentication of Transport Headers . . . . . 24
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Approaches to Transport Header Protection . . . . . . . . 24 4.2. Approaches to Transport Header Protection . . . . . . . . 25
5. Addition of Transport Information to Network-Layer Headers . 26 5. Addition of Transport Information to Network-Layer Headers . 27
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 26 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 26 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 27
6. Implications of Protecting the Transport Headers . . . . . . 27 6. Implications of Protecting the Transport Headers . . . . . . 28
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 28 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 29
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 30 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 31
6.3. Accountability and Internet Transport Protocols . . . . . 30 6.3. Accountability and Internet Transport Protocols . . . . . 31
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 31 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 32
6.5. Impact on Research, Development and Deployment . . . . . 31 6.5. Impact on Research, Development and Deployment . . . . . 32
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
11. Informative References . . . . . . . . . . . . . . . . . . . 38 11. Informative References . . . . . . . . . . . . . . . . . . . 39
Appendix A. Revision information . . . . . . . . . . . . . . . . 45 Appendix A. Revision information . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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.
skipping to change at page 3, line 38 skipping to change at page 3, line 38
mode. Virtual Private Networks (VPNs) typically also operate in this mode. Virtual Private Networks (VPNs) typically also operate in this
way. This form of encryption is not further discussed in this way. This form of encryption is not further discussed in this
document. 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 payload. An example of such a protocol,
that is now seeing widespread interest and deployment, is the QUIC that is now seeing widespread interest and deployment, is the QUIC
transport protocol [I-D.ietf-quic-transport]. The encryption and transport protocol [I-D.ietf-quic-transport]. The encryption and
authentication of transport header information can prevent unwanted authentication of transport header information can prevent unwanted
modification of transport headers by middleboxes, reducing the risk modification of transport header information by middleboxes, reducing
of protocol ossification. It also reduces the amount of metadata the risk of protocol ossification. It also reduces the amount of
about the progress of the transport connection that is visible to the metadata about the progress of the transport connection that is
network. visible to the network [RFC8558].
There are also, however, some costs, in that the widespread use of
transport encryption requires changes to network operations and other
practises. Operators could choose to do nothing special with
encrypted traffic. In some cases, encryption could drive changes to
the design of network measurement for research, operational, and
standardisation purposes.
The direction in which the use of transport header confidentiality
evolves could have significant implications on the way the Internet
architecture develops, and therefore needs to be considered as a part
of protocol design. This include considering whether the endpoints
permit network devices to observe a specific field of the transport
header; whether the devices could modify that field; and whether any
modification can be detected by the receiving endpoint.
As discussed in [RFC7258], Pervasive Monitoring (PM) is a technical As discussed in [RFC7258], Pervasive Monitoring (PM) is a technical
attack that needs to be mitigated in the design of IETF protocols. attack that needs to be mitigated in the design of IETF protocols.
This document supports that conclusion and the use of transport This document supports that conclusion and the use of transport
header encryption to protect against pervasive monitoring. RFC 7258 header encryption to protect against pervasive monitoring. RFC 7258
also notes, though, that "Making networks unmanageable to mitigate PM also notes, though, that "Making networks unmanageable to mitigate PM
is not an acceptable outcome, but ignoring PM would go against the is not an acceptable outcome, but ignoring PM would go against the
consensus documented here. An appropriate balance will emerge over consensus documented here. An appropriate balance will emerge over
time as real instances of this tension are considered". time as real instances of this tension are considered".
skipping to change at page 5, line 26 skipping to change at page 5, line 41
The increased use of transport header encryption has benefits, but The increased use of transport header encryption has benefits, but
also has implications for the broader ecosystem. The transport also has implications for the broader ecosystem. The transport
community has, to date, relied heavily on measurements and insights community has, to date, relied heavily on measurements and insights
from the network operations community to understand protocol from the network operations community to understand protocol
behaviour, and to inform the selection of appropriate mechanisms to behaviour, and to inform the selection of appropriate mechanisms to
ensure a safe, reliable, and robust Internet. In turn, network ensure a safe, reliable, and robust Internet. In turn, network
operators and access providers have relied upon being able to observe operators and access providers have relied upon being able to observe
traffic patterns and requirements, both in aggregate and at the flow traffic patterns and requirements, both in aggregate and at the flow
level, to help understand and optimise the behaviour of their level, to help understand and optimise the behaviour of their
networks. Widespread use of transport header encryption could limit networks. Transport header encryption can be used to intentionally
such observations in future. It is important to understand how limit the information available to network observers. The widespread
transport header information is used in the network, to allow future use of transport header encryption would therefore limit such
protocol designs to make an informed choice on what, if any, headers observations in future. It is important to understand how transport
to expose to the network. header information is used in the network, to allow future protocol
designs to make an informed choice on what, if any, headers to expose
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, and control cost and service reliability. To
support network operations and enhance performance, some operators 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
start of a TCP connection, providing header compression for a Secure start of a TCP connection, providing header compression for a Secure
RTP flow, or explicitly using exposed protocol information to provide RTP flow, or explicitly using exposed protocol information to provide
consistent decisions by on-path devices). However, in other cases, consistent decisions by on-path devices). Header compression (e.g.,
this can have unwanted outcomes, e.g., privacy impacts and [RFC5795]) depends understanding of transport header and the way
ossification. fields change packet-by-packet; as also do techniques to improve TCP
performance by transparent modification of acknowledgement traffic
[RFC3449]. Introducing a new transport protocol or changes to
existing transport header information prevent these methods being
used or require the network devices to be updated.
However, in other cases, ossification can have unwanted outcomes.
Ossification can frustrate the evolution of a transport protocol. A Ossification can frustrate the evolution of a transport protocol. A
mechanism implemented in a network device, such as a firewall, that mechanism implemented in a network device, such as a firewall, that
requires a header field to have only a specific known set of values requires a header field to have only a specific known set of values
can prevent the device from forwarding packets using a different can prevent the device from forwarding packets using a different
version of the protocol that introduces a feature that changes to a version of the protocol that introduces a feature that changes to a
new value for the observed field. new value for the observed field.
An example of ossification was observed in the development of An example of this type ossification was observed in the development
Transport Layer Security (TLS) 1.3 [RFC8446], where the design needed of Transport Layer Security (TLS) 1.3 [RFC8446], where the design
to function in the presence of deployed middleboxes that relied on needed to function in the presence of deployed middleboxes that
the presence of certain header fields exposed in TLS 1.2. relied on the presence of certain header fields exposed in TLS 1.2.
The design of MPTCP also had to be revised to account for middleboxes The design of MPTCP also had to be revised to account for middleboxes
(known as "TCP Normalizers") that monitor the evolution of the window (known as "TCP Normalizers") that monitor the evolution of the window
advertised in the TCP header and then reset connections when the advertised in the TCP header and then reset connections when the
window did not grow as expected. Similarly, issues have been window did not grow as expected. Similarly, issues have been
reported using TCP. For example, TCP Fast Open can experience reported using TCP. For example, TCP Fast Open can experience
middleboxes that modify the transport header of packets by removing middleboxes that modify the transport header of packets by removing
"unknown" TCP options, segments with unrecognised TCP options can be "unknown" TCP options, segments with unrecognised TCP options can be
dropped, segments that contain data and set the SYN bit can be dropped, segments that contain data and set the SYN bit can be
dropped, or middleboxes that disrupt connections which send data dropped, or middleboxes that disrupt connections that send data
before completion of the three-way handshake. Other examples of before completion of the three-way handshake.
ossification have included middleboxes that rewrite TCP sequence and
acknowledgement numbers, but are unaware of the (newer) TCP selective
acknowledgement (SACK) Option and therefore fail to correctly rewrite
the selective acknowledgement header information to match the changes
that were made to the fixed TCP header, preventing SACK from
operating correctly.
In all these cases, middleboxes with a hard-coded understanding of Other examples of ossification have included middleboxes that modify
transport behaviour, interacted poorly with transport protocols after transport headers by rewriting TCP sequence and acknowledgement
the transport behaviour was changed. numbers, but are unaware of the (newer) TCP selective acknowledgement
(SACK) Option and therefore fail to correctly rewrite the selective
acknowledgement header information to match the changes that were
made to the fixed TCP header, preventing SACK from operating
correctly.
In all these cases, middleboxes with a hard-coded, but incomplete,
understanding of transport behaviour, interacted poorly with
transport protocols after the transport behaviour was changed.
In contrast, transport header encryption prevents an on-path device In contrast, transport header encryption prevents an on-path device
from observing the transport headers, and therefore stops mechanisms from observing the transport headers, and therefore stops mechanisms
being built that directly rely on or infer semantics of the transport being built that directly rely on or infer semantics of the transport
header information. Encryption is normally combined with header information. Encryption is normally combined with
authentication of the protected information. RFC 8546 summarises authentication of the protected information. RFC 8546 summarises
this approach, stating that it is "The wire image, not the protocol's this approach, stating that it is "The wire image, not the protocol's
specification, determines how third parties on the network paths specification, determines how third parties on the network paths
among protocol participants will interact with that protocol" among protocol participants will interact with that protocol"
[RFC8546]. [RFC8546], and it can be expected that header information that is not
encrypted will become ossified.
While encryption can reduce ossification of the transport protocol, While encryption can reduce ossification of the transport protocol,
it does not itself prevent ossification of the network service. it does not itself prevent ossification of the network service.
People seeking to understand network traffic could still come to rely People seeking to understand network traffic could still come to rely
on pattern inferences and other heuristics or machine learning to on pattern inferences and other heuristics or machine learning to
derive measurement data and as the basis for network forwarding derive measurement data and as the basis for network forwarding
decisions. This can also create dependencies on the transport decisions [RFC8546]. This can also create dependencies on the
protocol, or the patterns of traffic it can generate. transport protocol, or the patterns of traffic it can generate, also
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., observable but not modifiable by the
skipping to change at page 7, line 27 skipping to change at page 8, line 8
provide a cryptographic integrity check that includes these immutable provide a cryptographic integrity check that includes these immutable
fields to detect any manipulation by network devices. 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. 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: Observable transport headers enable explicit
measurement and analysis of protocol performance, measurement and analysis of protocol performance,
network anomalies, and failure pathologies at any network anomalies, and failure pathologies at any
point along the Internet path. In many cases, it point along the Internet path. In many cases, it
is important to relate observations to specific 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. Operators might work without that operators. Some operators might work without
information, or they might turn to more ambitious that information, or some might turn to more
ways to collect, estimate, or infer this data. ambitious ways to collect, estimate, or infer
(Operational practises aimed at guessing this data. (Operational practises aimed at
transport parameters are out of scope for this guessing transport parameters are out of scope
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 Sections 3, 5, and 6.4. See also Section 3, Section 5, Section 6.4 and s
(Section 6.5).
Traffic Analysis: Observable transport headers have been used to Analysis of Aggregate Traffic: Observable transport headers have
determine which transport protocols and features been used to determine which transport protocols
are being used across a network segment, and to and features are being used across a network
measure trends in the pattern of usage. For some segment, and to measure trends in the pattern of
use cases, end-to-end measurements/traces are usage. For some use cases, end-to-end
sufficient and can assist in developing and measurements/traces are sufficient and can assist
debugging new transports and analysing their in developing and debugging new transports and
deployment. In other uses, it is important to analysing their deployment. In other uses, it is
relate observations to specific equipment/ important to relate observations to specific
configurations or particular network segments. equipment/configurations or particular network
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
operators such as determining which parts of the operators such as determining which parts of the
path contribute delay, jitter, or loss. path contribute delay, jitter, or loss.
Tools that rely upon observing headers, could Tools that rely upon observing headers, could
fail to produce useful data when those headers fail to produce useful data when those headers
are encrypted. While this impact could, in many are encrypted. While this impact could, in many
cases, be small, there are scenarios where cases, be small, there are scenarios where
operators have actively monitored and supported operators have actively monitored and supported
particular services, e.g., to explore issues particular services, e.g., to explore issues
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 Sections 3.1-3.2, and 5. See also Section 3.1 to Section 3.2 and
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 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
visible to operators. Loss metrics can also be visible to operators. Loss metrics can also be
deduced with more complexity from other header deduced with more complexity from other header
information (e.g., by observing TCP SACK blocks). information (e.g., by observing TCP SACK blocks).
When the transport header information is When the transport header information is
encrypted, explicit observable fields could also encrypted, explicit observable fields could also
be made available at the network or transport be made available at the network or transport
layers to provide these functions. layers to provide these functions. [RFC8558]
motivates the design of signals to focus on their
usage, decoupled from the internal design of the
protocol state machine. This could avoid
ossifying the protocol around the design of a
specific protocol mechanism.
See also Section 3.3 and 5. See also Section 3.3 and Section 5.
Network Protection: Observable transport headers currently provide Network Protection: Observable transport headers currently provide
useful input to classify and detect anomalous useful input to classify and detect anomalous
events, such as changes in application behaviour events, such as changes in application behaviour
or distributed denial of service attacks. or distributed denial of service attacks.
Operators often seek to uniquely disambiguate Operators often seek to uniquely disambiguate
unwanted traffic. unwanted traffic.
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 Sections 6.2 and 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 provide open and
verifiable measurements to support operations, verifiable measurements to support operations,
research, and protocol development. The ability research, and protocol development. The ability
of multiple stake holders to review transport of multiple stake holders to review transport
header traces helps develop insight into header traces helps develop insight into
performance and traffic contribution of specific performance and traffic contribution of specific
variants of a protocol. Independently observed variants of a protocol. Independently observed
data is important to help ensure the health of data is important to help ensure the health of
the research and development communities. the research and development communities.
skipping to change at page 10, line 27 skipping to change at page 11, line 18
be utilised to demonstrate regulatory compliance be utilised to demonstrate regulatory compliance
in some jurisdictions, and as a basis for in some jurisdictions, and as a basis for
informing design decisions. This can bring informing design decisions. This can bring
assurance to those operating networks, often assurance to those operating networks, often
avoiding deployment of complex techniques that avoiding deployment of complex techniques that
routinely monitor and manage Internet traffic routinely monitor and manage Internet traffic
flows (e.g., avoiding the capital and operational flows (e.g., avoiding the capital and operational
costs of deploying flow rate-limiting and network costs of deploying flow rate-limiting and network
circuit-breaker methods [RFC8084]). circuit-breaker methods [RFC8084]).
See also Sections 5 and 6.1-6.3. See also Section 5 and Section 6.1 to
Section 6.4.
Note, again, that this lists uses that have been made of transport Note, again, that this is a list of example uses that have been made
header information, and does not necessarily endorse any particular of transport header information. It is not an endorsement of any
approach. particular practice.
3. Current uses of Transport Headers within the Network 3. Current uses of Transport Headers within the Network
In response to pervasive monitoring [RFC7624] revelations and the In response to pervasive monitoring [RFC7624] revelations and the
IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258],
efforts are underway to increase encryption of Internet traffic. efforts are underway to increase encryption of Internet traffic.
Applying confidentiality to transport header fields affects how Applying confidentiality to transport header fields affects how
protocol information is used [RFC8404], requiring consideration of protocol information is used [RFC8404], requiring consideration of
the trade-offs discussed in Section 2.3. the trade-offs discussed in Section 2.3.
There are architectural challenges and considerations in the way There are architectural challenges and considerations in the way
transport protocols are designed, and the ability to characterise and transport protocols are designed, and the ability to characterise and
compare different transport solutions [Measure]. The decision about compare different transport solutions [Measurement]. The decision
which transport headers fields are made observable offers trade-offs about which transport headers fields are made observable offers
around header confidentiality versus header observability (including trade-offs around header confidentiality versus header observability
non-encrypted but authenticated header fields) for network operations (including non-encrypted but authenticated header fields) for network
and management, and the implications for ossification and user operations and management, and the implications for ossification and
privacy. Different parties will view the relative importance of user privacy. Different parties will view the relative importance of
these differently. For some, the benefits of encrypting all these differently. For some, the benefits of encrypting all
transport headers outweigh the impact of doing so; others might transport headers outweigh the impact of doing so; others might
analyse the security, privacy and ossification impacts and arrive at analyse the security, privacy and ossification impacts and arrive at
a different trade-off. a different trade-off.
To understand the implications, it is necessary to understand how To understand the implications, it is necessary to understand how
transport layer headers are currently observed and/or modified by transport layer headers are currently observed and/or modified by
middleboxes within the network. This section therefore reviews middleboxes within the network. This section therefore reviews
examples of current usage. It does not consider the intentional examples of current usage. It does not consider the intentional
modification of transport headers by middleboxes (such as in Network modification of transport headers by middleboxes (such as in Network
skipping to change at page 12, line 12 skipping to change at page 13, line 6
identify the protocol. However, port information alone is not identify the protocol. However, port information alone is not
sufficient to guarantee identification. Applications can use sufficient to guarantee identification. Applications can use
arbitrary ports, multiple sessions can be multiplexed on a single arbitrary ports, multiple sessions can be multiplexed on a single
port, and ports can be re-used by subsequent sessions. UDP-based port, and ports can be re-used by subsequent sessions. UDP-based
protocols often do not use well-known port numbers. Some flows can protocols often do not use well-known port numbers. Some flows can
be identified by observing signalling protocol data (e.g., [RFC3261], be identified by observing signalling protocol data (e.g., [RFC3261],
[I-D.ietf-rtcweb-overview]) or through the use of magic numbers [I-D.ietf-rtcweb-overview]) or through the use of magic numbers
placed in the first byte(s) of the datagram payload [RFC7983]. placed in the first byte(s) of the datagram payload [RFC7983].
When transport header information can not be observed, this removes When transport header information can not be observed, this removes
information that could be used to classify flows by passive observers information that could have been used to classify flows by passive
along the path. More ambitious ways could be used to collect, observers along the path. More ambitious ways could be used to
estimate, or infer flow information, including heuristics based on collect, estimate, or infer flow information, including heuristics
the analysis of traffic patterns. For example, an operator that based on the analysis of traffic patterns. For example, an operator
cannot access the Session Description Protocol (SDP) session that cannot access the Session Description Protocol (SDP) session
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. were used with unencrypted transport headers. The IAB have provided
a summary of expected implications of increased encryption on network
functions that use the observable headers [RFC8546] and describe the
expected benefits of designs that explicitly declare protocol
invarient 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: Protocol sequence number and packet size Traffic Rate and Volume: Volume measures per-application can be used
could be used to derive 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. Observing the protocol sequence number
pattern of network usage. Measurements can be per endpoint or for and packet size offers one way to meausre this (e.g., measurements
an endpoint aggregate (e.g., to assess subscriber usage). observing counters in periodic reports such as RTCP; or
Measurements can also be used to trigger traffic shaping, and to measurements observing protocol sequence numbers in statistical
associate QoS support within the network and lower layers. Volume samples of packet flows, or specific control packets, such as
measures can also be valuable for capacity planning and providing those observed at the start and end of a flow). Measurements can
detail of trends in usage. The traffic rate and volume can be be per endpoint or for an endpoint aggregate (e.g., to assess
determined providing that the packets belonging to individual subscriber usage). Measurements can also be used to trigger
flows can be identified, but there might be no additional traffic shaping, and to associate QoS support within the network
information about a flow when the transport headers cannot be and lower layers. Volume measures can also be valuable for
observed. capacity planning and providing detail of trends in usage. The
traffic rate and volume can be determined providing that the
packets belonging to individual flows can be identified, but there
might be no additional information about a flow when the transport
headers cannot be observed.
Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g.,
from transport sequence numbers or inferred from observing from transport sequence numbers or inferred from observing
transport protocol interactions) and has been used as a metric for transport protocol interactions) and has been used as a metric for
performance assessment and to characterise transport behaviour. performance assessment and to characterise transport behaviour.
Understanding the location and root cause of loss can help an Understanding the location and root cause of loss can help an
operator determine whether this requires corrective action. operator determine whether this requires corrective action.
Network operators have used the variation in patterns of loss as a Network operators have used the variation in patterns of loss as a
key performance metric, utilising this to detect changes in the key performance metric, utilising this to detect changes in the
offered service. offered service.
skipping to change at page 15, line 38 skipping to change at page 16, line 39
source of this data and the method used to generate the summary source of this data and the method used to generate the summary
information. information.
These metrics can support network operations, inform capacity These metrics can support network operations, inform capacity
planning, and assist in determining the demand for equipment and/or planning, and assist in determining the demand for equipment and/or
configuration changes by network operators. They can also inform configuration changes by network operators. They can also inform
Internet engineering activities by informing the development of new Internet engineering activities by informing the development of new
protocols, methodologies, and procedures. protocols, methodologies, and procedures.
In some cases, measurements could involve active injection of test In some cases, measurements could involve active injection of test
traffic to perform a measurement (see section 3.4 of [RFC7799]). traffic to perform a measurement (see Section 3.4 of [RFC7799]).
However, most operators do not have access to user equipment, However, most operators do not have access to user equipment,
therefore the point of test is normally different from the transport therefore the point of test is normally different from the transport
endpoint. Injection of test traffic can incur an additional cost in endpoint. Injection of test traffic can incur an additional cost in
running such tests (e.g., the implications of capacity tests in a running such tests (e.g., the implications of capacity tests in a
mobile network are obvious). Some active measurements [RFC7799] mobile network are obvious). Some active measurements [RFC7799]
(e.g., response under load or particular workloads) perturb other (e.g., response under load or particular workloads) perturb other
traffic, and could require dedicated access to the network segment. traffic, and could require dedicated access to the network segment.
Passive measurements (see section 3.6 of [RFC7799]) can have Passive measurements (see Section 3.6 of [RFC7799]) can have
advantages in terms of eliminating unproductive test traffic, advantages in terms of eliminating unproductive test traffic,
reducing the influence of test traffic on the overall traffic mix, reducing the influence of test traffic on the overall traffic mix,
and the ability to choose the point of observation (see and the ability to choose the point of observation (see
Section 3.2.1). Measurements can rely on observing packet headers, Section 3.2.1). Measurements can rely on observing packet headers,
which is not possible if those headers are encrypted, but could which is not possible if those headers are encrypted, but could
utilise information about traffic volumes or patterns of interaction utilise information about traffic volumes or patterns of interaction
to deduce metrics. to deduce metrics.
An alternative approach is to use in-network techniques add and An alternative approach is to use in-network techniques to add and
observe packet headers to facilitate measurements while traffic observe packet headers to facilitate measurements while traffic
traverses an operational network. This approach does not require the traverses an operational network. This approach does not require the
cooperation of an endpoint. cooperation of an endpoint.
3.1.3. Transport use of Network Layer Header Fields 3.1.3. Transport use of Network Layer Header Fields
Information from the transport protocol is used by a multi-field Information from the transport protocol is 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 to implement access rules (see constrained networks, and by firewalls to implement access rules (see
also section 2.2.2 of [RFC8404]). Network-layer classification also Section 2.2.2 of [RFC8404]). Network-layer classification
methods that rely on a multi-field classifier (e.g., inferring QoS methods that rely on a multi-field classifier (e.g., inferring QoS
from the 5-tuple or choice of application protocol) are incompatible from the 5-tuple or choice of application protocol) are incompatible
with transport protocols that encrypt the transport information. with transport protocols that encrypt the transport information.
Traffic that cannot be classified typically receives a default Traffic that cannot be classified typically receives a default
treatment. treatment.
Transport information can also be explicitly set in network-layer Transport information can also be explicitly set in network-layer
header fields that are not encrypted, serving as a replacement/ header fields that are not encrypted, serving as a replacement/
addition to the exposed transport information [RFC8558]. This addition to the exposed transport information [RFC8558]. This
information can enable a different forwarding treatment by the information can enable a different forwarding treatment by the
skipping to change at page 17, line 47 skipping to change at page 18, line 48
to be classified the same). The field is mutable, i.e., some to be classified the same). The field is mutable, i.e., some
network devices can be expected to change this field (use of each network devices can be expected to change this field (use of each
DSCP value is defined by an RFC). DSCP value is defined by an RFC).
Since the DSCP value can impact the quality of experience for a Since the DSCP value can impact the quality of experience for a
flow, observations of service performance has to consider this flow, observations of service performance has to consider this
field when a network path supports differentiated service field when a network path supports differentiated service
treatment. treatment.
Using Explicit Congestion Marking: ECN [RFC3168] is a transport Using Explicit Congestion Marking: ECN [RFC3168] is a transport
mechanism that utilises the ECN field in the network-layer header. mechanism that uses the ECN field in the network-layer header.
Use of ECN explicitly informs the network-layer that a transport Use of ECN explicitly informs the network-layer that a transport
is ECN-capable, and requests ECN treatment of the flow. An ECN- is ECN-capable, and requests ECN treatment of the flow. An ECN-
capable transport can offer benefits when used over a path with capable transport can offer benefits when used over a path with
equipment that implements an AQM method with CE marking of IP equipment that implements an AQM method with CE marking of IP
packets [RFC8087], since it can react to congestion without also packets [RFC8087], since it can react to congestion without also
having to recover from lost packets. having to recover from lost packets.
ECN exposes the presence of congestion. The reception of CE- ECN exposes the presence of congestion. The reception of CE-
marked packets can be used to estimate the level of incipient marked packets can be used to estimate the level of incipient
congestion on the upstream portion of the path from the point of congestion on the upstream portion of the path from the point of
skipping to change at page 18, line 23 skipping to change at page 19, line 24
AQM and ECN offer a range of algorithms and configuration options. AQM and ECN offer a range of algorithms and configuration options.
Tools therefore have to be available to network operators and Tools therefore have to be available to network operators and
researchers to understand the implication of configuration choices researchers to understand the implication of configuration choices
and transport behaviour as the use of ECN increases and new and transport behaviour as the use of ECN increases and new
methods emerge [RFC7567]. methods emerge [RFC7567].
When transport headers cannot be observed, operators are unable to When transport headers cannot be observed, operators are unable to
use this information directly. Careful use of the network layer use this information directly. Careful use of the network layer
features can help provide similar information in the case where the features can help provide similar information in the case where the
network is unable to inspect transport protocol headers. network is unable to inspect transport protocol headers. Section 5
Section Section 5 describes use of network extension headers. describes use of network extension headers.
3.2. Transport Measurement 3.2. Transport Measurement
The common language between network operators and application/content The common language between network operators and application/content
providers/users is packet transfer performance at a layer that all providers/users is packet transfer performance at a layer that all
can view and analyse. For most packets, this has been the transport can view and analyse. For most packets, this has been the transport
layer, until the emergence of transport protocols performing header layer, until the emergence of transport protocols performing header
encryption, with the obvious exception of VPNs and IPsec. encryption, with the obvious exception of VPNs and IPsec.
When encryption hides more layers in each packet, people seeking When encryption hides more layers in each packet, people seeking
understanding of the network operation rely more on pattern inference understanding of the network operation rely more on pattern inference
and other heuristics. It remains to be seen whether more complex and other heuristics. It remains to be seen whether more complex
inferences can be mastered to produce the same monitoring accuracy inferences can be mastered to produce the same monitoring accuracy
(see section 2.1.1 of [RFC8404]). (see Section 2.1.1 of [RFC8404]).
When measurement datasets are made available by servers or client When measurement datasets are made available by servers or client
endpoints, additional metadata, such as the state of the network, is endpoints, additional metadata, such as the state of the network, is
often necessary to interpret this data to answer questions about often necessary to interpret this data to answer questions about
network performance or understand a pathology. Collecting and network performance or understand a pathology. Collecting and
coordinating such metadata is more difficult when the observation coordinating such metadata is more difficult when the observation
point is at a different location to the bottleneck/device under point is at a different location to the bottleneck/device under
evaluation [RFC7799]. evaluation [RFC7799].
Packet sampling techniques are used to scale the processing involved Packet sampling techniques are used to scale the processing involved
skipping to change at page 23, line 41 skipping to change at page 24, line 41
the network. It can also help protect the privacy of a user, by the network. It can also help protect the privacy of a user, by
hiding data relating to user/device identity or location. hiding data relating to user/device identity or location.
4.1. Motivation 4.1. Motivation
There are several motivations for encryption: There are several motivations for encryption:
o One motive to encrypt transport headers is in response to o One motive to encrypt transport headers is in response to
perceptions that the network has become ossified, since traffic perceptions that the network has become ossified, since traffic
inspecting middleboxes prevent new protocols and mechanisms from inspecting middleboxes prevent new protocols and mechanisms from
being deployed. This has lead to a perception that there is too being deployed. One benefit of encrypting transport headers is
much "manipulation" of protocol headers within the network, and that it can help improve the pace of transport development by
that designing to deploy in such networks is preventing transport eliminating interference by deployed middleboxes.
evolution. One benefit of encrypting transport headers is that it
can help improve the pace of transport development by eliminating
interference by deployed middleboxes.
o Another motivation stems from increased concerns about privacy and o Another motivation stems from increased concerns about privacy and
surveillance. Users value the ability to protect their identity surveillance. Users value the ability to protect their identity
and location, and defend against traffic analysis. Revelations and location, and defend against analysis of the traffic.
about the use of pervasive surveillance [RFC7624] have, to some Revelations about the use of pervasive surveillance [RFC7624]
extent, eroded trust in the service offered by network operators have, to some extent, eroded trust in the service offered by
and have led to an increased use of encryption to avoid unwanted network operators and have led to an increased use of encryption
eavesdropping on communications. Concerns have also been voiced to avoid unwanted eavesdropping on communications. Concerns have
about the addition of information to packets by third parties to also been voiced about the addition of information to packets by
provide analytics, customization, advertising, cross-site tracking third parties to provide analytics, customization, advertising,
of users, to bill the customer, or to selectively allow or block cross-site tracking of users, to bill the customer, or to
content. Whatever the reasons, the IETF is designing protocols selectively allow or block content. Whatever the reasons, the
that include transport header encryption (e.g., QUIC IETF is designing protocols that include transport header
[I-D.ietf-quic-transport]) to supplement the already widespread encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement
payload encryption, and to further limit exposure of transport the already widespread payload encryption, and to further limit
metadata to the network. exposure of transport metadata to the network.
The use of transport header authentication and encryption exposes a The use of transport header authentication and encryption exposes a
tussle between middlebox vendors, operators, applications developers tussle between middlebox vendors, operators, applications developers
and users: and users:
o On the one hand, future Internet protocols that support transport o On the one hand, future Internet protocols that support transport
header encryption assist in the restoration of the end-to-end header encryption assist in the restoration of the end-to-end
nature of the Internet by returning complex processing to the nature of the Internet by returning complex processing to the
endpoints, since middleboxes cannot modify what they cannot see, endpoints, since middleboxes cannot modify what they cannot see,
and can improve privacy by reducing leakage of transport metadata. and can improve privacy by reducing leakage of transport metadata.
skipping to change at page 27, line 30 skipping to change at page 28, line 27
packets that set an IPv6 header extension (e.g., results from 2016 in packets that set an IPv6 header extension (e.g., results from 2016 in
[RFC7872]). [RFC7872]).
Protocols can be designed to expose header information separately to Protocols can be designed to expose header information separately to
the (hidden) fields used by the protocol state machine. On the one the (hidden) fields used by the protocol state machine. On the one
hand, such approaches can simplify tools by exposing the relevant hand, such approaches can simplify tools by exposing the relevant
metrics (loss, latency, etc), rather having to derive this from other metrics (loss, latency, etc), rather having to derive this from other
fields. This also permits the protocol to evolve independently of fields. This also permits the protocol to evolve independently of
the ossified observable header [RFC8558]. On the other hand, the ossified observable header [RFC8558]. On the other hand,
protocols do not necessarily have an incentive to expose the actual protocols do not necessarily have an incentive to expose the actual
information that is utilised by the protocol itself and could information that is used by the protocol itself and could therefore
therefore manipulate the exposed header information to gain an manipulate the exposed header information to gain an advantage from
advantage from the network. Where the information is provided by an the network. Where the information is provided by an endpoint, the
endpoint, the incentive to reflect actual transport information has incentive to reflect actual transport information has to be
to be considered when proposing a method. considered when proposing a method.
6. Implications of Protecting the Transport Headers 6. Implications of Protecting the Transport Headers
The choice of which transport header fields to expose and which to The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible. header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to Security work typically employs a design technique that seeks to
skipping to change at page 28, line 19 skipping to change at page 29, line 19
network. Encrypting transport header encryption changes the ability network. Encrypting transport header encryption changes the ability
to collect and independently analyse data. Internet transport to collect and independently analyse data. Internet transport
protocols employ a set of mechanisms. Some of these have to work in protocols employ a set of mechanisms. Some of these have to work in
cooperation with the network layer for loss detection and recovery, cooperation with the network layer for loss detection and recovery,
congestion detection and control. Others have to work only end-to- congestion detection and control. Others have to work only end-to-
end (e.g., parameter negotiation, flow-control). end (e.g., parameter negotiation, flow-control).
The majority of present Internet applications use two well-known The majority of present Internet applications use two well-known
transport protocols, TCP and UDP. Although TCP represents the transport protocols, TCP and UDP. Although TCP represents the
majority of current traffic, many real-time applications use UDP, and majority of current traffic, many real-time applications use UDP, and
much of this traffic utilises RTP format headers in the payload of much of this traffic uses RTP format headers in the payload of the
the UDP datagram. Since these protocol headers have been fixed for UDP datagram. Since these protocol headers have been fixed for
decades, a range of tools and analysis methods have became common and decades, a range of tools and analysis methods have became common and
well-understood. well-understood.
Protocols that expose the state information used by the transport Protocols that expose the state information used by the transport
protocol in their header information (e.g., timestamps used to protocol in their header information (e.g., timestamps used to
calculate the RTT, packet numbers used to asses congestion and calculate the RTT, packet numbers used to asses congestion and
requests for retransmission) provide an incentive for the sending requests for retransmission) provide an incentive for the sending
endpoint to provide correct information, since the protocol will not endpoint to provide correct information, since the protocol will not
work otherwise. This increases confidence that the observer work otherwise. This increases confidence that the observer
understands the transport interaction with the network. For example, understands the transport interaction with the network. For example,
skipping to change at page 36, line 50 skipping to change at page 37, line 50
management functions monitor packets or flows and anti-spam management functions monitor packets or flows and anti-spam
mechanisms need to see mail message content." [RFC7258]. This can mechanisms need to see mail message content." [RFC7258]. This can
be used as the first line of defence to identify potential threats be used as the first line of defence to identify potential threats
from DOS or malware and redirect suspect traffic to dedicated nodes from DOS or malware and redirect suspect traffic to dedicated nodes
responsible for DOS analysis, malware detection, or to perform packet responsible for DOS analysis, malware detection, or to perform packet
"scrubbing" (the normalization of packets so that there are no "scrubbing" (the normalization of packets so that there are no
ambiguities in interpretation by the ultimate destination of the ambiguities in interpretation by the ultimate destination of the
packet). These techniques are currently used by some operators to packet). These techniques are currently used by some operators to
also defend from distributed DOS attacks. also defend from distributed DOS attacks.
Exposed transport header fields are sometimes also utilised as a part Exposed transport header fields can also form a part of the
of the information used by the receiver of a transport protocol to information used by the receiver of a transport protocol to protect
protect the transport layer from data injection by an attacker. In the transport layer from data injection by an attacker. In
evaluating this use of exposed header information, it is important to evaluating this use of exposed header information, it is important to
consider whether it introduces a significant DOS threat. For consider whether it introduces a significant DOS threat. For
example, an attacker could construct a DOS attack by sending packets example, an attacker could construct a DOS attack by sending packets
with a sequence number that falls within the currently accepted range with a sequence number that falls within the currently accepted range
of sequence numbers at the receiving endpoint, this would then of sequence numbers at the receiving endpoint, this would then
introduce additional work at the receiving endpoint, even though the introduce additional work at the receiving endpoint, even though the
data in the attacking packet might not finally be delivered by the data in the attacking packet might not finally be delivered by the
transport layer. This is sometimes known as a "shadowing attack". transport layer. This is sometimes known as a "shadowing attack".
An attack can, for example, disrupt receiver processing, trigger loss An attack can, for example, disrupt receiver processing, trigger loss
and retransmission, or make a receiving endpoint perform unproductive and retransmission, or make a receiving endpoint perform unproductive
decryption of packets that cannot be successfully decrypted (forcing decryption of packets that cannot be successfully decrypted (forcing
a receiver to commit decryption resources, or to update and then a receiver to commit decryption resources, or to update and then
restore protocol state). restore protocol state).
One mitigation to off-path attack is to deny knowledge of what header One mitigation to off-path attack is to deny knowledge of what header
information is accepted by a receiver or obfuscate the accepted information is accepted by a receiver or obfuscate the accepted
header information, e.g., setting a non-predictable initial value for header information, e.g., setting a non-predictable initial value for
a sequence number during a protocol handshake, as in [RFC3550] and a sequence number during a protocol handshake, as in [RFC3550] and
[RFC6056], or a port value that can not be predicted (see section 5.1 [RFC6056], or a port value that can not be predicted (see Section 5.1
of [RFC8085]). A receiver could also require additional information of [RFC8085]). A receiver could also require additional information
to be used as a part of a validation check before accepting packets to be used as a part of a validation check before accepting packets
at the transport layer (e.g., utilising a part of the sequence number at the transport layer (e.g., utilising a part of the sequence number
space that is encrypted; or by verifying an encrypted token not space that is encrypted; or by verifying an encrypted token not
visible to an attacker). This would also mitigate against on-path visible to an attacker). This would also mitigate against on-path
attacks. An additional processing cost can be incurred when attacks. An additional processing cost can be incurred when
decryption has to be attempted before a receiver is able to discard decryption has to be attempted before a receiver is able to discard
injected packets. injected packets.
Open standards motivate a desire for this evaluation to include Open standards motivate a desire for this evaluation to include
skipping to change at page 38, line 10 skipping to change at page 39, line 10
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, and other members of the TSVWG for their Wood, Thomas Fossati, Martin Thomson, and other members of the TSVWG
comments and feedback. 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 39, line 19 skipping to change at page 40, line 19
[I-D.trammell-plus-abstract-mech] [I-D.trammell-plus-abstract-mech]
Trammell, B., "Abstract Mechanisms for a Cooperative Path Trammell, B., "Abstract Mechanisms for a Cooperative Path
Layer under Endpoint Control", draft-trammell-plus- Layer under Endpoint Control", draft-trammell-plus-
abstract-mech-00 (work in progress), September 2016. abstract-mech-00 (work in progress), September 2016.
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of
Techniques and Their Merits, IEEE Comm. Surveys & Techniques and Their Merits, IEEE Comm. Surveys &
Tutorials. 26;18(3) p2149-2196", November 2014. Tutorials. 26;18(3) p2149-2196", November 2014.
[Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- [Measurement]
Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement-
based Protocol Design, Eur. Conf. on Networks and based Protocol Design, Eur. Conf. on Networks and
Communications, Oulu, Finland.", June 2017. Communications, Oulu, Finland.", June 2017.
[Quic-Trace] [Quic-Trace]
"https:QUIC trace utilities //github.com/google/quic- "https:QUIC trace utilities //github.com/google/quic-
trace". trace".
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
skipping to change at page 40, line 25 skipping to change at page 41, line 25
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
skipping to change at page 41, line 23 skipping to change at page 42, line 28
[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, DOI 10.17487/RFC5236, June 2008,
<https://www.rfc-editor.org/info/rfc5236>. <https://www.rfc-editor.org/info/rfc5236>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/info/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
skipping to change at page 47, line 7 skipping to change at page 48, line 7
Added summary text and refs to key sections. Note to editors: The Added summary text and refs to key sections. Note to editors: The
section numbers are hard-linked. section numbers are hard-linked.
-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
corrections from other 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. 47 change blocks. 
155 lines changed or deleted 208 lines changed or added

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