draft-ietf-tsvwg-transport-encrypt-18.txt   draft-ietf-tsvwg-transport-encrypt-19.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: May 6, 2021 University of Glasgow Expires: August 1, 2021 University of Glasgow
November 2, 2020 January 28, 2021
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-18 draft-ietf-tsvwg-transport-encrypt-19
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, mitigate attacks against the transport ossification by middleboxes, mitigate attacks against the transport
protocol, and protect metadata about the communication. Current protocol, and protect metadata about the communication. Current
operational practice in some networks inspect transport header operational practice in some networks inspect transport header
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 May 6, 2021. This Internet-Draft will expire on August 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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. Current uses of Transport Headers within the Network . . . . 4 2. Current uses of Transport Headers within the Network . . . . 4
2.1. To Identify Transport Protocols and Flows . . . . . . . . 5 2.1. To Identify Transport Protocols and Flows . . . . . . . . 5
2.2. To Understand Transport Protocol Performance . . . . . . 6 2.2. To Understand Transport Protocol Performance . . . . . . 6
2.3. To Support Network Operations . . . . . . . . . . . . . . 13 2.3. To Support Network Operations . . . . . . . . . . . . . . 12
2.4. To Support Network Diagnostics and Troubleshooting . . . 16 2.4. To Support Header Compression . . . . . . . . . . . . . . 17
2.5. To Support Header Compression . . . . . . . . . . . . . . 17 2.5. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18
2.6. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18 3. Research, Development and Deployment . . . . . . . . . . . . 18
3. Other Uses of Observable Transport Headers . . . . . . . . . 18 3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19
3.1. Characterising "Unknown" Network Traffic . . . . . . . . 19 3.2. Measurable Transport Protocols . . . . . . . . . . . . . 19
3.2. Accountability and Internet Transport Protocols . . . . . 19 3.3. Other Sources of Information . . . . . . . . . . . . . . 20
3.3. Impact on Tooling and Network Operations . . . . . . . . 20 4. Encryption and Authentication of Transport Headers . . . . . 21
3.4. Independent Measurement . . . . . . . . . . . . . . . . . 20 5. Intentionally Exposing Transport Information to the Network . 25
3.5. Impact on Research, Development and Deployment . . . . . 22 5.1. Exposing Transport Information in Extension Headers . . . 26
4. Encryption and Authentication of Transport Headers . . . . . 23 5.2. Common Exposed Transport Information . . . . . . . . . . 26
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Considerations for Exposing Transport Information . . . . 26
4.2. Approaches to Transport Header Protection . . . . . . . . 26
5. Intentionally Exposing Transport Information to the Network . 28
5.1. Exposing Transport Information in Extension Headers . . . 28
5.2. Common Exposed Transport Information . . . . . . . . . . 29
5.3. Considerations for Exposing Transport Information . . . . 29
6. Addition of Transport OAM Information to Network-Layer 6. Addition of Transport OAM Information to Network-Layer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 30 6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27
6.2. Use of OAM across Multiple Maintenance Domains . . . . . 30 6.2. Use of OAM across Multiple Maintenance Domains . . . . . 28
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
11. Informative References . . . . . . . . . . . . . . . . . . . 36 11. Informative References . . . . . . . . . . . . . . . . . . . 34
Appendix A. Revision information . . . . . . . . . . . . . . . . 45 Appendix A. Revision information . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The transport layer supports the end-to-end flow of data across a The transport layer supports the end-to-end flow of data across a
network path, providing features such as connection establishment, network path, providing features such as connection establishment,
reliability, framing, ordering, congestion control, flow control, reliability, framing, ordering, congestion control, flow control,
etc., as needed to support applications. One of the core functions etc., as needed to support applications. One of the core functions
of an Internet transport: to discover and adapt to the of an Internet transport: to discover and adapt to the
characteristics of the network path that is currently being used. characteristics of the network path that is currently being used.
skipping to change at page 3, line 48 skipping to change at page 3, line 47
Monitoring (PM) is a technical attack that needs to be mitigated in Monitoring (PM) is a technical attack that needs to be mitigated in
the design of IETF protocols. This document supports that the design of IETF protocols. This document supports that
conclusion. It also recognises that RFC7258 states "Making networks conclusion. It also recognises that RFC7258 states "Making networks
unmanageable to mitigate PM is not an acceptable outcome, but unmanageable to mitigate PM is not an acceptable outcome, but
ignoring PM would go against the consensus documented here. An ignoring PM would go against the consensus documented here. 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 considered". This document is written to provide input tension are considered". This document is written to provide input
to the discussion around what is an appropriate balance, by to the discussion around what is an appropriate balance, by
highlighting some implications of transport header encryption. highlighting some implications of transport header encryption.
This document explains current uses of transport header information Current uses of transport header information in the network are
in the network, which can be beneficial or malicious. It is written explained, which can be beneficial or malicious. This is written to
to provide input to the discussion around what is an appropriate provide input to the discussion around what is an appropriate
balance, by highlighting some implications of transport header balance, by highlighting some implications of transport header
encryption. encryption.
2. Current uses of Transport Headers within the Network 2. 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 can improve Applying confidentiality to transport header fields can improve
privacy, and can help to mitigate certain attacks, but can also privacy, and can help to mitigate certain attacks or manipulation of
affect network operations [RFC8404]. packets in the network, but it can also affect network operations and
measurement [RFC8404].
When considering what parts of the transport headers should be When considering what parts of the transport headers should be
encrypted to provide confidentiality, and what parts should be encrypted to provide confidentiality, and what parts should be
visible to the network (including non-encrypted but authenticated visible to the network (including non-encrypted but authenticated
headers), it is necessary to consider both the impact on network headers), it is necessary to consider both the impact on network
operations and management, and the implications for ossification and operations and management, and the implications for ossification and
user privacy [Measurement]. Different parties will view the relative user privacy [Measurement]. Different parties will view the relative
importance of these concerns differently. For some, the benefits of importance of these concerns differently. For some, the benefits of
encrypting all the transport headers outweigh the impact of doing so; encrypting all the transport headers outweigh the impact of doing so;
others might analyse the security, privacy, and ossification impacts others might analyse the security, privacy, and ossification impacts
skipping to change at page 5, line 11 skipping to change at page 5, line 11
headers by middleboxes, such as in Network Address Translation (NAT) headers by middleboxes, such as in Network Address Translation (NAT)
or Firewalls. Common issues concerning IP address sharing are or Firewalls. Common issues concerning IP address sharing are
described in [RFC6269]. described in [RFC6269].
2.1. To Identify Transport Protocols and Flows 2.1. To Identify Transport Protocols and Flows
Information in exposed transport layer headers can be used by the Information in exposed transport layer headers can be used by the
network to identify transport protocols and flows [RFC8558]. The network to identify transport protocols and flows [RFC8558]. The
ability to identify transport protocols, flows, and sessions is a ability to identify transport protocols, flows, and sessions is a
common function performed, for example, by measurement activities, common function performed, for example, by measurement activities,
QoS classifiers, and firewalls. These functions can be beneficial, Quality of Service (QoS) classifiers, and firewalls. These functions
and performed with the consent of, and in support of, the end user. can be beneficial, and performed with the consent of, and in support
Alternatively, a network operator could use the same mechanisms to of, the end user. Alternatively, the same mechanisms could be used
support practises that are adversarial to the end user, including to support practises that might be adversarial to the end user,
blocking, de-prioritising, and monitoring traffic without consent. including blocking, de-prioritising, and monitoring traffic without
consent.
Observable transport header information, together with information in Observable transport header information, together with information in
the network header, has been used to identify flows and their the network header, has been used to identify flows and their
connection state, together with the set of protocol options being connection state, together with the set of protocol options being
used. Transport protocols, such as TCP and the Stream Control used. Transport protocols, such as TCP and the Stream Control
Transport Protocol (SCTP), specify a standard base header that Transport Protocol (SCTP), specify a standard base header that
includes sequence number information and other data. They also have includes sequence number information and other data. They also have
the possibility to negotiate additional headers at connection setup, the possibility to negotiate additional headers at connection setup,
identified by an option number in the transport header. identified by an option number in the transport header.
In some uses, an assigned transport port (e.g., 0..49151) can In some uses, an assigned transport port (e.g., 0..49151) can
identify the upper-layer protocol or service [RFC7605]. However, identify the upper-layer protocol or service [RFC7605]. However,
port information alone is not sufficient to guarantee identification. port information alone is not sufficient to guarantee identification.
Applications can use arbitrary ports and do not need to use assigned Applications can use arbitrary ports and do not need to use assigned
port numbers. The use of an assigned port number is also not limited port numbers. The use of an assigned port number is also not limited
to the protocol for which the port is intended. Multiple sessions to the protocol for which the port is intended. Multiple sessions
can also be multiplexed on a single port, and ports can be re-used by can also be multiplexed on a single port, and ports can be re-used by
subsequent sessions. subsequent sessions.
Some flows can be identified by observing signalling protocol data Some flows can be identified by observing signalling data (e.g.,
(e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic
magic numbers placed in the first byte(s) of the datagram payload numbers placed in the first byte(s) of a datagram payload [RFC7983].
[RFC7983].
When transport header information cannot be observed, this removes When transport header information cannot be observed, this removes
information that could have been used to classify flows by passive information that could have been used to classify flows by passive
observers along the path. More ambitious ways could be used to observers along the path. More ambitious ways could be used to
collect, estimate, or infer flow information, including heuristics collect, estimate, or infer flow information, including heuristics
based on the analysis of traffic patterns. For example, an operator based on the analysis of traffic patterns. For example, an operator
that cannot access the Session Description Protocol (SDP) session that cannot access the Session Description Protocol (SDP) session
descriptions [RFC4566] to classify a flow as audio traffic, might descriptions [RFC4566] to classify a flow as audio traffic, might
instead use (possibly less-reliable) heuristics to infer that short instead use (possibly less-reliable) heuristics to infer that short
UDP packets with regular spacing carry audio traffic. Operational UDP packets with regular spacing carry audio traffic. Operational
skipping to change at page 6, line 13 skipping to change at page 6, line 13
practises that were used with unencrypted transport headers. practises that were used with unencrypted transport headers.
The IAB [RFC8546] have provided a summary of expected implications of The IAB [RFC8546] have provided a summary of expected implications of
increased encryption on network functions that use the observable increased encryption on network functions that use the observable
headers and describe the expected benefits of designs that explicitly headers and describe the expected benefits of designs that explicitly
declare protocol invariant header information that can be used for declare protocol invariant header information that can be used for
this purpose. this purpose.
2.2. To Understand Transport Protocol Performance 2.2. To Understand Transport Protocol Performance
Information in exposed transport layer headers can be used by the This subsection describes use by the network of exposed transport
network to understand transport protocol performance and behaviour. layer headers to understand transport protocol performance and
behaviour.
2.2.1. Using Information Derived from Transport Layer Headers 2.2.1. Using Information 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, and network anomalies at any point along the
at any point along the Internet path. Some operators use passive Internet path. Some operators use passive monitoring to manage their
monitoring to manage their portion of the Internet by characterising portion of the Internet by characterising the performance of link/
the performance of link/network segments. Inferences from transport network segments. Inferences from transport headers are used to
headers are used to derive performance metrics. A variety of open derive performance metrics:
source and commercial tools have been deployed that utilise transport
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 measure 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). those observed at the start and end of a flow).
Measurements can be per endpoint, or for an endpoint aggregate. Measurements can be per endpoint, or for an endpoint aggregate.
This can be used, for example, to assess subscriber usage or for These could be used to assess usage or for subscriber billing.
billing purposes.
Measurements can also be used to trigger traffic shaping, and to Such measurements can be used to trigger traffic shaping, and to
associate QoS support within the network and lower layers. This associate QoS support within the network and lower layers. This
can be done with consent and in support of an end user, to improve can be done with consent and in support of an end user, to improve
quality of service; or can be used by the network to de-prioritise quality of service; or could be used by the network to de-
certain flows without user consent. prioritise certain flows without user consent.
Volume measures can also be valuable for capacity planning and
providing detail of trends in usage.
The traffic rate and volume can be determined providing that the The traffic rate and volume can be determined providing that the
packets belonging to individual flows can be identified, but there packets belonging to individual flows can be identified, but there
might be no additional information about a flow when the transport might be no additional information about a flow when the transport
headers cannot be observed. 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
operator determine whether this requires corrective action. Network operators have used the variation in patterns to detect
Network operators have used the variation in patterns of loss as a changes in the offered service. Understanding the location and
key performance metric, utilising this to detect changes in the root cause of loss can help an operator determine whether this
offered service. requires corrective action.
There are various causes of loss, including: corruption of link There are various causes of loss, including: corruption of link
frames (e.g., due to interference on a radio link), buffering loss frames (e.g., due to interference on a radio link), buffering loss
(e.g., overflow due to congestion, Active Queue Management (AQM) (e.g., overflow due to congestion, Active Queue Management, AQM
[RFC7567], or inadequate provision following traffic pre-emption), [RFC7567], or inadequate provision following traffic pre-emption),
and policing (traffic management) [RFC2475]. Understanding flow and policing (traffic management [RFC2475]). Understanding flow
loss rates requires either observing sequence numbers in network loss rates requires either observing sequence numbers in network
or transport headers, or maintaining per-flow packet counters or transport headers, or maintaining per-flow packet counters
(flow identification often requires transport layer information). (flow identification often requires transport layer information).
Per-hop loss can also sometimes be monitored at the interface Per-hop loss can also sometimes be monitored at the interface
level by devices in the network. level by devices in the network.
Losses can often occur as bursts, randomly-timed events, etc. The The pattern of loss can provide insight into the cause of loss.
pattern of loss can provide insight into the cause of loss. It Losses can often occur as bursts, randomly-timed events, etc. It
can also be valuable to understand the conditions under which loss can also be valuable to understand the conditions under which loss
occurs, which usually requires relating loss to the traffic occurs. This usually requires relating loss to the traffic
flowing at a network node or segment at the time of loss. This flowing at a network node or segment at the time of loss.
can also help identify cases where loss could have been wrongly Transport header information can help identify cases where loss
identified, or where the transport did not require transmission of could have been wrongly identified, or where the transport did not
a lost packet. require transmission of a lost packet.
Throughput and Goodput: Throughput is the amount of payload data Throughput and Goodput: Throughput is the amount of payload data
sent by a flow per time interval. Goodput (see Section 2.5 of sent by a flow per time interval. Goodput (see Section 2.5 of
[RFC7928]) is a measure of useful data exchanged (the ratio of [RFC7928]) is a measure of useful data exchanged (the ratio of
useful data to total volume of traffic sent by a flow). The useful data to total volume of traffic sent by a flow). The
throughput of a flow can be determined in the absence of transport throughput of a flow can be determined in the absence of transport
header information, providing that the individual flow can be header information, providing that the individual flow can be
identified, and the overhead known. Goodput requires ability to identified, and the overhead known. Goodput requires ability to
differentiate loss and retransmission of packets, for example by differentiate loss and retransmission of packets, for example by
observing packet sequence numbers in the TCP or RTP headers observing packet sequence numbers in the TCP or RTP headers
skipping to change at page 8, line 33 skipping to change at page 8, line 30
could identify excessively large buffers, indicating where to could identify excessively large buffers, indicating where to
deploy or configure AQM. An AQM method is often deployed in deploy or configure AQM. An AQM method is often deployed in
combination with other techniques, such as scheduling [RFC7567] combination with other techniques, such as scheduling [RFC7567]
[RFC8290] and although parameter-less methods are desired [RFC8290] and although parameter-less methods are desired
[RFC7567], current methods often require tuning [RFC8290] [RFC7567], current methods often require tuning [RFC8290]
[RFC8289] [RFC8033] because they cannot scale across all possible [RFC8289] [RFC8033] because they cannot scale across all possible
deployment scenarios. deployment scenarios.
Latency and round-trip time information can potentially expose Latency and round-trip time information can potentially expose
some information useful for approximate geolocation, as discussed some information useful for approximate geolocation, as discussed
in [PAM-RTT]. Encrypting transport headers can reduce the latency in [PAM-RTT].
information that is available.
Variation in delay: Some network applications are sensitive to Variation in delay: Some network applications are sensitive to
(small) changes in packet timing (jitter). Short and long-term (small) changes in packet timing (jitter). Short and long-term
delay variation can impact on the latency of a flow and hence the delay variation can impact on the latency of a flow and hence the
perceived quality of applications using the network. For example, perceived quality of applications using the network. For example,
jitter metrics are often cited when characterising paths jitter metrics are often cited when characterising paths
supporting real-time traffic. The expected performance of such supporting real-time traffic. The expected performance of such
applications, can be inferred from a measure the variation in applications, can be inferred from a measure the variation in
delay observed along a portion of the path [RFC3393] [RFC5481]. delay observed along a portion of the path [RFC3393] [RFC5481].
The requirements resemble those for the measurement of latency. The requirements resemble those for the measurement of latency.
skipping to change at page 9, line 13 skipping to change at page 9, line 8
for many reasons, from equipment design to misconfiguration of for many reasons, from equipment design to misconfiguration of
forwarding rules. Network tools can detect and measure unwanted/ forwarding rules. Network tools can detect and measure unwanted/
excessive reordering, and the impact on transport performance. excessive reordering, and the impact on transport performance.
There have been initiatives in the IETF transport area to reduce There have been initiatives in the IETF transport area to reduce
the impact of reordering within a transport flow, possibly leading the impact of reordering within a transport flow, possibly leading
to a reduction in the requirements for preserving ordering. These to a reduction in the requirements for preserving ordering. These
have potential to simplify network equipment design as well as the have potential to simplify network equipment design as well as the
potential to improve robustness of the transport service. potential to improve robustness of the transport service.
Measurements of reordering can help understand the present level Measurements of reordering can help understand the present level
of reordering within deployed infrastructure, and inform decisions of reordering, and inform decisions about how to progress new
about how to progress such mechanisms. Key performance indicators mechanisms.
are retransmission rate, packet drop rate, sector utilisation
level, a measure of reordering, peak rate, the ECN congestion
experienced (CE) marking rate, etc.
Metrics have been defined that evaluate whether a network has
maintained packet order on a packet-by-packet basis [RFC4737]
[RFC5236].
Techniques for measuring reordering typically observe packet Techniques for measuring reordering typically observe packet
sequence numbers. Some protocols provide in-built monitoring and sequence numbers. Metrics have been defined that evaluate whether
reporting functions. Transport fields in the RTP header [RFC3550] a network has maintained packet order on a packet-by-packet basis
[RFC4585] can be observed to derive traffic volume measurements [RFC4737] [RFC5236]. Some protocols provide in-built monitoring
and provide information on the progress and quality of a session and reporting functions. Transport fields in the RTP header
using RTP. As with other measurement, metadata assist in [RFC3550] [RFC4585] can be observed to derive traffic volume
understanding the context under which the data was collected, measurements and provide information on the progress and quality
including the time, observation point [RFC7799], and way in which of a session using RTP. Metadata assists in understanding the
metrics were accumulated. The RTCP protocol directly reports some context under which the data was collected, including the time,
of this information in a form that can be directly visible in the observation point [RFC7799], and way in which metrics were
network. A user of summary measurement data has to trust the accumulated. The RTCP protocol directly reports some of this
source of this data and the method used to generate the summary information in a form that can be directly visible in the network.
information.
These metrics can support network operations, inform capacity
planning, and assist in determining the demand for equipment and/or
configuration changes by network operators. They can also inform
Internet engineering activities by informing the development of new
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 2.3.1). Measurements can rely on observing packet headers, Section 2.3.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.
One alternative approach is to use in-network techniques, which does Passive packet sampling techniques are also often used to scale the
not require the cooperation of an endpoint (see Section 6). processing involved in observing packets on high rate links. This
exports only the packet header information of (randomly) selected
packets. Interpretation of the exported information relies on
understanding of the header information. The utility of these
measurements depends on the type of bearer and number of mechanisms
used by network devices. Simple routers are relatively easy to
manage, but a device with more complexity demands understanding of
the choice of many system parameters.
2.2.2. Using Information Derived from Network Layer Header Fields 2.2.2. Using Information Derived from Network Layer Header Fields
Information from the transport header can be used by a multi-field Information from the transport header can be used by a multi-field
classifier as a part of policy framework. Policies are commonly used (MF) classifier as a part of policy framework. Policies are commonly
for management of the QoS or Quality of Experience (QoE) in resource- used for management of the QoS or Quality of Experience (QoE) in
constrained networks, or by firewalls to implement access rules (see resource-constrained networks, or by firewalls to implement access
also Section 2.2.2 of [RFC8404]). Operators can use such policies to rules (see also Section 2.2.2 of [RFC8404]). Policies can support
support user applications and to protect against unwanted traffic. user applications/services or protect against unwanted, or lower
Such policies can also be used without user consent, to de-prioritise priority traffic (Section 2.3.4).
certain applications or services, for example.
Network-layer classification methods that rely on a multi-field
classifier (e.g., inferring QoS from the 5-tuple or choice of
application protocol) are incompatible with transport protocols that
encrypt the transport header information. Traffic that cannot be
classified typically receives a default treatment. Some networks
block or rate traffic that cannot be classified.
Transport layer information can also be explicitly carried in Transport layer information can also be explicitly carried in
network-layer header fields that are not encrypted, serving as a network-layer header fields that are not encrypted, serving as a
replacement/addition to the exposed transport header information replacement/addition to the exposed transport header information
[RFC8558]. This information can enable a different forwarding [RFC8558]. This information can enable a different forwarding
treatment by the network, even when a transport employs encryption to treatment by the network, even when a transport employs encryption to
protect other header information. protect other header information.
The user of a transport that multiplexes multiple sub-flows might On the one hand, the user of a transport that multiplexes multiple
want to obscure the presence and characteristics of these sub-flows. sub-flows might want to obscure the presence and characteristics of
On the other hand, an encrypted transport could set the network-layer these sub-flows. On the other hand, an encrypted transport could set
information to indicate the presence of sub-flows, and to reflect the the network-layer information to indicate the presence of sub-flows,
service requirements of individual sub-flows. There are several ways and to reflect the service requirements of individual sub-flows.
this could be done: There are several ways this could be done:
IP Address: Applications normally expose the addresses used by IP Address: Applications normally expose the endpoint addresses used
endpoints, and this is used in the forwarding decisions in network in the forwarding decisions in network devices. Address and other
devices. Address and other protocol information can be used by a protocol information can be used by a MF-classifier to determine
Multi-Field (MF) classifier to determine how traffic is treated how traffic is treated [RFC2475], and hence affect the quality of
[RFC2475], and hence affect the quality of experience for a flow. experience for a flow.
Using the IPv6 Network-Layer Flow Label: A number of Standards Track Using the IPv6 Network-Layer Flow Label: A number of Standards Track
and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437],
[RFC6438]) encourage endpoints to set the IPv6 flow label field of [RFC6438]) encourage endpoints to set the IPv6 flow label field of
the network-layer header. IPv6 "source nodes SHOULD assign each the network-layer header. IPv6 "source nodes SHOULD assign each
unrelated transport connection and application data stream to a unrelated transport connection and application data stream to a
new flow" [RFC6437]. A multiplexing transport could choose to use new flow" [RFC6437]. A multiplexing transport could choose to use
multiple flow labels to allow the network to independently forward multiple flow labels to allow the network to independently forward
sub-flows. RFC6437 provides further guidance on choosing a flow sub-flows. RFC6437 provides further guidance on choosing a flow
label value, stating these "should be chosen such that their bits label value, stating these "should be chosen such that their bits
exhibit a high degree of variability", and chosen so that "third exhibit a high degree of variability", and chosen so that "third
parties should be unlikely to be able to guess the next value that parties should be unlikely to be able to guess the next value that
a source of flow labels will choose". a source of flow labels will choose".
Once set, a flow label can provide information that can help Once set, a flow label can provide information that can help
inform network-layer queueing and forwarding [RFC6438], for inform network-layer queueing and forwarding [RFC6438], for
example with Equal Cost Multi-Path routing and Link Aggregation example with Equal Cost Multi-Path routing and Link Aggregation
[RFC6294]. Considerations when using IPsec are further described [RFC6294]. RFC 6438 describes considerations when using IPsec
in [RFC6438]. [RFC6438].
The choice of how to assign a flow label needs to avoid The choice of how to assign a flow label needs to avoid
introducing linkability that a network device could observe. introducing linkability that a network device could observe.
Inappropriate use by the transport can have privacy implications Inappropriate use by the transport can have privacy implications
(e.g., assigning the same label to two independent flows that (e.g., assigning the same label to two independent flows that
ought not to be classified the same). ought not to be classified the same).
Using the Network-Layer Differentiated Services Code Point: Using the Network-Layer Differentiated Services Code Point:
Applications can expose their delivery expectations to the network Applications can expose their delivery expectations to the network
by setting the Differentiated Services Code Point (DSCP) field of by setting the Differentiated Services Code Point (DSCP) field of
skipping to change at page 11, line 47 skipping to change at page 11, line 26
(audio vs. video) based on the value of the DSCP field (audio vs. video) based on the value of the DSCP field
[I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information
to inform network-layer queueing and forwarding, rather than an to inform network-layer queueing and forwarding, rather than an
operator inferring traffic requirements from transport and operator inferring traffic requirements from transport and
application headers via a multi-field classifier. Inappropriate application headers via a multi-field classifier. Inappropriate
use by the transport can have privacy implications (e.g., use by the transport can have privacy implications (e.g.,
assigning a different DSCP to a subflow could assist in a network assigning a different DSCP to a subflow could assist in a network
device discovering the traffic pattern used by an application, device discovering the traffic pattern used by an application,
assigning the same label to two independent flows that ought not assigning the same label to two independent flows that ought not
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. Since the
DSCP value is defined by an RFC). DSCP value can impact the quality of experience for a flow,
observations of service performance have to consider this field
Since the DSCP value can impact the quality of experience for a when a network path supports differentiated service treatment.
flow, observations of service performance has to consider this
field when a network path supports differentiated service
treatment.
Using Explicit Congestion Marking: ECN [RFC3168] is a transport Using Explicit Congestion Marking: ECN [RFC3168] is a transport
mechanism that uses 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.
skipping to change at page 12, line 29 skipping to change at page 12, line 5
observation (Section 2.5 of [RFC8087]). Interpreting the marking observation (Section 2.5 of [RFC8087]). Interpreting the marking
behaviour (i.e., assessing congestion and diagnosing faults) behaviour (i.e., assessing congestion and diagnosing faults)
requires context from the transport layer, such as path RTT. requires context from the transport layer, such as path RTT.
AQM and ECN offer a range of algorithms and configuration options. AQM and ECN offer a range of algorithms and configuration options.
Tools therefore 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].
Network-Layer Options Network protocols can carry optional headers. Network-Layer Options Network protocols can carry optional headers
These can be used to explicitly expose transport header (see Section 5.1). These can explicitly expose transport header
information to on-path devices operating at the network layer (as information to on-path devices operating at the network layer (as
discussed further in Section 6). discussed further in Section 6).
IPv4 [RFC0791] has provision for optional header fields identified IPv4 [RFC0791] has provision for optional header fields. IP
by an option type field. IP routers can examine these headers and routers can examine these headers and are required to ignore IPv4
are required to ignore IPv4 options that they does not recognise. options that they does not recognise. Many current paths include
Many current paths include network devices that forward packets network devices that forward packets that carry options on a
that carry options on a slower processing path. Some network slower processing path. Some network devices (e.g., firewalls)
devices (e.g., firewalls) can be (and are) configured to drop can be (and are) configured to drop these packets [RFC7126]. BCP
these packets [RFC7126]. BCP 186 [RFC7126] provides Best Current 186 [RFC7126] provides Best Current Practice guidance on how
Practice guidance on how operators should treat IPv4 packets that operators should treat IPv4 packets that specify options.
specify options.
IPv6 can encode optional network-layer information in separate IPv6 can encode optional network-layer information in separate
headers that may be placed between the IPv6 header and the upper- headers that may be placed between the IPv6 header and the upper-
layer header [RFC8200]. The Hop-by-Hop options header, when layer header [RFC8200]. The Hop-by-Hop options header, when
present, immediately follows the IPv6 header. IPv6 permits this present, immediately follows the IPv6 header. IPv6 permits this
header to be examined by any node along the path. While [RFC7872] header to be examined by any node along the path if explicitly
required all nodes to examine and process the Hop-by-Hop options configured [RFC8200].
header, it is now expected [RFC8200] that nodes along a path only
examine and process the Hop-by-Hop options header if explicitly
configured to do so.
Careful use of the network layer features can help provide similar Careful use of the network layer features (e.g., Extension Headers
information in the case where the network is unable to inspect can Section 5) help provide similar information in the case where the
transport protocol headers. Section 5 describes use of network network is unable to inspect transport protocol headers.
extension headers.
2.3. To Support Network Operations 2.3. To Support Network Operations
Some network operators make use of on-path observations of transport Some network operators make use of on-path observations of transport
headers to monitor the performance of their networks, and to support headers to analyse the service offered to the users of a network
network operations. Transport protocols with observable headers segment, and to inform operational practice, and can help detect and
allow such operators to explicitly measurement and analyse transport
protocol performance, and in some cases this can help detect and
locate network problems. [RFC8517] gives an operator's perspective locate network problems. [RFC8517] gives an operator's perspective
about such use. about such use.
When encryption hides the transport headers, making it difficult to When observable transport header information is not available, those
directly observe transport behaviour and dynamics, those seeking an seeking an understanding of transport behaviour and dynamics might
understanding of network operations might learn to work without that learn to work without that information. Alternatively, they might
information. Alternatively, they might use more limited measurements use more limited measurements combined with pattern inference and
combined with pattern inference and other heuristics to infer network other heuristics to infer network behaviour (see Section 2.1.1 of
behaviour (see Section 2.1.1 of [RFC8404]). Operational practises [RFC8404]). Operational practises aimed at inferring transport
aimed at inferring transport parameters are out of scope for this parameters are out of scope for this document, and are only mentioned
document, and are only mentioned here to recognise that encryption here to recognise that encryption does not necessarily stop operators
does not necessarily stop operators from attempting to apply from attempting to apply practises that have been used with
practises that have been used with unencrypted transport headers. unencrypted transport headers.
When measurement datasets are made available by servers or client
endpoints, additional metadata, such as the state of the network, is
often necessary to interpret this data to answer questions about
network performance or understand a pathology. Collecting and
coordinating such metadata is more difficult when the observation
point is at a different location to the bottleneck or device under
evaluation [RFC7799].
Packet sampling techniques are used to scale the processing involved
in observing packets on high rate links. This exports only the
packet header information of (randomly) selected packets. The
utility of these measurements depends on the type of bearer and
number of mechanisms used by network devices. Simple routers are
relatively easy to manage, but a device with more complexity demands
understanding of the choice of many system parameters. This level of
complexity exists when several network methods are combined.
This section discusses topics concerning observation of transport This section discusses topics concerning observation of transport
flows, with a focus on transport measurement. flows, with a focus on transport measurement.
2.3.1. Problem Location 2.3.1. Problem Location
In network measurements of transport header information can be used Observations of transport header information can be used to locate
to locate the source of problems, or to assess the performance of a the source of problems or to assess the performance of a network
network segment or a particular device configuration. Often issues segment. Often issues can only be understood in the context of the
can only be understood in the context of the other flows that share a other flows that share a particular path, particular device
particular path, common network device, interface port, etc. A configuration, interface port, etc. A simple example is monitoring
simple example is monitoring of a network device that uses a of a network device that uses a scheduler or active queue management
scheduler or active queue management technique [RFC7567], where it technique [RFC7567], where it could be desirable to understand
could be desirable to understand whether the algorithms are correctly whether the algorithms are correctly controlling latency, or if
controlling latency, or if overload protection is working. This overload protection is working. This implies knowledge of how
understanding implies knowledge of how traffic is assigned to any traffic is assigned to any sub-queues used for flow scheduling, but
sub-queues used for flow scheduling, but can also require information can require information about how the traffic dynamics impact active
about how the traffic dynamics impact active queue management, queue management, starvation prevention mechanisms, and circuit-
starvation prevention mechanisms, and circuit-breakers. breakers.
Sometimes multiple in network observation points have to be used. By Sometimes correlating observations of headers at multiple points
correlating observations of headers at multiple points along the path along the path (e.g., at the ingress and egress of a network
(e.g., at the ingress and egress of a network segment), an observer segment), allows an observer to determine the contribution of a
can determine the contribution of a portion of the path to an portion of the path to an observed metric. e.g., to locate a source
observed metric, to locate a source of delay, jitter, loss, of delay, jitter, loss, reordering, congestion marking.
reordering, congestion marking, etc.
2.3.2. Network Planning and Provisioning 2.3.2. Network Planning and Provisioning
Traffic rate and volume measurements are used by operators to help Traffic rate and volume measurements are used to help plan deployment
plan deployment of new equipment and configuration in their networks. of new equipment and configuration in networks. Data is also
Data is also valuable to equipment vendors who want to understand valuable to equipment vendors who want to understand traffic trends
traffic trends and patterns of usage as inputs to decisions about and patterns of usage as inputs to decisions about planning products
planning products and provisioning for new deployments. This and provisioning for new deployments.
measurement information can also be correlated with billing
information when this is also collected by an operator.
Trends in aggregate traffic can be observed and can be related to the Trends in aggregate traffic can be observed and can be related to the
endpoint addresses being used, but when transport header information endpoint addresses being used, but when transport header information
is not observable, it might be impossible to correlate patterns in is not observable, it might be impossible to correlate patterns in
measurements with changes in transport protocols. This increases the measurements with changes in transport protocols. This increases the
dependency on other indirect sources of information to inform dependency on other indirect sources of information to inform
planning and provisioning. planning and provisioning.
2.3.3. Service Performance Measurement 2.3.3. Compliance with Congestion Control
Performance measurements (e.g., throughput, loss, latency) can be
used by various actors to analyse the service offered to the users of
a network segment, and to inform operational practice.
2.3.4. Compliance with Congestion Control
The traffic that can be observed by on-path network devices (the The traffic that can be observed by on-path network devices (the
"wire image") is a function of transport protocol design/options, "wire image") is a function of transport protocol design/options,
network use, applications, and user characteristics. In general, network use, applications, and user characteristics. In general,
when only a small proportion of the traffic has a specific when only a small proportion of the traffic has a specific
(different) characteristic, such traffic seldom leads to operational (different) characteristic, such traffic seldom leads to operational
concern, although the ability to measure and monitor it is lower. concern, although the ability to measure and monitor it is lower.
The desire to understand the traffic and protocol interactions The desire to understand the traffic and protocol interactions
typically grows as the proportion of traffic increases in volume. typically grows as the proportion of traffic increases in volume.
The challenges increase when multiple instances of an evolving The challenges increase when multiple instances of an evolving
protocol contribute to the traffic that share network capacity. protocol contribute to the traffic that share network capacity.
Operators can manage traffic load (e.g., when the network is severely Operators can manage traffic load (e.g., when the network is severely
overloaded) by deploying rate-limiters, traffic shaping, or network overloaded) by deploying rate-limiters, traffic shaping, or network
transport circuit breakers [RFC8084]. The information provided by transport circuit breakers [RFC8084]. The information provided by
observing transport headers is a source of data that can help to observing transport headers is a source of data that can help to
inform such mechanisms. inform such mechanisms.
Congestion Control Compliance of Traffic: Congestion control is a Congestion Control Compliance of Traffic: Congestion control is a
skipping to change at page 15, line 40 skipping to change at page 14, line 30
application-layer mechanisms [RFC8085]. application-layer mechanisms [RFC8085].
A standards-compliant TCP stack provides congestion control that A standards-compliant TCP stack provides congestion control that
is judged safe for use across the Internet. Applications is judged safe for use across the Internet. Applications
developed on top of well-designed transports can be expected to developed on top of well-designed transports can be expected to
appropriately control their network usage, reacting when the appropriately control their network usage, reacting when the
network experiences congestion, by back-off and reduce the load network experiences congestion, by back-off and reduce the load
placed on the network. This is the normal expected behaviour for placed on the network. This is the normal expected behaviour for
IETF-specified transports (e.g., TCP and SCTP). IETF-specified transports (e.g., TCP and SCTP).
However, when anomalies are detected, tools can interpret the
transport protocol header information to help understand the
impact of specific transport protocols (or protocol mechanisms) on
the other traffic that shares a network. An observation in the
network can gain an understanding of the dynamics of a flow and
its congestion control behaviour. Analysing observed flows can
help to build confidence that an application flow backs-off its
share of the network load under persistent congestion, and hence
to understand whether the behaviour is appropriate for sharing
limited network capacity. For example, it is common to visualise
plots of TCP sequence numbers versus time for a flow to understand
how a flow shares available capacity, deduce its dynamics in
response to congestion, etc.
The ability to identify sources and flows that contribute to
persistent congestion is important to the safe operation of
network infrastructure, and can inform configuration of network
devices to complement the endpoint congestion avoidance mechanisms
[RFC7567] [RFC8084] to avoid a portion of the network being driven
into congestion collapse [RFC2914].
Congestion Control Compliance for UDP traffic: UDP provides a Congestion Control Compliance for UDP traffic: UDP provides a
minimal message-passing datagram transport that has no inherent minimal message-passing datagram transport that has no inherent
congestion control mechanisms. Because congestion control is congestion control mechanisms. Because congestion control is
critical to the stable operation of the Internet, applications and critical to the stable operation of the Internet, applications and
other protocols that choose to use UDP as a transport have to other protocols that choose to use UDP as a transport have to
employ mechanisms to prevent collapse, avoid unacceptable employ mechanisms to prevent collapse, avoid unacceptable
contributions to jitter/latency, and to establish an acceptable contributions to jitter/latency, and to establish an acceptable
share of capacity with concurrent traffic [RFC8085]. share of capacity with concurrent traffic [RFC8085].
A network operator can observe the headers of transport protocols
layered above UDP to understand if the datagram flows comply with
congestion control expectations. This can help inform a decision
on whether it might be appropriate to deploy methods such as rate-
limiters to enforce acceptable usage.
UDP flows that expose a well-known header can be observed to gain UDP flows that expose a well-known header can be observed to gain
understanding of the dynamics of a flow and its congestion control understanding of the dynamics of a flow and its congestion control
behaviour. For example, tools exist to monitor various aspects of behaviour. For example, tools exist to monitor various aspects of
RTP header information and RTCP reports for real-time flows (see RTP header information and RTCP reports for real-time flows (see
Section 2.2). The Secure RTP and RTCP extensions [RFC3711] were Section 2.2). The Secure RTP and RTCP extensions [RFC3711] were
explicitly designed to expose some header information to enable explicitly designed to expose some header information to enable
such observation, while protecting the payload data. such observation, while protecting the payload data.
2.4. To Support Network Diagnostics and Troubleshooting A network operator can observe the headers of transport protocols
layered above UDP to understand if the datagram flows comply with
congestion control expectations. This can help inform a decision
on whether it might be appropriate to deploy methods such as rate-
limiters to enforce acceptable usage. The available information
determines the level of precision with which flows can be
classified and the design space for conditioning mechanisms (e.g.,
rate limiting, circuit breaker techniques [RFC8084], or blocking
of uncharacterised traffic) [RFC5218].
Transport header information can be utilised for a variety of When anomalies are detected, tools can interpret the transport header
operational tasks [RFC8404]: to diagnose network problems, assess information to help understand the impact of specific transport
network provider performance, evaluate equipment or protocol protocols (or protocol mechanisms) on the other traffic that shares a
performance, capacity planning, management of security threats network. An observation in the network can gain an understanding of
(including DoS), and responding to user performance questions. the dynamics of a flow and its congestion control behaviour.
Analysing observed flows can help to build confidence that an
application flow backs-off its share of the network load under
persistent congestion, and hence to understand whether the behaviour
is appropriate for sharing limited network capacity. For example, it
is common to visualise plots of TCP sequence numbers versus time for
a flow to understand how a flow shares available capacity, deduce its
dynamics in response to congestion, etc.
The ability to identify sources and flows that contribute to
persistent congestion is important to the safe operation of network
infrastructure, and can inform configuration of network devices to
complement the endpoint congestion avoidance mechanisms [RFC7567]
[RFC8084] to avoid a portion of the network being driven into
congestion collapse [RFC2914].
2.3.4. To Characterise "Unknown" Network Traffic
The patterns and types of traffic that share Internet capacity change
over time as networked applications, usage patterns and protocols
continue to evolve.
Encryption can increase the volume of "unknown" or "uncharacterised"
traffic seen by the network. If these traffic patterns form a small
part of the traffic aggregate passing through a network device or
segment of the network the path, the dynamics of the uncharacterised
traffic might not have a significant collateral impact on the
performance of other traffic that shares this network segment. Once
the proportion of this traffic increases, monitoring the traffic can
determine if appropriate safety measures have to be put in place.
Tracking the impact of new mechanisms and protocols requires traffic
volume to be measured and new transport behaviours to be identified.
This is especially true of protocols operating over a UDP substrate.
The level and style of encryption needs to be considered in
determining how this activity is performed. On a shorter timescale,
information could also be collected to manage Denial of Service (DoS)
attacks against the infrastructure.
Traffic that cannot be classified, typically receives a default
treatment. Some networks block or rate-limit traffic that cannot be
classified.
2.3.5. Network Diagnostics and Troubleshooting
Operators monitor the health of a network segment to support a
variety of operational tasks [RFC8404] including procedures to
provide early warning and trigger action: to diagnose network
problems, to manage security threats (including DoS), to evaluate
equipment or protocol performance, or to respond to user performance
questions. Information about transport flows can assist in setting
buffer sizes, and help identify whether link/network tuning is
effective. Information can also support debugging and diagnosis of
the root causes of faults that concern a particular user's traffic
and can support post-mortem investigation after an anomaly.
Section 3.1.2 and Section 5 of [RFC8404] provide further examples. Section 3.1.2 and Section 5 of [RFC8404] provide further examples.
Operators can monitor the health of a portion of the Internet, to Network segments vary in their complexity. The design trade-offs for
provide early warning and trigger action. Traffic and performance radio networks are often very different from those of wired networks
measurements can assist in setting buffer sizes, debugging and [RFC8462]. A radio-based network (e.g., cellular mobile, enterprise
diagnosing the root causes of faults that concern a particular user's Wireless LAN (WLAN), satellite access/back-haul, point-to-point
traffic. They can also be used to support post-mortem investigation radio) add a subsystem that performs radio resource management, with
after an anomaly to determine the root cause of a problem. In other impact on the available capacity, and potentially loss/reordering of
cases, measurement involves dissecting network traffic flows. packets. This impact can differ by traffic type, and can be
Observed transport header information can help identify whether link/ correlated with link propagation and interference. These can impact
network tuning is effective and alert to potential problems that can the cost and performance of a provided service, and is expected to
be hard to derive from link or device measurements alone. increase in importance as operators bring together heterogeneous
types of network equipment and deploy opportunistic methods to access
shared radio spectrum.
An alternative could rely on access to endpoint diagnostic tools or 2.3.6. Tooling and Network Operations
user involvement in diagnosing and troubleshooting unusual use cases
or to troubleshoot non-trivial problems.
Another approach is to use traffic pattern analysis. Such tools can A variety and open source and proprietary tools have been deployed
provide useful information during network anomalies (e.g., detecting that use the transport header information observable with widely used
significant reordering, high or intermittent loss), however indirect protocols such as TCP or RTP/UDP/IP. Tools that dissect network
measurements would need to be carefully designed to provide traffic flows can alert to potential problems that are hard to derive
information for diagnostics and troubleshooting. from volume measurements, link statistics or device measurements
alone.
The design trade-offs for radio networks are often very different Changes to the transport, whether to protect the transport headers,
from those of wired networks. A radio-based network (e.g., cellular introduce a new transport protocol, protocol feature, or application
mobile, enterprise Wireless LAN (WLAN), satellite access/back-haul, might require changes to such tools, and so could impact operational
point-to-point radio) has the complexity of a subsystem that performs practice and policies. Such changes have associated costs that are
radio resource management, with direct impact on the available incurred by the network operators that need to update their tooling
capacity, and potentially loss/reordering of packets. The impact of or develop alternative practises that work without access to the
the pattern of loss and congestion and differences between traffic changed/removed information.
types, and their correlation with link propagation and interference
can all have significant impact on the cost and performance of a
provided service. For radio links, the use for this type of
information is expected to increase as operators bring together
heterogeneous types of network equipment and seek to deploy
opportunistic methods to access radio spectrum.
Lack of tools and resulting information can reduce the ability of an The use of encryption has the desirable effect of preventing
operator to observe transport performance and could limit the ability unintended observation of the payload data and these tools seldom
of network operators to trace problems, make appropriate QoS seek to observe the payload, or other application details. A flow
decisions, or respond to other queries about the network service. that hides its transport header information could imply "don't touch"
to some operators. This might limit a trouble-shooting response to
"can't help, no trouble found".
A network operator supporting traffic that uses transport header An alternative that does not require access to observable transport
encryption is unable to use tools that rely on transport protocol headers is to access endpoint diagnostic tools or to include user
information. However, the use of encryption has the desirable effect involvement in diagnosing and troubleshooting unusual use cases or to
of preventing unintended observation of the payload data and these troubleshoot non-trivial problems. Another approach is to use
tools seldom seek to observe the payload, or other application traffic pattern analysis. Such tools can provide useful information
details. A flow that hides its transport header information could during network anomalies (e.g., detecting significant reordering,
imply "don't touch" to some operators. This might limit a trouble- high or intermittent loss), however indirect measurements need to be
shooting response to "can't help, no trouble found". carefully designed to provide information for diagnostics and
troubleshooting.
2.5. To Support Header Compression If new protocols, or protocol extensions, are made to closely
resemble or match existing mechanisms, then the changes to tooling
and the associated costs can be small. Equally, more extensive
changes to the transport tend to require more extensive, and more
expensive, changes to tooling and operational practice. Protocol
designers can mitigate these costs by explicitly choosing to expose
selected information as invariants that are guaranteed not to change
for a particular protocol (e.g., the header invariants and the spin-
bit in QUIC [I-D.ietf-quic-transport]). Specification of common log
formats and development of alternative approaches can also help
mitigate the costs of transport changes.
2.4. To Support Header Compression
Header compression saves link capacity by compressing network and Header compression saves link capacity by compressing network and
transport protocol headers on a per-hop basis. It was widely used transport protocol headers on a per-hop basis. It was widely used
with low bandwidth dial-up access links, and still finds application with low bandwidth dial-up access links, and still finds application
on wireless links that are subject to capacity constraints. Examples on wireless links that are subject to capacity constraints. Examples
of header compression include use with TCP/IP and RTP/UDP/IP flows of header compression include use with TCP/IP and RTP/UDP/IP flows
[RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful compression [RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful compression
depends on observing the transport headers and understanding of the depends on observing the transport headers and understanding of the
way header fields change packet-by-packet, and is hence incompatible way fields change between packets, and is hence incompatible with
with header encryption. Devices that compress transport headers are header encryption. Devices that compress transport headers are
dependent on a stable header format, implying ossification of that dependent on a stable header format, implying ossification of that
format. format.
Introducing a new transport protocol, or changing the format of the Introducing a new transport protocol, or changing the format of the
transport header information, will limit the effectiveness of header transport header information, will limit the effectiveness of header
compression until the network devices are updated. Encrypting the compression until the network devices are updated. Encrypting the
transport protocol headers will tend to cause the header compression transport protocol headers will tend to cause the header compression
to a fall back to compressing only the network layer headers, with a to a fall back to compressing only the network layer headers, with a
significant reduction in efficiency. This can limit connectivity if significant reduction in efficiency. This can limit connectivity if
the resulting flow exceeds the link capacity, or if the packets are the resulting flow exceeds the link capacity, or if the packets are
dropped because they exceed the link MTU. dropped because they exceed the link MTU.
The Secure RTP (SRTP) extensions [RFC3711] were explicitly designed The Secure RTP (SRTP) extensions [RFC3711] were explicitly designed
to leave the transport protocol headers unencrypted, but to leave the transport protocol headers unencrypted, but
authenticated, since support for header compression was considered authenticated, since support for header compression was considered
important. important.
2.6. To Verify SLA Compliance 2.5. To Verify SLA Compliance
Observable transport headers coupled with published transport Observable transport headers coupled with published transport
specifications allow operators and regulators to explore and verify specifications allow operators and regulators to explore and verify
compliance with Service Level Agreements (SLAs). compliance with Service Level Agreements (SLAs). It can also be used
to understand whether a service is providing differential treatment
to certain flows.
When transport header information cannot be observed, other methods When transport header information cannot be observed, other methods
have to be found to confirm that the traffic produced conforms to the have to be found to confirm that the traffic produced conforms to the
expectations of the operator or developer. expectations of the operator or developer.
Independently verifiable performance metrics can be utilised to Independently verifiable performance metrics can be utilised to
demonstrate regulatory compliance in some jurisdictions, and as a demonstrate regulatory compliance in some jurisdictions, and as a
basis for informing design decisions. This can bring assurance to basis for informing design decisions. This can bring assurance to
those operating networks, often avoiding deployment of complex those operating networks, often avoiding deployment of complex
techniques that routinely monitor and manage Internet traffic flows techniques that routinely monitor and manage Internet traffic flows
(e.g., avoiding the capital and operational costs of deploying flow (e.g., avoiding the capital and operational costs of deploying flow
rate-limiting and network circuit-breaker methods [RFC8084]). rate-limiting and network circuit-breaker methods [RFC8084]).
3. Other Uses of Observable Transport Headers 3. Research, Development and Deployment
The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to
expose only what is needed [RFC3552]. This approach provides
incentives to not reveal any information that is not necessary for
the end-to-end communication. The IAB has provided guidelines for
writing Security Considerations for IETF specifications [RFC3552].
Endpoint design choices impacting privacy also need to be considered Independently observed data is important to ensure the health of the
as a part of the design process [RFC6973]. The IAB has provided research and development communities and provides data need to
guidance for analyzing and documenting privacy considerations within evaluate new proposals for standardisation. Data can also help
IETF specifications [RFC6973]. promote acceptance of proposed specifications by the wider community
(e.g., as a method to judge the safety for Internet deployment).
Open standards motivate a desire to include independent observation
and evaluation of performance data, which in turn demands control/
understanding about where and when measurement samples are collected.
This requires consideration of the methods used to observe
information and the appropriate balance between encrypting all and no
transport header information.
There can also be performance and operational trade-offs in exposing There can be performance and operational trade-offs in exposing
selected information to network tools. This section explores key selected information to network tools. This section explores key
implications of working with encrypted transport protocols, but does implications of tool and procedures that observe transport protocols,
not endorse or condemn these practices. but does not endorse or condemn any specific practices.
3.1. Characterising "Unknown" Network Traffic
The patterns and types of traffic that share Internet capacity change
over time as networked applications, usage patterns and protocols
continue to evolve.
If "unknown" or "uncharacterised" traffic patterns form a small part
of the traffic aggregate passing through a network device or segment
of the network the path, the dynamics of the uncharacterised traffic
might not have a significant collateral impact on the performance of
other traffic that shares this network segment. Once the proportion
of this traffic increases, monitoring the traffic can determine if
appropriate safety measures have to be put in place.
Tracking the impact of new mechanisms and protocols requires traffic
volume to be measured and new transport behaviours to be identified.
This is especially true of protocols operating over a UDP substrate.
The level and style of encryption has to be considered in determining
how this activity is performed. On a shorter timescale, information
could also have to be collected to manage DoS attacks against the
infrastructure.
3.2. Accountability and Internet Transport Protocols
Information provided by tools observing transport headers can be used
to classify traffic, and to limit the network capacity used by
certain flows, as discussed in Section 2.3.4). Equally, operators
could use analysis of transport headers and transport flow state to
demonstrate that they are not providing differential treatment to
certain flows. Obfuscating or hiding this information using
encryption could lead operators and maintainers of middleboxes
(firewalls, etc.) to seek other methods to classify, and potentially
other mechanisms to condition network traffic.
A lack of data that reduces the level of precision with which flows
can be classified also reduces the design space for conditioning
mechanisms (e.g., rate limiting, circuit breaker techniques
[RFC8084], or blocking of uncharacterised traffic) [RFC5218].
3.3. Impact on Tooling and Network Operations
A variety and open source and proprietary tools have been deployed to
can make use of the transport header information that's observable in
widely used protocols such as TCP or RTP/UDP/IP.
Changes to the transport, whether to protect the transport headers,
introduce a new transport protocol, protocol feature, or application
might require changes to such tools, and so could impact operational
practice and policies. Such changes have associated costs that are
incurred by the network operators that need to update their tooling
or develop alternative practises that work without access to the
changed/removed information.
If new protocols, or protocol extensions, are made to closely
resemble or match existing mechanisms, then these changes and the
associated costs can be small. Equally, more extensive changes to
the transport tend to require more extensive, and more expensive,
changes to tooling and operational practice.
Protocol designers can mitigate these costs by explicitly choosing to
expose selected information as invariants that are guaranteed not to
change for a particular protocol (e.g., the header invariants and the
spin-bit in QUIC [I-D.ietf-quic-transport]). Specification of common
log formats and development of alternative approaches can also help
mitigate the costs of transport changes.
3.4. Independent Measurement
Independent observation by multiple actors is currently used by the
transport community to maintain an accurate understanding of the
network. Encrypting transport header encryption changes the ability
to collect and independently analyse data.
Protocols that expose the state information used by the transport
protocol in their header information (e.g., timestamps used to
calculate the RTT, packet numbers used to assess congestion and
requests for retransmission) provide an incentive for the sending
endpoint to provide correct information, since the protocol will not
work otherwise. This increases confidence that the observer
understands the transport interaction with the network. For example,
when TCP is used over an unencrypted network path (i.e., one that
does not use IPsec or other encryption below the transport), it
implicitly exposes transport header information that can be used for
measurement at any point along the path. This information is
necessary for the protocol's correct operation, therefore there is no
incentive for a TCP or RTP implementation to put incorrect
information in this transport header. A network device can have
confidence that the well-known (and ossified) transport header
information represents the actual state of the endpoints.
When encryption is used to hide some or all of the transport headers,
the transport protocol chooses which information to reveal to the
network about its internal state, what information to leave
encrypted, and what fields to grease to protect against future
ossification [RFC8701]. Such a transport could provide summary data
regarding its performance, congestion control state, etc., or to make
available explicit measurement information. For example, a QUIC
endpoint can optionally set the spin bit to reflect to explicitly
reveal the RTT of an encrypted transport session to the on-path
network devices [I-D.ietf-quic-transport]).
When providing or using such information, it is important to consider 3.1. Independent Measurement
the privacy of the user and their incentive for providing accurate
and detailed information. Protocols that selectively reveal some
transport state or measurable information are choosing to establish a
trust relationship with the network operators. There is no protocol
mechanism that can guarantee that the information provided represents
the actual transport state of the endpoints, since those endpoints
can always send additional information in the encrypted part of the
header, to update or replace whatever they reveal. This reduces the
ability to independently measure and verify that a protocol is
behaving as expected. For some operational uses, the information has
to contain sufficient detail to understand, and possibly reconstruct,
the network traffic pattern for further testing. In this case,
operators have to gain the trust of transport protocol implementers
if the transport headers are to correctly reveal such information.
OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a Encrypting transport header information has implications on the way
variety of encapsulation methods at different layers to support the network data is collected and analysed. Independent observation by
goals of a specific operational domain. OAM-related metadata can multiple actors is currently used by the transport community to
support functions such as performance evaluation, path-tracing, path maintain an accurate understanding of the network. When providing or
verification information, classification and a diversity of other using such information, it is important to consider the privacy of
uses. When encryption is used to hide some or all of the transport the user and their incentive for providing accurate and detailed
headers, analysis requires coordination between actors at different information.
layers to successfully characterise flows and correlate the
performance or behaviour of a specific mechanism with the
configuration and traffic using operational equipment (e.g.,
combining transport and network measurements to explore congestion
control dynamics, the implications of designs for active queue
management or circuit breakers).
Some measurements could be completed by utilising endpoint-based Protocols that expose the state of the transport protocol in their
logging (e.g., based on Quic-Trace [Quic-Trace]). Such information header (e.g., timestamps used to calculate the RTT, packet numbers
has a diversity of uses, including developers wishing to debug/ used to assess congestion and requests for retransmission) provide an
understand the transport/application protocols with which they work, incentive for a sending endpoint to provide consistent information,
researchers seeking to spot trends and anomalies, and to characterise because a protocol will not work otherwise. An in-network observer
variants of protocols. A standard format for endpoint logging could can have confidence that well-known (and ossified) transport header
allow these to be shared (after appropriate anonymisation) to information represents the actual state of the endpoints, when this
understand performance and pathologies. Measurements based on information is necessary for the protocol's correct operation.
logging have to establish the validity and provenance of the logged
information to establish how and when traces were captured.
Despite being applicable in some scenarios, endpoint logs do not Encryption of transport header information could reduce the range of
provide equivalent information to in-network measurements. In actors that can observe useful data. This would limit the
particular, endpoint logs contain only a part of the information to information sources available to the Internet community to understand
understand the operation of network devices and identify issues such the operation of new transport protocols, reducing information to
as link performance or capacity sharing between multiple flows. inform design decisions and standardisation of the new protocols and
Additional information has to be combined to determine which related operational practises. The cooperating dependence of
equipment/links are used and the configuration of equipment along the network, application, and host to provide communication performance
network paths being measured. on the Internet is uncertain when only endpoints (i.e., at user
devices and within service platforms) can observe performance, and
when performance cannot be independently verified by all parties.
3.5. Impact on Research, Development and Deployment 3.2. Measurable Transport Protocols
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. A transport protocol that provides observable headers can be hand. A transport protocol that provides observable headers can be
used to provide open and verifiable measurement data. Observation of used to provide open and verifiable measurement data. Observation of
pathologies has a critical role in the design of transport protocol pathologies has a critical role in the design of transport protocol
mechanisms and development of new mechanisms and protocols. This mechanisms and development of new mechanisms and protocols. This
helps understanding of the interactions between cooperating protocols helps understand the interactions between cooperating protocols and
and network mechanisms, the implications of sharing capacity with network mechanisms, the implications of sharing capacity with other
other traffic and the impact of different patterns of usage. The traffic and the impact of different patterns of usage. The ability
ability of other stakeholders to review transport header traces helps of other stakeholders to review transport header traces helps develop
develop insight into performance and traffic contribution of specific insight into performance and traffic contribution of specific
variants of a protocol. 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.
Encryption enables a transport protocol to choose which internal
state to reveal to the network, what information to encrypt, and what
fields to grease [RFC8701]. A new design can provide summary
information regarding its performance, congestion control state,
etc., or to make available explicit measurement information. For
example, [I-D.ietf-quic-transport] specifies a way for a QUIC
endpoint to optionally set the spin-bit to reflect to explicitly
reveal the RTT of an encrypted transport session to the on-path
network devices. There is a choice of what information to expose.
For some operational uses, the information has to contain sufficient
detail to understand, and possibly reconstruct, the network traffic
pattern for further testing. The interpretation of the information
needs to consider whether this information reflects the actual
transport state of the endpoints. This might require the trust of
transport protocol implementers, to correctly reveal the desired
information.
New transport protocol formats are expected to facilitate an New transport protocol formats are expected to facilitate an
increased pace of transport evolution, and with it the possibility to increased pace of transport evolution, and with it the possibility to
experiment with and deploy a wide range of protocol mechanisms. experiment with and deploy a wide range of protocol mechanisms. At
There has been recent interest in a wide range of new transport the time of writing, there has been interest in a wide range of new
methods, e.g., Larger Initial Window, Proportional Rate Reduction transport methods, e.g., Larger Initial Window, Proportional Rate
(PRR), congestion control methods based on measuring bottleneck Reduction (PRR), congestion control methods based on measuring
bandwidth and round-trip propagation time, the introduction of AQM bottleneck bandwidth and round-trip propagation time, the
techniques and new forms of ECN response (e.g., Data Centre TCP, introduction of AQM techniques and new forms of ECN response (e.g.,
DCTP, and methods proposed for L4S). The growth and diversity of Data Centre TCP, DCTP, and methods proposed for L4S). The growth and
applications and protocols using the Internet also continues to diversity of applications and protocols using the Internet also
expand. For each new method or application, it is desirable to build continues to expand. For each new method or application, it is
a body of data reflecting its behaviour under a wide range of desirable to build a body of data reflecting its behaviour under a
deployment scenarios, traffic load, and interactions with other wide range of deployment scenarios, traffic load, and interactions
deployed/candidate methods. with other deployed/candidate methods.
Encryption of transport header information could reduce the range of 3.3. Other Sources of Information
actors that can observe useful data. This would limit the
information sources available to the Internet community to understand
the operation of new transport protocols, reducing information to
inform design decisions and standardisation of the new protocols and
related operational practises. The cooperating dependence of
network, application, and host to provide communication performance
on the Internet is uncertain when only endpoints (i.e., at user
devices and within service platforms) can observe performance, and
when performance cannot be independently verified by all parties.
Independently observed data is also important to ensure the health of Some measurements that traditionally rely on observable transport
the research and development communities and can help promote information could be completed by utilising endpoint-based logging
acceptance of proposed specifications by the wider community (e.g., (e.g., based on Quic-Trace [Quic-Trace]). Such information has a
as a method to judge the safety for Internet deployment) and provides diversity of uses, including developers wishing to debug/understand
valuable input during standardisation. Open standards motivate a the transport/application protocols with which they work, researchers
desire to include independent observation and evaluation of seeking to spot trends and anomalies, and to characterise variants of
performance data, which in turn demands control/understanding about protocols. A standard format for endpoint logging could allow these
where and when measurement samples are collected. This requires to be shared (after appropriate anonymisation) to understand
consideration of the methods used to observe data and the appropriate performance and pathologies.
balance between encrypting all and no transport header information.
4. Encryption and Authentication of Transport Headers When measurement datasets are made available by servers or client
endpoints, additional metadata, such as the state of the network and
conditions in which the system was observed, is often necessary to
interpret this data to answer questions about network performance or
understand a pathology. Collecting and coordinating such metadata is
more difficult when the observation point is at a different location
to the bottleneck or device under evaluation [RFC7799].
End-to-end encryption can be applied at various protocol layers. It Despite being applicable in some scenarios, endpoint logs do not
can be applied above the transport to encrypt the transport payload provide equivalent information to in-network measurements. In
(e.g., using TLS). This can hide information from an eavesdropper in particular, endpoint logs contain only a part of the information to
the network. It can also help protect the privacy of a user, by understand the operation of network devices and identify issues such
hiding data relating to user/device identity or location. Encryption as link performance or capacity sharing between multiple flows. An
and authentication is also increasingly used to protect the transport analysis can require coordination between actors at different layers
headers. to successfully characterise flows and correlate the performance or
behaviour of a specific mechanism with an equipment configuration and
traffic using operational equipment along a network path (e.g.,
combining transport and network measurements to explore congestion
control dynamics, to understand the implications of traffic on
designs for active queue management or circuit breakers).
4.1. Motivation Another source of information could arise from operations,
administration and management (OAM) (see Section 6) information data
records [I-D.ietf-ippm-ioam-data] that could be embedded into header
information at different layers to support functions such as
performance evaluation, path-tracing, path verification information,
classification and a diversity of other uses.
4. Encryption and Authentication of Transport Headers
There are several motivations for transport header encryption. There are several motivations for transport header encryption.
One motive to encrypt transport headers is to prevent network One motive to encrypt transport headers is to prevent network
ossification from network devices that inspect transport headers. ossification from network devices that inspect well-known transport
Once a network device observes a transport header and becomes reliant headers. Once a network device observes a transport header and
upon using it, the overall use of that field can become ossified, becomes reliant upon using it, the overall use of that field can
preventing new protocols and mechanisms from being deployed. One of become ossified, preventing new versions of the protocol and
the benefits of encrypting transport headers is that it can help mechanisms from being deployed. Examples include:
improve the pace of transport development by eliminating interference
by deployed middleboxes. Examples of this include:
o During the development of TLS 1.3 [RFC8446], the design needed to o During the development of TLS 1.3 [RFC8446], the design needed to
be modified to function in the presence of deployed middleboxes function in the presence of deployed middleboxes that relied on
that relied on the presence of certain header fields exposed in the presence of certain header fields exposed in TLS 1.2
TLS 1.2 [RFC5426]. [RFC5426].
o The design of Multipath TCP (MPTCP) [RFC8684] also had to be o The design of Multipath TCP (MPTCP) [RFC8684] had to account for
revised to account for middleboxes (known as "TCP Normalizers") middleboxes (known as "TCP Normalizers") that monitor the
that monitor the evolution of the window advertised in the TCP evolution of the window advertised in the TCP header and then
header and then reset connections when the window did not grow as reset connections when the window did not grow as expected.
expected.
o TCP Fast Open [RFC7413] can experience problems due to middleboxes o TCP Fast Open [RFC7413] can experience problems due to middleboxes
that modify the transport header of packets by removing "unknown" that modify the transport header of packets by removing "unknown"
TCP options, segments with unrecognised TCP options can be 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 that send data dropped, or middleboxes that disrupt connections that send data
before completion of the three-way handshake. before completion of the three-way handshake.
o Other examples of ossification have included middleboxes that o Other examples of TCP ossification have included middleboxes that
modify transport headers by rewriting TCP sequence and modify transport headers by rewriting TCP sequence and
acknowledgement numbers, but are unaware of the (newer) TCP acknowledgement numbers, but are unaware of the (newer) TCP
selective acknowledgement (SACK) option and therefore fail to selective acknowledgement (SACK) option and therefore fail to
correctly rewrite the SACK information to match the changes that correctly rewrite the SACK information to match the changes made
were made to the fixed TCP header, preventing SACK from operating to the fixed TCP header, preventing correct SACK operation.
correctly.
In all these cases, middleboxes with a hard-coded, but incomplete, In all these cases, middleboxes with a hard-coded, but incomplete,
understanding of transport behaviour, interacted poorly with understanding of a specific transport behaviour (i.e., TCP),
transport protocols after the transport behaviour was changed. In interacted poorly with transport protocols after the transport
some case, the middleboxes modified or replaced information in the behaviour was changed. In some case, the middleboxes modified or
transport protocol header. replaced information in the transport protocol header.
Transport header encryption prevents an on-path device from observing Transport header encryption prevents an on-path device from observing
the transport headers, and therefore stops mechanisms being built the transport headers, and therefore stops ossified mechanisms being
that directly rely on or infer semantics of the transport header used that directly rely on or infer semantics of the transport header
information. Encryption is normally combined with authentication of information. This encryption is normally combined with
the protected information. RFC 8546 summarises this approach, authentication of the protected information. RFC 8546 summarises
stating that it is "The wire image, not the protocol's specification, this approach, stating that it is "The wire image, not the protocol's
determines how third parties on the network paths among protocol specification, determines how third parties on the network paths
participants will interact with that protocol" (Section 1 of among protocol participants will interact with that protocol"
[RFC8546]), and it can be expected that header information that is (Section 1 of [RFC8546]), and it can be expected that header
not encrypted will become ossified. Encryption can reduce information that is not encrypted will become ossified.
ossification of the transport protocol, but does not itself prevent
ossification of the network service. People seeking to understand
network traffic could still come to rely on pattern inferences and
other heuristics or machine learning to derive measurement data and
as the basis for network forwarding decisions [RFC8546]. This can
also create dependencies on the transport protocol, or the patterns
of traffic it can generate, also in time resulting in ossification of
the service.
Another motivation stems from increased concerns about privacy and Encryption does not itself prevent ossification of the network
surveillance. Users value the ability to protect their identity and service. People seeking to understand or classify network traffic
location, and defend against analysis of the traffic. Revelations could still come to rely on pattern inferences and other heuristics
about the use of pervasive surveillance [RFC7624] have, to some or machine learning to derive measurement data and as the basis for
extent, eroded trust in the service offered by network operators and network forwarding decisions [RFC8546]. This can also create
have led to an increased use of encryption to avoid unwanted dependencies on the transport protocol, or the patterns of traffic it
eavesdropping on communications. Concerns have also been voiced can generate, also resulting in ossification of the service.
about the addition of information to packets by third parties to
provide analytics, customisation, advertising, cross-site tracking of
users, to bill the customer, or to selectively allow or block
content. Whatever the reasons, the IETF is designing protocols that
include transport header encryption (e.g., QUIC
[I-D.ietf-quic-transport]) to supplement the already widespread
payload encryption, and to further limit exposure of transport
metadata to the network.
The use of transport header authentication and encryption exposes a Another motivation for using transport header encryption is to
tussle between middlebox vendors, operators, applications developers improve privacy and to decrease opportunities for surveillance.
and users: Users value the ability to protect their identity and location, and
defend against analysis of the traffic. Revelations about the use of
pervasive surveillance [RFC7624] have, to some extent, eroded trust
in the service offered by network operators and have led to an
increased use of encryption. Concerns have also been voiced about
the addition of metadata to packets by third parties to provide
analytics, customisation, advertising, cross-site tracking of users,
to bill the customer, or to selectively allow or block content.
Whatever the reasons, the IETF is designing protocols that include
transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to
supplement the already widespread payload encryption, and to further
limit exposure of transport metadata to the network.
If a transport protocol uses header encryption, the designers have to
decide whether to encrypt all, or a part of, the transport layer
information. Section 4 of [RFC8558] states: "Anything exposed to the
path should be done with the intent that it be used by the network
elements on the path". Certain transport header fields can be made
observable in the network, or can define new fields designed to
explicitly expose observable transport layer information to the
network. Where exposed fields are intended to be immutable (i.e.,
can be observed, but not modified by a network device), the endpoints
are encouraged to use authentication to provide a cryptographic
integrity check that can detect if these immutable fields have been
modified by network devices. Authentication can help to prevent
attacks that rely on sending packets that fake exposed control
signals in transport headers (e.g., TCP RST spoofing). Making a part
of a transport header observable or exposing new header fields can
lead to ossification of that part of a header as network devices come
to rely on observations of the exposed fields.
The use of transport header authentication and encryption therefore
exposes a tussle between middlebox vendors, operators, applications
developers 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.
o On the other hand, encryption of transport layer information has o On the other hand, encryption of transport layer information has
implications for people who are responsible for operating implications for people who are responsible for operating
networks, and researchers and analysts seeking to understand the networks, and researchers and analysts seeking to understand the
dynamics of protocols and traffic patterns. dynamics of protocols and traffic patterns.
A decision to use transport header encryption can improve user
privacy, and can reduce protocol ossification and help the evolution
of the transport protocol stack, but is also has implications for
network operations and management.
4.2. Approaches to Transport Header Protection
The designers of a transport protocol have to decide whether to
encrypt all, or a part of, the transport layer information.
Section 4 of [RFC8558] states: "Anything exposed to the path should
be done with the intent that it be used by the network elements on
the path".
Protocol designers can decide not to encrypt certain transport header
fields, making those fields observable in the network, or can define
new fields designed to explicitly expose observable transport layer
information to the network. Where exposed fields are intended to be
immutable (i.e., can be observed, but not modified by a network
device), the endpoints are encouraged to use authentication to
provide a cryptographic integrity check that can detect if these
immutable fields have been modified by network devices.
Authentication can also help to prevent attacks that rely on sending
packets that fake exposed control signals in transport headers (e.g.,
TCP RST spoofing). Making a part of a transport header observable or
exposing new header fields can lead to ossification of that part of a
header as network devices come to rely on observations of the exposed
fields.
The following briefly reviews some security design options for The following briefly reviews some security design options for
transport protocols. A Survey of the Interaction between Security transport protocols. A Survey of the Interaction between Security
Protocols and Transport Services [RFC8922] provides more details Protocols and Transport Services [RFC8922] provides more details
concerning commonly used encryption methods at the transport layer. concerning commonly used encryption methods at the transport layer.
Security work typically employs a design technique that seeks to
expose only what is needed [RFC3552]. This approach provides
incentives to not reveal any information that is not necessary for
the end-to-end communication. The IAB has provided guidelines for
writing Security Considerations for IETF specifications [RFC3552].
Endpoint design choices impacting privacy also need to be considered
as a part of the design process [RFC6973]. The IAB has provided
guidance for analyzing and documenting privacy considerations within
IETF specifications [RFC6973].
Authenticating the Transport Protocol Header: Transport layer header Authenticating the Transport Protocol Header: Transport layer header
information can be authenticated. An integrity check that information can be authenticated. An integrity check that
protects the immutable transport header fields, but can still protects the immutable transport header fields, but can still
expose the transport protocol header information in the clear, expose the transport header information in the clear, allows in-
allows in-network devices to observe these fields. An integrity network devices to observe these fields. An integrity check is
check is not able to prevent in-network modification, but can not able to prevent in-network modification, but can prevent a
prevent a receiving endpoint from accepting changes and avoid receiving endpoint from accepting changes and avoid impact on the
impact on the transport protocol operation, including some types transport protocol operation, including some types of attack.
of attack.
An example transport authentication mechanism is TCP- An example transport authentication mechanism is TCP-
Authentication (TCP-AO) [RFC5925]. This TCP option authenticates Authentication (TCP-AO) [RFC5925]. This TCP option authenticates
the IP pseudo header, TCP header, and TCP data. TCP-AO protects the IP pseudo header, TCP header, and TCP data. TCP-AO protects
the transport layer, preventing attacks from disabling the TCP the transport layer, preventing attacks from disabling the TCP
connection itself and provides replay protection. Such connection itself and provides replay protection. Such
authentication might interact with middleboxes, depending on their authentication might interact with middleboxes, depending on their
behaviour [RFC3234]. behaviour [RFC3234].
The IPsec Authentication Header (AH) [RFC4302] was designed to The IPsec Authentication Header (AH) [RFC4302] was designed to
work at the network layer and authenticate the IP payload. This work at the network layer and authenticate the IP payload. This
approach authenticates all transport headers, and verifies their approach authenticates all transport headers, and verifies their
integrity at the receiver, preventing in-network modification. integrity at the receiver, preventing in-network modification.
The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also
provide authentication and integrity without confidentiality using provide authentication and integrity without confidentiality using
the NULL encryption algorithm [RFC2410]. SRTP [RFC3711] is the NULL encryption algorithm [RFC2410]. SRTP [RFC3711] is
another example of a transport protocol that allows header another example of a transport protocol that allows header
authentication. authentication.
Selectively Encrypting Transport Headers and Payload: A transport Selectively Encrypting Transport Headers and Payload: A transport
protocol design can encrypt selected header fields, while also protocol design that encrypts selected header fields, allows
choosing to authenticate the entire transport header. This allows
specific transport header fields to be made observable by network specific transport header fields to be made observable by network
devices (explicitly exposed either in a transport header field or devices. This information is explicitly exposed either in a
lower layer protocol header). A design that only exposes transport header field or lower layer protocol header. A design
immutable fields can also perform end-to-end authentication of that only exposes immutable fields can also perform end-to-end
these fields across the path to prevent undetected modification of authentication of these fields across the path to prevent
the immutable transport headers. undetected modification of the immutable transport headers.
Mutable fields in the transport header provide opportunities where Mutable fields in the transport header provide opportunities where
network devices can modify the transport behaviour (e.g., the network devices can modify the transport behaviour (e.g., the
extended headers described in [I-D.trammell-plus-abstract-mech]). extended headers described in [I-D.trammell-plus-abstract-mech]).
An example of a method that encrypts some, but not all, transport An example of a method that encrypts some, but not all, transport
header information is GRE-in-UDP [RFC8086] when used with GRE header information is GRE-in-UDP [RFC8086] when used with GRE
encryption. encryption.
Optional Encryption of Header Information: There are implications to Optional Encryption of Header Information: There are implications to
the use of optional header encryption in the design of a transport the use of optional header encryption in the design of a transport
protocol, where support of optional mechanisms can increase the protocol, where support of optional mechanisms can increase the
complexity of the protocol and its implementation, and in the complexity of the protocol and its implementation, and in the
management decisions that are have to be made to use variable management decisions that are have to be made to use variable
format fields. Instead, fields of a specific type ought to always format fields. Instead, fields of a specific type ought to always
skipping to change at page 28, line 8 skipping to change at page 25, line 34
fields or values for use by future versions of a specification. fields or values for use by future versions of a specification.
The specification of receivers has traditionally ignored The specification of receivers has traditionally ignored
unspecified values, however in-network devices have emerged that unspecified values, however in-network devices have emerged that
ossify to require a certain value in a field, or re-use a field ossify to require a certain value in a field, or re-use a field
for another purpose. When the specification is later updated, it for another purpose. When the specification is later updated, it
is impossible to deploy the new use of the field, and forwarding is impossible to deploy the new use of the field, and forwarding
of the protocol could even become conditional on a specific header of the protocol could even become conditional on a specific header
field value. field value.
A protocol can intentionally vary the value, format, and/or A protocol can intentionally vary the value, format, and/or
presence of observable transport header fields. This behaviour, presence of observable transport header fields [RFC8701]. This
known as GREASE (Generate Random Extensions And Sustain prevents a network device ossifying the use of a specific
Extensibility) is designed to avoid a network device ossifying the observable field and can ease future deployment of new uses of the
use of a specific observable field. Greasing seeks to ease value or codepoint. This is not a security mechanism, although
deployment of new methods. This seeks to prevent in-network the use can be combined with an authentication mechanism.
devices utilising the information in a transport header, or can
make an observation robust to a set of changing values, rather
than a specific set of values. It is not a security mechanism,
although use can be combined with an authentication mechanism.
As seen, different transports use encryption to protect their header Different transports use encryption to protect their header
information to varying degrees. The trend is towards increased information to varying degrees. The trend is towards increased
protection. protection.
5. Intentionally Exposing Transport Information to the Network 5. Intentionally Exposing Transport Information to the Network
A transport protocol can choose to expose certain transport A transport protocol can choose to expose certain transport
information to on-path devices operating at the network layer by information to on-path devices operating at the network layer by
sending observable fields. One approach is to make an explicit sending observable fields. One approach is to make an explicit
choice not to encrypt certain transport header fields, making this choice not to encrypt certain transport header fields, making this
transport information observable by the network. Another approach is transport information observable by the network. Another approach is
to choose to expose transport information through the use of network- to expose transport information in a network-layer extension header
layer extension headers (see Section 6). Both are examples of (see Section 5.1). Both are examples of explicit information
explicit information intended to be used by network devices on the intended to be used by network devices on the path [RFC8558].
path [RFC8558].
Whatever the mechanism used to expose the information, a decision to Whatever the mechanism used to expose the information, a decision to
only expose specific transport information, places the transport expose only specific information, places the transport endpoint in
endpoint in control of what to expose or not to expose outside of the control of what to expose outside of the encrypted transport header.
encrypted transport header. This decision can then be made This decision can then be made independently of the transport
independently of the transport protocol functionality. This can be protocol functionality. This can be done by exposing part of the
done by exposing part of the transport header or as a network layer transport header or as a network layer option/extension.
option/extension.
5.1. Exposing Transport Information in Extension Headers 5.1. Exposing Transport Information in Extension Headers
At the network-layer, packets can carry optional headers (similar to At the network-layer, packets can carry optional headers that
Section 6) that may be used to explicitly expose transport header explicitly expose transport header information to the on-path devices
information to the on-path devices operating at the network layer operating at the network layer (Section 2.2.2). For example, an
(Section 2.2.2). For example, an endpoint that sends an IPv6 Hop-by- endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide
Hop option [RFC8200] can provide explicit transport layer information explicit transport layer information that can be observed and used by
that can be observed and used by network devices on the path. network devices on the path.
Network-layer optional headers explicitly indicate the information Network-layer optional headers explicitly indicate the information
that is exposed, whereas use of exposed transport header information that is exposed, whereas use of exposed transport header information
first requires an observer to identify the transport protocol and its first requires an observer to identify the transport protocol and its
format. See Section 2.1 for further discussion of transport protocol format. (See Section 2.1.)
identification.
An arbitrary path can include one or more network devices that drop An arbitrary path can include one or more network devices that drop
packets that include a specific header or option used for this packets that include a specific header or option used for this
purpose (see [RFC7872]). This could impact the proper functioning of purpose (see [RFC7872]). This could impact the proper functioning of
the protocols using the path. Protocol methods can be designed to the protocols using the path. Protocol methods can be designed to
probe to discover whether the specific option(s) can be used along probe to discover whether the specific option(s) can be used along
the current path, enabling use on arbitrary paths. the current path, enabling use on arbitrary paths.
5.2. Common Exposed Transport Information 5.2. Common Exposed Transport Information
skipping to change at page 30, line 50 skipping to change at page 28, line 20
extension header or an IPv4 option. This information can be used extension header or an IPv4 option. This information can be used
across multiple network segments, or between the transport endpoints. across multiple network segments, or between the transport endpoints.
One example is the IPv6 Performance and Diagnostic Metrics (PDM) One example is the IPv6 Performance and Diagnostic Metrics (PDM)
destination option [RFC8250]. This allows a sender to optionally destination option [RFC8250]. This allows a sender to optionally
include a destination option that caries header fields that can be include a destination option that caries header fields that can be
used to observe timestamps and packet sequence numbers. This used to observe timestamps and packet sequence numbers. This
information could be authenticated by receiving transport endpoints information could be authenticated by receiving transport endpoints
when the information is added at the sender and visible at the when the information is added at the sender and visible at the
receiving endpoint, although methods to do this have not currently receiving endpoint, although methods to do this have not currently
been proposed. This method has to be explicitly enabled at the been proposed. This need to be explicitly enabled at the sender.
sender.
7. Conclusions 7. Conclusions
Header encryption and strong integrity checks are being incorporated Header encryption and strong integrity checks are being incorporated
into new transport protocols and have important benefits. The pace into new transport protocols and have important benefits. The pace
of development of transports using the WebRTC data channel, and the of development of transports using the WebRTC data channel, and the
rapid deployment of the QUIC transport protocol, can both be rapid deployment of the QUIC transport protocol, can both be
attributed to using the combination of UDP as a substrate while attributed to using the combination of UDP as a substrate while
providing confidentiality and authentication of the encapsulated providing confidentiality and authentication of the encapsulated
transport headers and payload. transport headers and payload.
skipping to change at page 31, line 28 skipping to change at page 28, line 45
necessary, or endorse the use of any specific practise. Rather, the necessary, or endorse the use of any specific practise. Rather, the
intent is to highlight operational tools and practises to consider intent is to highlight operational tools and practises to consider
when designing and modifying transport protocols, so protocol when designing and modifying transport protocols, so protocol
designers can make informed choice about what transport header fields designers can make informed choice about what transport header fields
to encrypt, and whether it might be beneficial to make an explicit to encrypt, and whether it might be beneficial to make an explicit
choice to expose certain fields to the network. In making such a choice to expose certain fields to the network. In making such a
decision, it is important to balance: decision, it is important to balance:
o User Privacy: The less transport header information that is o User Privacy: The less transport header information that is
exposed to the network, the lower the risk of leaking metadata exposed to the network, the lower the risk of leaking metadata
that might have privacy implications for the users. Transports that might have user privacy implications. Transports that chose
that chose to expose some header fields need to make a privacy to expose some header fields need to make a privacy assessment to
assessment to understand the privacy cost versus benefit trade-off understand the privacy cost versus benefit trade-off in making
in making that information available. The process used to define that information available. The design of the QUIC spin bit to
and expose the QUIC spin bit to the network is an example of such the network is an example considered such analysis.
an analysis.
o Transport Ossification: Unencrypted transport header fields are o Transport Ossification: Unencrypted transport header fields are
likely to ossify rapidly, as network devices come to rely on their likely to ossify rapidly, as network devices come to rely on their
presence, making it difficult to change the transport in future. presence, making it difficult to change the transport in future.
This argues that the choice to expose information to the network This argues that the choice to expose information to the network
is made deliberately and with care, since it is essentially is made deliberately and with care, since it is essentially
defining a stable interface between the transport and the network. defining a stable interface between the transport and the network.
Some protocols will want to make that interface as limited as Some protocols will want to make that interface as limited as
possible; other protocols might find value in exposing certain possible; other protocols might find value in exposing certain
information to signal to the network, or in allowing the network information to signal to the network, or in allowing the network
to change certain header fields as signals to the transport. The to change certain header fields as signals to the transport. The
visible wire image of a protocol should be explicitly designed. visible wire image of a protocol should be explicitly designed.
o Network Ossification: While encryption can reduce ossification of o Network Ossification: While encryption can reduce ossification of
the transport protocol, it does not itself prevent ossification of the transport protocol, it does not itself prevent ossification of
the network service. People seeking to understand network traffic the network service. People seeking to understand network traffic
could still come to rely on pattern inferences and other could still come to rely on pattern inferences and other
heuristics or machine learning to derive measurement data and as heuristics or machine learning to derive measurement data and as
the basis for network forwarding decisions [RFC8546]. This can the basis for network forwarding decisions [RFC8546]. This
also create dependencies on the transport protocol, or the creates dependencies on the transport protocol, or the patterns of
patterns of traffic it can generate, also in time resulting in traffic it can generate, resulting in ossification of the service.
ossification of the service.
o Impact on Operational Practice: The network operations community o Impact on Operational Practice: The network operations community
has long relied on being able to understand Internet traffic has long relied on being able to understand Internet traffic
patterns, both in aggregate and at the flow level, to support patterns, both in aggregate and at the flow level, to support
network management, traffic engineering, and troubleshooting. network management, traffic engineering, and troubleshooting.
Operational practice has developed based on the information Operational practice has developed based on the information
available from unencrypted transport headers. The IETF has available from unencrypted transport headers. The IETF has
supported this practice by developing operations and management supported this practice by developing operations and management
specifications, interface specifications, and associated Best specifications, interface specifications, and associated Best
Current Practises. Widespread deployment of transport protocols Current Practises. Widespread deployment of transport protocols
skipping to change at page 33, line 4 skipping to change at page 30, line 21
different parts of the network. The social contract that different parts of the network. The social contract that
maintains the stability of the Internet relies on accepting common maintains the stability of the Internet relies on accepting common
interworking specifications, and on it being possible to detect interworking specifications, and on it being possible to detect
violations. It is important to find new ways of maintaining that violations. It is important to find new ways of maintaining that
community trust as increased use of transport header encryption community trust as increased use of transport header encryption
limits visibility into transport behaviour. limits visibility into transport behaviour.
o Impact on Benchmarking and Understanding Feature Interactions: An o Impact on Benchmarking and Understanding Feature Interactions: An
appropriate vantage point for observation, coupled with timing appropriate vantage point for observation, coupled with timing
information about traffic flows, provides a valuable tool for information about traffic flows, provides a valuable tool for
benchmarking network devices, endpoint stacks, functions, and/or benchmarking network devices, endpoint stacks, and/or
configurations. This can also help with understanding complex configurations. This can help understand complex feature
feature interactions. An inability to observe transport header interactions. An inability to observe transport header
information can make it harder to diagnose and explore information can make it harder to diagnose and explore
interactions between features at different protocol layers, a interactions between features at different protocol layers, a
side-effect of not allowing a choice of vantage point from which side-effect of not allowing a choice of vantage point from which
this information is observed. New approaches might have to be this information is observed. New approaches might have to be
developed. developed.
o Impact on Research and Development: Hiding transport header o Impact on Research and Development: Hiding transport header
information can impede independent research into new mechanisms, information can impede independent research into new mechanisms,
measurement of behaviour, and development initiatives. Experience measurement of behaviour, and development initiatives. Experience
shows that transport protocols are complicated to design and shows that transport protocols are complicated to design and
skipping to change at page 35, line 47 skipping to change at page 33, line 13
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 cannot be predicted (see Section 5.1 [RFC6056], or a port value that cannot 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 is attempted before a receiver discards an injected
injected packets. packet.
Open standards motivate a desire for this evaluation to include Open standards motivate a desire for this evaluation to include
independent observation and evaluation of performance data, which in independent observation and evaluation of performance data, which in
turn suggests control over where and when measurement samples are turn suggests control over where and when measurement samples are
collected. This requires consideration of the appropriate balance collected. This requires consideration of the appropriate balance
between encrypting all and no transport header information. Open between encrypting all and no transport header information. Open
data, and accessibility to tools that can help understand trends in data, and accessibility to tools that can help understand trends in
application deployment, network traffic and usage patterns can all application deployment, network traffic and usage patterns can all
contribute to understanding security challenges. contribute to understanding security challenges.
skipping to change at page 38, line 37 skipping to change at page 36, line 5
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999, DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>. <https://www.rfc-editor.org/info/rfc2508>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<https://www.rfc-editor.org/info/rfc3234>. <https://www.rfc-editor.org/info/rfc3234>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
skipping to change at page 47, line 30 skipping to change at page 44, line 30
and M. Duke. Update to add reference to RFC7605. Clarify a focus and M. Duke. Update to add reference to RFC7605. Clarify a focus
on immutable transport fields, rather than modifying middleboxes with on immutable transport fields, rather than modifying middleboxes with
Tom H. Clarified Header Compression discussion only provides a list Tom H. Clarified Header Compression discussion only provides a list
of examples of HC methods for transport. Clarified port usage with of examples of HC methods for transport. Clarified port usage with
Tom H/Joe T. Removed some duplicated sentences, and minor edits. Tom H/Joe T. Removed some duplicated sentences, and minor edits.
Added NULL-ESP. Improved after initial feedback from Martin Duke. Added NULL-ESP. Improved after initial feedback from Martin Duke.
-16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3. -16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3.
-17 Revised to satisfy ID-NITs and updates REFs to latest rev, -17 Revised to satisfy ID-NITs and updates REFs to latest rev,
updated HC REFs; cited IAB guidance on security and privacy within updated HC Refs; cited IAB guidance on security and privacy within
IETF specs. IETF specs.
-18 Revised based on AD review. -18 Revised based on AD review.
-19 Revised after additional AD review request, and request to
restructure.
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. 102 change blocks. 
679 lines changed or deleted 540 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/