draft-ietf-tsvwg-transport-encrypt-20.txt | draft-ietf-tsvwg-transport-encrypt-21.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: September 9, 2021 University of Glasgow | Expires: October 20, 2021 University of Glasgow | |||
March 8, 2021 | April 18, 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-20 | draft-ietf-tsvwg-transport-encrypt-21 | |||
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 September 9, 2021. | This Internet-Draft will expire on October 20, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 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 Separate Flows in Network Devices . . . . . . . . . . 5 | |||
2.2. To Understand Transport Protocol Performance . . . . . . 6 | 2.2. To Identify Transport Protocols and Flows . . . . . . . . 5 | |||
2.3. To Support Network Operations . . . . . . . . . . . . . . 12 | 2.3. To Understand Transport Protocol Performance . . . . . . 6 | |||
2.4. To Support Header Compression . . . . . . . . . . . . . . 17 | 2.4. To Support Network Operations . . . . . . . . . . . . . . 13 | |||
2.5. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18 | 2.5. To Mitigate the Effects of Constrained Networks . . . . . 18 | |||
3. Research, Development and Deployment . . . . . . . . . . . . 18 | 2.6. To Verify SLA Compliance . . . . . . . . . . . . . . . . 19 | |||
3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19 | 3. Research, Development and Deployment . . . . . . . . . . . . 20 | |||
3.2. Measurable Transport Protocols . . . . . . . . . . . . . 19 | 3.1. Independent Measurement . . . . . . . . . . . . . . . . . 20 | |||
3.3. Other Sources of Information . . . . . . . . . . . . . . 21 | 3.2. Measurable Transport Protocols . . . . . . . . . . . . . 21 | |||
4. Encryption and Authentication of Transport Headers . . . . . 21 | 3.3. Other Sources of Information . . . . . . . . . . . . . . 22 | |||
5. Intentionally Exposing Transport Information to the Network . 26 | 4. Encryption and Authentication of Transport Headers . . . . . 23 | |||
5.1. Exposing Transport Information in Extension Headers . . . 26 | 5. Intentionally Exposing Transport Information to the Network . 28 | |||
5.2. Common Exposed Transport Information . . . . . . . . . . 27 | 5.1. Exposing Transport Information in Extension Headers . . . 28 | |||
5.3. Considerations for Exposing Transport Information . . . . 27 | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28 | 6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 30 | |||
6.2. Use of OAM across Multiple Maintenance Domains . . . . . 28 | 6.2. Use of OAM across Multiple Maintenance Domains . . . . . 30 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 34 | 11. Informative References . . . . . . . . . . . . . . . . . . . 36 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . 43 | Appendix A. Revision information . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
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 is 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. | |||
For some years, it has been common for the transport layer payload to | For some years, it has been common for the transport layer payload to | |||
be protected by encryption and authentication, but for the transport | be protected by encryption and authentication, but for the transport | |||
layer headers to be sent unprotected. Examples of protocols that | layer headers to be sent unprotected. Examples of protocols that | |||
behave in this manner include Transport Layer Security (TLS) over TCP | behave in this manner include Transport Layer Security (TLS) over TCP | |||
[RFC8446], Datagram TLS [RFC6347] [I-D.ietf-tls-dtls13], the Secure | [RFC8446], Datagram TLS [RFC6347] [I-D.ietf-tls-dtls13], the Secure | |||
Real-time Transport Protocol [RFC3711], and tcpcrypt [RFC8548]. The | Real-time Transport Protocol [RFC3711], and tcpcrypt [RFC8548]. The | |||
use of unencrypted transport headers has led some network operators, | use of unencrypted transport headers has led some network operators, | |||
researchers, and others to develop tools and processes that rely on | researchers, and others to develop tools and processes that rely on | |||
observations of transport headers both in aggregate and at the flow | observations of transport headers both in aggregate and at the flow | |||
level to infer details of the network's behaviour and inform | level to infer details of the network's behaviour and inform | |||
operational practice. | operational practice. | |||
Transport protocols are now being developed that encrypt some or all | Transport protocols are now being developed that encrypt some or all | |||
of the transport headers, in addition to the transport payload data. | of the transport headers, in addition to the transport payload data. | |||
The QUIC transport protocol [I-D.ietf-quic-transport] is an example | The QUIC transport protocol [I-D.ietf-quic-transport] is an example | |||
of such a protocol. Such transport header encryption makes it | of such a protocol. Such transport header encryption makes it | |||
difficult to observe transport protocol behaviour within the network. | difficult to observe transport protocol behaviour from the vantage | |||
This document discusses some implications of transport header | point of the network. This document discusses some implications of | |||
encryption for network operators, researchers, and others that have | transport header encryption for network operators and researchers | |||
previously observed transport headers, and highlights some issues to | that have previously observed transport headers, and highlights some | |||
consider for transport protocol designers. | issues to consider for transport protocol designers. | |||
As discussed in [RFC7258], the IETF has concluded that Pervasive | As discussed in [RFC7258], the IETF has concluded that Pervasive | |||
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. | |||
Current uses of transport header information in the network are | Current uses of transport header information by network devices on | |||
explained, which can be beneficial or malicious. This is written to | the Internet path are explained. These uses can be beneficial or | |||
provide input to the discussion around what is an appropriate | malicious. This is written to provide input to the discussion around | |||
balance, by highlighting some implications of transport header | what is an appropriate balance, by highlighting some implications of | |||
encryption. | transport header 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 or manipulation of | privacy, and can help to mitigate certain attacks or manipulation of | |||
packets in the network, but it can also affect network operations and | packets by devices on the network path, but it can also affect | |||
measurement [RFC8404]. | 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 network devices (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 | |||
and arrive at a different trade-off. | and arrive at a different trade-off. | |||
This section reviews examples of the observation of transport layer | This section reviews examples of the observation of transport layer | |||
headers within the network. Unencrypted transport headers provide | headers within the network by devices on the network path, or using | |||
information can support network operations and management, and this | information exported by an on-path device. Unencrypted transport | |||
section notes some ways in which this has been done. Unencrypted | headers provide information that can support network operations and | |||
transport header information also contributes metadata that can be | management, and this section notes some ways in which this has been | |||
exploited for purposes unrelated to network transport measurement, | done. Unencrypted transport header information also contributes | |||
diagnostics or troubleshooting (e.g., to block or to throttle traffic | metadata that can be exploited for purposes unrelated to network | |||
from a specific content provider), and this section also notes some | transport measurement, diagnostics or troubleshooting (e.g., to block | |||
threats relating to unencrypted transport headers. | or to throttle traffic from a specific content provider), and this | |||
section also notes some threats relating to unencrypted transport | ||||
headers. | ||||
Exposed transport information also provides a source of information | Exposed transport information also provides a source of information | |||
that contributes to linked data sets, which could be exploited to | that contributes to linked data sets, which could be exploited to | |||
deduce private information, e.g., user patterns, user location, | deduce private information, e.g., user patterns, user location, | |||
tracking behaviour, etc. This might reveal information the parties | tracking behaviour, etc. This might reveal information the parties | |||
did not intend to be revealed. [RFC6973] aims to make designers, | did not intend to be revealed. [RFC6973] aims to make designers, | |||
implementers, and users of Internet protocols aware of privacy- | implementers, and users of Internet protocols aware of privacy- | |||
related design choices in IETF protocols. | related design choices in IETF protocols. | |||
This section does not consider intentional modification of transport | This section does not consider intentional modification of transport | |||
headers by middleboxes, such as in Network Address Translation (NAT) | headers by middleboxes, such as devices performing Network Address | |||
or Firewalls. Common issues concerning IP address sharing are | Translation (NAT) or Firewalls. | |||
described in [RFC6269]. | ||||
2.1. To Identify Transport Protocols and Flows | 2.1. To Separate Flows in Network Devices | |||
Some network layer mechanisms separate network traffic by flow, | ||||
without resorting to identifying the type of traffic. Hash-based | ||||
load-sharing sharing across paths (e..g., equal cost multi path, | ||||
ECMP), sharing across a group of links (e.g., using a link | ||||
aggregation group, LAG), ensuring equal access to link capacity | ||||
(e.g., fair queuing, FQ), or distributing traffic to servers (e.g., | ||||
load balancing). To prevent packet reordering, forwarding engines | ||||
can consistently forward the same transport flows along the same | ||||
forwarding path, often achieved by calculating a hash using an | ||||
n-tuple gleaned from a combination of link header information through | ||||
to transport header information. This n-tuple can use the MAC | ||||
address, IP addresses, and can include observable transport header | ||||
information. | ||||
When transport header information cannot be observed, there can be | ||||
less information to separate flows at equipment along the path. Flow | ||||
separation might not be possible when, a transport that forms traffic | ||||
into an encrypted aggregate. For IPv6, the Flow Label [RFC6437] can | ||||
be used even when all transport information is encrypted, enabling | ||||
Flow Label-based ECMP [RFC6438] and Load-Sharing [RFC7098]. | ||||
2.2. 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, | |||
Quality of Service (QoS) classifiers, and firewalls. These functions | Quality of Service (QoS) classifiers, and firewalls. These functions | |||
can be beneficial, and performed with the consent of, and in support | can be beneficial, and performed with the consent of, and in support | |||
of, the end user. Alternatively, the same mechanisms could be used | of, the end user. Alternatively, the same mechanisms could be used | |||
to support practises that might be adversarial to the end user, | to support practises that might be adversarial to the end user, | |||
including blocking, de-prioritising, and monitoring traffic without | including blocking, de-prioritising, and monitoring traffic without | |||
consent. | 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 [RFC7414] and the Stream | |||
Transport Protocol (SCTP), specify a standard base header that | Control Transport Protocol (SCTP) [RFC4960], specify a standard base | |||
includes sequence number information and other data. They also have | header that includes sequence number information and other data. | |||
the possibility to negotiate additional headers at connection setup, | They also have the possibility to negotiate additional headers at | |||
identified by an option number in the transport header. | connection setup, 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 data (e.g., | Some flows can be identified by observing signalling data (e.g., | |||
[RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic | [RFC3261], [RFC8837]) or through the use of magic numbers placed in | |||
numbers placed in the first byte(s) of a datagram payload [RFC7983]. | the first byte(s) of a datagram payload [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, such as classification of | |||
that cannot access the Session Description Protocol (SDP) session | flows relying on timing, volumes of information, and correlation | |||
descriptions [RFC4566] to classify a flow as audio traffic, might | between multiple flows. For example, an operator that cannot access | |||
instead use (possibly less-reliable) heuristics to infer that short | the Session Description Protocol (SDP) session descriptions [RFC4566] | |||
UDP packets with regular spacing carry audio traffic. Operational | to classify a flow as audio traffic, might instead use (possibly | |||
practises aimed at inferring transport parameters are out of scope | less-reliable) heuristics to infer that short UDP packets with | |||
for this document, and are only mentioned here to recognise that | regular spacing carry audio traffic. Operational practises aimed at | |||
encryption does not prevent operators from attempting to apply | inferring transport parameters are out of scope for this document, | |||
practises that were used with unencrypted transport headers. | and are only mentioned here to recognise that encryption does not | |||
prevent operators from attempting to apply 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.3. To Understand Transport Protocol Performance | |||
This subsection describes use by the network of exposed transport | This subsection describes use by the network of exposed transport | |||
layer headers to understand transport protocol performance and | layer headers to understand transport protocol performance and | |||
behaviour. | behaviour. | |||
2.2.1. Using Information Derived from Transport Layer Headers | 2.3.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, and network anomalies at any point along the | of protocol performance, and detection of network anomalies at any | |||
Internet path. Some operators use passive monitoring to manage their | point along the Internet path. Some operators use passive monitoring | |||
portion of the Internet by characterising the performance of link/ | to manage their portion of the Internet by characterising the | |||
network segments. Inferences from transport headers are used to | performance of link/network segments. Inferences from transport | |||
derive performance metrics: | headers are used to derive performance metrics: | |||
Traffic Rate and Volume: Volume measures per-application can be used | Traffic Rate and Volume: Per-application traffic rate and volume | |||
to characterise the traffic that uses a network segment or the | measures can be used to characterise the traffic that uses a | |||
pattern of network usage. Observing the protocol sequence number | network segment or the pattern of network usage. Observing the | |||
and packet size offers one way to measure this (e.g., measurements | protocol sequence number and packet size offers one way to measure | |||
observing counters in periodic reports such as RTCP; or | this (e.g., measurements observing counters in periodic reports | |||
measurements observing protocol sequence numbers in statistical | such as RTCP; or measurements observing protocol sequence numbers | |||
samples of packet flows, or specific control packets, such as | in statistical samples of packet flows, or specific control | |||
those observed at the start and end of a flow). | packets, such as 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. | |||
These could be used to assess usage or for subscriber billing. | These could be used to assess usage or for subscriber billing. | |||
Such measurements can 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 could be used by the network to de- | quality of service; or could be used by the network to de- | |||
prioritise certain flows without user consent. | prioritise certain flows without user consent. | |||
skipping to change at page 7, line 15 ¶ | skipping to change at page 7, line 42 ¶ | |||
Network operators have used the variation in patterns to detect | Network operators have used the variation in patterns to detect | |||
changes in the offered service. Understanding the location and | changes in the offered service. Understanding the location and | |||
root cause of loss can help an operator determine whether this | root cause of loss can help an operator determine whether this | |||
requires corrective action. | 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 maintaining per-flow state (flow | |||
or transport headers, or maintaining per-flow packet counters | identification often requires transport layer information) and | |||
(flow identification often requires transport layer information). | either observing the increase in sequence numbers in the network | |||
Per-hop loss can also sometimes be monitored at the interface | or transport headers, or comparing a per-flow packet counter with | |||
level by devices in the network. | the number of packets that the flow actually sent. Per-hop loss | |||
can also sometimes be monitored at the interface level by devices | ||||
on the network path, or using in-situ methods operating over a | ||||
network segment (see Section 3.3). | ||||
The pattern of loss can provide insight into the cause of loss. | The pattern of loss can provide insight into the cause of loss. | |||
Losses can often occur as bursts, randomly-timed events, etc. 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. This 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. | flowing at a network node or segment at the time of loss. | |||
Transport header information can help identify cases where loss | Transport header information can help identify cases where loss | |||
could have been wrongly identified, or where the transport did not | could have been wrongly identified, or where the transport did not | |||
require transmission of a lost packet. | require retransmission 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 (the subset of | |||
[RFC7928]) is a measure of useful data exchanged (the ratio of | throughput consisting of useful traffic) (see Section 2.5 of | |||
useful data to total volume of traffic sent by a flow). The | [RFC7928] and [RFC5166]) is a measure of useful data exchanged. | |||
throughput of a flow can be determined in the absence of transport | The throughput of a flow can be determined in the absence of | |||
header information, providing that the individual flow can be | transport header information, providing that the individual flow | |||
identified, and the overhead known. Goodput requires ability to | can be identified, and the overhead known. Goodput requires | |||
differentiate loss and retransmission of packets, for example by | ability to differentiate loss and retransmission of packets, for | |||
observing packet sequence numbers in the TCP or RTP headers | example by observing packet sequence numbers in the TCP or RTP | |||
[RFC3550]. | headers [RFC3550]. | |||
Latency: Latency is a key performance metric that impacts | Latency: Latency is a key performance metric that impacts | |||
application and user-perceived response times. It often | application and user-perceived response times. It often | |||
indirectly impacts throughput and flow completion time. This | indirectly impacts throughput and flow completion time. This | |||
determines the reaction time of the transport protocol itself, | determines the reaction time of the transport protocol itself, | |||
impacting flow setup, congestion control, loss recovery, and other | impacting flow setup, congestion control, loss recovery, and other | |||
transport mechanisms. The observed latency can have many | transport mechanisms. The observed latency can have many | |||
components [Latency]. Of these, unnecessary/unwanted queueing in | components [Latency]. Of these, unnecessary/unwanted queueing in | |||
network buffers has often been observed as a significant factor | buffers of the network devices on the path has often been observed | |||
[bufferbloat]. Once the cause of unwanted latency has been | as a significant factor [bufferbloat]. Once the cause of unwanted | |||
identified, this can often be eliminated. | latency has been identified, this can often be eliminated. | |||
To measure latency across a part of a path, an observation point | To measure latency across a part of a path, an observation point | |||
[RFC7799] can measure the experienced round trip time (RTT) using | [RFC7799] can measure the experienced round trip time (RTT) using | |||
packet sequence numbers and acknowledgements, or by observing | packet sequence numbers and acknowledgements, or by observing | |||
header timestamp information. Such information allows an | header timestamp information. Such information allows an | |||
observation point in the network to determine not only the path | observation point on the network path to determine not only the | |||
RTT, but also allows measurement of the upstream and downstream | path RTT, but also allows measurement of the upstream and | |||
contribution to the RTT. This could be used to locate a source of | downstream contribution to the RTT. This could be used to locate | |||
latency, e.g., by observing cases where the median RTT is much | a source of latency, e.g., by observing cases where the median RTT | |||
greater than the minimum RTT for a part of a path. | is much greater than the minimum RTT for a part of a path. | |||
The service offered by network operators can benefit from latency | The service offered by network operators can benefit from latency | |||
information to understand the impact of configuration changes and | information to understand the impact of configuration changes and | |||
to tune deployed services. Latency metrics are key to evaluating | to tune deployed services. Latency metrics are key to evaluating | |||
and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | |||
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | |||
could identify excessively large buffers, indicating where to | could identify excessively large buffers, indicating where to | |||
deploy or configure AQM. An AQM method is often deployed in | deploy or configure AQM. An AQM method is often deployed in | |||
combination with other techniques, such as scheduling [RFC7567] | combination with other techniques, such as scheduling [RFC7567] | |||
[RFC8290] and although parameter-less methods are desired | [RFC8290] and although parameter-less methods are desired | |||
skipping to change at page 8, line 35 ¶ | skipping to change at page 9, line 16 ¶ | |||
[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]. | in [PAM-RTT]. | |||
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 a network path. For | |||
jitter metrics are often cited when characterising paths | example, 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 of 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. | |||
Flow Reordering: Significant packet reordering within a flow can | Flow Reordering: Significant packet reordering within a flow can | |||
impact time-critical applications and can be interpreted as loss | impact time-critical applications and can be interpreted as loss | |||
by reliable transports. Many transport protocol techniques are | by reliable transports. Many transport protocol techniques are | |||
impacted by reordering (e.g., triggering TCP retransmission or re- | impacted by reordering (e.g., triggering TCP retransmission or re- | |||
buffering of real-time applications). Packet reordering can occur | buffering of real-time applications). Packet reordering can occur | |||
for many reasons, from equipment design to misconfiguration of | for many reasons, from equipment design to misconfiguration of | |||
forwarding rules. Flow identification is often required to avoid | forwarding rules. Flow identification is often required to avoid | |||
significant packet mis-ordering (e.g., when ECMP is used). | significant packet mis-ordering (e.g., when using ECMP, or LAG). | |||
Network tools can detect and measure unwanted/excessive | Network tools can detect and measure unwanted/excessive | |||
reordering, and the impact on transport performance. | 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, and inform decisions about how to progress new | of reordering, and inform decisions about how to progress new | |||
mechanisms. | mechanisms. | |||
Techniques for measuring reordering typically observe packet | Techniques for measuring reordering typically observe packet | |||
sequence numbers. Metrics have been defined that evaluate whether | sequence numbers. Metrics have been defined that evaluate whether | |||
a network has maintained packet order on a packet-by-packet basis | a network path has maintained packet order on a packet-by-packet | |||
[RFC4737] [RFC5236]. Some protocols provide in-built monitoring | basis [RFC4737] [RFC5236]. Some protocols provide in-built | |||
and reporting functions. Transport fields in the RTP header | monitoring and reporting functions. Transport fields in the RTP | |||
[RFC3550] [RFC4585] can be observed to derive traffic volume | header [RFC3550] [RFC4585] can be observed to derive traffic | |||
measurements and provide information on the progress and quality | volume measurements and provide information on the progress and | |||
of a session using RTP. Metadata assists in understanding the | quality of a session using RTP. Metadata assists in understanding | |||
context under which the data was collected, including the time, | the context under which the data was collected, including the | |||
observation point [RFC7799], and way in which metrics were | time, observation point [RFC7799], and way in which metrics were | |||
accumulated. The RTCP protocol directly reports some of this | accumulated. The RTCP protocol directly reports some of this | |||
information in a form that can be directly visible in the network. | information in a form that can be directly visible by devices on | |||
the network path. | ||||
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 segment are obvious). Some active measurements | |||
(e.g., response under load or particular workloads) perturb other | [RFC7799] (e.g., response under load or particular workloads) perturb | |||
traffic, and could require dedicated access to the network segment. | other 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.4.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. | |||
Passive packet sampling techniques are also often used to scale the | Passive packet sampling techniques are also often used to scale the | |||
processing involved in observing packets on high rate links. This | processing involved in observing packets on high rate links. This | |||
exports only the packet header information of (randomly) selected | exports only the packet header information of (randomly) selected | |||
packets. Interpretation of the exported information relies on | packets. Interpretation of the exported information relies on | |||
understanding of the header information. The utility of these | understanding of the header information. The utility of these | |||
measurements depends on the type of bearer and number of mechanisms | measurements depends on the type of network segment/link and number | |||
used by network devices. Simple routers are relatively easy to | of mechanisms used by the network devices. Simple routers are | |||
manage, but a device with more complexity demands understanding of | relatively easy to manage, but a device with more complexity demands | |||
the choice of many system parameters. | understanding of the choice of many system parameters. | |||
2.2.2. Using Information Derived from Network Layer Header Fields | 2.3.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 | |||
(MF) classifier as a part of policy framework. Policies are commonly | (MF) classifier as a part of policy framework. Policies are commonly | |||
used for management of the QoS or Quality of Experience (QoE) in | used for management of the QoS or Quality of Experience (QoE) in | |||
resource-constrained networks, or by firewalls to implement access | resource-constrained networks, or by firewalls to implement access | |||
rules (see also Section 2.2.2 of [RFC8404]). Policies can support | rules (see also Section 2.2.2 of [RFC8404]). Policies can support | |||
user applications/services or protect against unwanted, or lower | user applications/services or protect against unwanted, or lower | |||
priority traffic (Section 2.3.4). | priority traffic (Section 2.4.4). | |||
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 devices forming the network path, even when a | |||
protect other header information. | transport employs encryption to protect other header information. | |||
On the one hand, the user of a transport that multiplexes multiple | On the one hand, the user of a transport that multiplexes multiple | |||
sub-flows might want to obscure the presence and characteristics of | sub-flows might want to obscure the presence and characteristics of | |||
these sub-flows. On the other hand, an encrypted transport could set | these sub-flows. On the other hand, an encrypted transport could set | |||
the network-layer information to indicate the presence of sub-flows, | the network-layer information to indicate the presence of sub-flows, | |||
and to reflect the service requirements of individual sub-flows. | and to reflect the service requirements of individual sub-flows. | |||
There are several ways this could be done: | There are several ways this could be done: | |||
IP Address: Applications normally expose the endpoint addresses used | IP Address: Applications normally expose the endpoint addresses used | |||
in the forwarding decisions in network devices. Address and other | in the forwarding decisions in network devices. Address and other | |||
protocol information can be used by a MF-classifier to determine | protocol information can be used by a MF-classifier to determine | |||
how traffic is treated [RFC2475], and hence affect the quality of | how traffic is treated [RFC2475], and hence affect the quality of | |||
experience for a flow. | experience for a flow. Common issues concerning IP address | |||
sharing are described in [RFC6269]. | ||||
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, including use with | |||
example with Equal Cost Multi-Path routing and Link Aggregation | IPsec, [RFC6294] and use with Equal Cost Multi-Path routing and | |||
[RFC6294]. RFC 6438 describes considerations when using IPsec | Link Aggregation[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 linkages between flows that a network device could not | |||
Inappropriate use by the transport can have privacy implications | otherwise observe. Inappropriate use by the transport can have | |||
(e.g., assigning the same label to two independent flows that | privacy implications (e.g., assigning the same label to two | |||
ought not to be classified the same). | independent flows that 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 network | |||
by setting the Differentiated Services Code Point (DSCP) field of | devices by setting the Differentiated Services Code Point (DSCP) | |||
IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications | field of IPv4 and IPv6 packets [RFC2474]. For example, WebRTC | |||
identify different forwarding treatments for individual sub-flows | applications identify different forwarding treatments for | |||
(audio vs. video) based on the value of the DSCP field | individual sub-flows (audio vs. video) based on the value of the | |||
[I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information | DSCP field [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit | |||
to inform network-layer queueing and forwarding, rather than an | information to inform network-layer queueing and forwarding, | |||
operator inferring traffic requirements from transport and | rather than an operator inferring traffic requirements from | |||
application headers via a multi-field classifier. Inappropriate | transport and application headers via a multi-field classifier. | |||
use by the transport can have privacy implications (e.g., | Inappropriate use by the transport can have privacy implications | |||
assigning a different DSCP to a subflow could assist in a network | (e.g., assigning a different DSCP to a subflow could assist in a | |||
device discovering the traffic pattern used by an application, | network device discovering the traffic pattern used by an | |||
assigning the same label to two independent flows that ought not | application). The field is mutable, i.e., some network devices | |||
to be classified the same). The field is mutable, i.e., some | can be expected to change this field. Since the DSCP value can | |||
network devices can be expected to change this field. Since the | impact the quality of experience for a flow, observations of | |||
DSCP value can impact the quality of experience for a flow, | service performance have to consider this field when a network | |||
observations of service performance have to consider this field | path supports differentiated service treatment. | |||
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 15 ¶ | skipping to change at page 12, line 45 ¶ | |||
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 | |||
(see Section 5.1). These can 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. IP | IPv4 [RFC0791] has provision for optional header fields. IP | |||
routers can examine these headers and are required to ignore IPv4 | routers can examine these headers and are required to ignore IPv4 | |||
options that they does not recognise. Many current paths include | options that they do not recognise. Many current paths include | |||
network devices that forward packets that carry options on a | network devices that forward packets that carry options on a | |||
slower processing path. Some network devices (e.g., firewalls) | slower processing path. Some network devices (e.g., firewalls) | |||
can be (and are) configured to drop these packets [RFC7126]. BCP | can be (and are) configured to drop these packets [RFC7126]. BCP | |||
186 [RFC7126] provides Best Current Practice guidance on how | 186 [RFC7126] provides Best Current Practice guidance on how | |||
operators should treat IPv4 packets that specify options. | operators should treat IPv4 packets that 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]. (e.g., the IPv6 Alternate Marking Method | |||
[I-D.ietf-6man-ipv6-alt-mark], which can be used to measure packet | ||||
loss and delay metrics). 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 if explicitly | header to be examined by any node along the path if explicitly | |||
configured [RFC8200]. | configured [RFC8200]. | |||
Careful use of the network layer features (e.g., Extension Headers | Careful use of the network layer features (e.g., Extension Headers | |||
can Section 5) help provide similar information in the case where the | can Section 5) help provide similar information in the case where the | |||
network is unable to inspect transport protocol headers. | network is unable to inspect transport protocol headers. | |||
2.3. To Support Network Operations | 2.4. 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 analyse the service offered to the users of a network | headers to analyse the service offered to the users of a network | |||
segment, and to inform operational practice, and can help detect and | segment, and to inform operational practice, and 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 observable transport header information is not available, those | When observable transport header information is not available, those | |||
seeking an understanding of transport behaviour and dynamics might | seeking an understanding of transport behaviour and dynamics might | |||
learn to work without that information. Alternatively, they might | learn to work without that information. Alternatively, they might | |||
skipping to change at page 13, line 8 ¶ | skipping to change at page 13, line 40 ¶ | |||
other heuristics to infer network behaviour (see Section 2.1.1 of | other heuristics to infer network behaviour (see Section 2.1.1 of | |||
[RFC8404]). Operational practises aimed at inferring transport | [RFC8404]). Operational practises aimed at inferring transport | |||
parameters are out of scope for this document, and are only mentioned | parameters are out of scope for this document, and are only mentioned | |||
here to recognise that encryption does not necessarily stop operators | here to recognise that encryption does not necessarily stop operators | |||
from attempting to apply practises that have been used with | from attempting to apply practises that have been used with | |||
unencrypted transport headers. | unencrypted transport headers. | |||
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.4.1. Problem Location | |||
Observations of transport header information can be used to locate | Observations of transport header information can be used to locate | |||
the source of problems or to assess the performance of a network | the source of problems or to assess the performance of a network | |||
segment. Often issues can only be understood in the context of the | segment. Often issues can only be understood in the context of the | |||
other flows that share a particular path, particular device | other flows that share a particular path, particular device | |||
configuration, interface port, etc. A simple example is monitoring | configuration, interface port, etc. A simple example is monitoring | |||
of a network device that uses a scheduler or active queue management | of a network device that uses a scheduler or active queue management | |||
technique [RFC7567], where it could be desirable to understand | technique [RFC7567], where it could be desirable to understand | |||
whether the algorithms are correctly controlling latency, or if | whether the algorithms are correctly controlling latency, or if | |||
overload protection is working. This implies knowledge of how | overload protection is working. This implies knowledge of how | |||
traffic is assigned to any sub-queues used for flow scheduling, but | traffic is assigned to any sub-queues used for flow scheduling, but | |||
can require information about how the traffic dynamics impact active | can require information about how the traffic dynamics impact active | |||
queue management, starvation prevention mechanisms, and circuit- | queue management, starvation prevention mechanisms, and circuit- | |||
breakers. | breakers. | |||
Sometimes correlating observations of headers at multiple points | Sometimes correlating observations of headers at multiple points | |||
along the path (e.g., at the ingress and egress of a network | along the path (e.g., at the ingress and egress of a network | |||
segment), allows an observer to determine the contribution of a | segment), allows an observer to determine the contribution of a | |||
portion of the path to an observed metric. e.g., to locate a source | portion of the path to an observed metric. e.g., to locate a source | |||
of delay, jitter, loss, reordering, congestion marking. | of delay, jitter, loss, reordering, or congestion marking. | |||
2.3.2. Network Planning and Provisioning | 2.4.2. Network Planning and Provisioning | |||
Traffic rate and volume measurements are used to help plan deployment | Traffic rate and volume measurements are used to help plan deployment | |||
of new equipment and configuration in networks. Data is also | of new equipment and configuration in networks. Data is also | |||
valuable to equipment vendors who want to understand traffic trends | valuable to equipment vendors who want to understand traffic trends | |||
and patterns of usage as inputs to decisions about planning products | and patterns of usage as inputs to decisions about planning products | |||
and provisioning for new deployments. | and provisioning for new deployments. | |||
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. Compliance with Congestion Control | 2.4.3. 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. The | |||
The challenges increase when multiple instances of an evolving | challenges increase when multiple instances of an evolving protocol | |||
protocol contribute to the traffic that share network capacity. | 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 | |||
key transport function [RFC2914]. Many network operators | key transport function [RFC2914]. Many network operators | |||
implicitly accept that TCP traffic complies with a behaviour that | implicitly accept that TCP traffic complies with a behaviour that | |||
skipping to change at page 14, line 45 ¶ | skipping to change at page 15, line 28 ¶ | |||
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]. | |||
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.3). 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. | |||
A network operator can observe the headers of transport protocols | A network operator can observe the headers of transport protocols | |||
layered above UDP to understand if the datagram flows comply with | layered above UDP to understand if the datagram flows comply with | |||
congestion control expectations. This can help inform a decision | congestion control expectations. This can help inform a decision | |||
on whether it might be appropriate to deploy methods such as rate- | on whether it might be appropriate to deploy methods such as rate- | |||
limiters to enforce acceptable usage. The available information | limiters to enforce acceptable usage. The available information | |||
determines the level of precision with which flows can be | determines the level of precision with which flows can be | |||
classified and the design space for conditioning mechanisms (e.g., | classified and the design space for conditioning mechanisms (e.g., | |||
rate limiting, circuit breaker techniques [RFC8084], or blocking | rate limiting, circuit breaker techniques [RFC8084], or blocking | |||
of uncharacterised traffic) [RFC5218]. | of uncharacterised traffic) [RFC5218]. | |||
When anomalies are detected, tools can interpret the transport header | When anomalies are detected, tools can interpret the transport header | |||
information to help understand the impact of specific transport | information to help understand the impact of specific transport | |||
protocols (or protocol mechanisms) on the other traffic that shares a | protocols (or protocol mechanisms) on the other traffic that shares a | |||
network. An observation in the network can gain an understanding of | network. An observer on the network path can gain an understanding | |||
the dynamics of a flow and its congestion control behaviour. | of the dynamics of a flow and its congestion control behaviour. | |||
Analysing observed flows can help to build confidence that an | Analysing observed flows can help to build confidence that an | |||
application flow backs-off its share of the network load under | application flow backs-off its share of the network load under | |||
persistent congestion, and hence to understand whether the behaviour | persistent congestion, and hence to understand whether the behaviour | |||
is appropriate for sharing limited network capacity. For example, it | is appropriate for sharing limited network capacity. For example, it | |||
is common to visualise plots of TCP sequence numbers versus time for | is common to visualise plots of TCP sequence numbers versus time for | |||
a flow to understand how a flow shares available capacity, deduce its | a flow to understand how a flow shares available capacity, deduce its | |||
dynamics in response to congestion, etc. | dynamics in response to congestion, etc. | |||
The ability to identify sources and flows that contribute to | The ability to identify sources and flows that contribute to | |||
persistent congestion is important to the safe operation of network | persistent congestion is important to the safe operation of network | |||
infrastructure, and can inform configuration of network devices to | infrastructure, and can inform configuration of network devices to | |||
complement the endpoint congestion avoidance mechanisms [RFC7567] | complement the endpoint congestion avoidance mechanisms [RFC7567] | |||
[RFC8084] to avoid a portion of the network being driven into | [RFC8084] to avoid a portion of the network being driven into | |||
congestion collapse [RFC2914]. | congestion collapse [RFC2914]. | |||
2.3.4. To Characterise "Unknown" Network Traffic | 2.4.4. To Characterise "Unknown" Network Traffic | |||
The patterns and types of traffic that share Internet capacity change | The patterns and types of traffic that share Internet capacity change | |||
over time as networked applications, usage patterns and protocols | over time as networked applications, usage patterns and protocols | |||
continue to evolve. | continue to evolve. | |||
Encryption can increase the volume of "unknown" or "uncharacterised" | Encryption can increase the volume of "unknown" or "uncharacterised" | |||
traffic seen by the network. If these traffic patterns form a small | traffic seen by the network. If these traffic patterns form a small | |||
part of the traffic aggregate passing through a network device or | part of the traffic aggregate passing through a network device or | |||
segment of the network the path, the dynamics of the uncharacterised | segment of the network path, the dynamics of the uncharacterised | |||
traffic might not have a significant collateral impact on the | traffic might not have a significant collateral impact on the | |||
performance of other traffic that shares this network segment. Once | performance of other traffic that shares this network segment. Once | |||
the proportion of this traffic increases, monitoring the traffic can | the proportion of this traffic increases, monitoring the traffic can | |||
determine if appropriate safety measures have to be put in place. | determine if appropriate safety measures have to be put in place. | |||
Tracking the impact of new mechanisms and protocols requires traffic | Tracking the impact of new mechanisms and protocols requires traffic | |||
volume to be measured and new transport behaviours to be identified. | volume to be measured and new transport behaviours to be identified. | |||
This is especially true of protocols operating over a UDP substrate. | This is especially true of protocols operating over a UDP substrate. | |||
The level and style of encryption needs to be considered in | The level and style of encryption needs to be considered in | |||
determining how this activity is performed. On a shorter timescale, | determining how this activity is performed. | |||
information could also be collected to manage Denial of Service (DoS) | ||||
attacks against the infrastructure. | ||||
Traffic that cannot be classified, typically receives a default | Traffic that cannot be classified typically receives a default | |||
treatment. Some networks block or rate-limit traffic that cannot be | treatment. Some networks block or rate-limit traffic that cannot be | |||
classified. | classified. | |||
2.3.5. Network Diagnostics and Troubleshooting | 2.4.5. To Support Network Security Functions | |||
On-path observation of the transport headers of packets can be used | ||||
for various security functions. For example, Denial of Service (DoS) | ||||
and Distributed DoS (DDoS) attacks against the infrastructure or | ||||
against an endpoint can be detected and mitigated by characterising | ||||
anomalous traffic (see Section 2.4.4) on a shorter timescale. Other | ||||
uses include support for security audits (e.g., verifying the | ||||
compliance with cipher suites), client and application fingerprinting | ||||
for inventory, and to provide alerts for network intrusion detection | ||||
and other next generation firewall functions. | ||||
When using an encrypted transport, endpoints can directly provide | ||||
information to support these security functions. Another method, if | ||||
the endpoints do not provide this information, is to use an on-path | ||||
network device that relies on pattern inferences in the traffic, and | ||||
heuristics or machine learning instead of processing observed header | ||||
information. An endpoint could also explicitly cooperate with an on- | ||||
path device (e.g., a QUIC endpoint could share information about | ||||
current uses of connection IDs). | ||||
2.4.6. Network Diagnostics and Troubleshooting | ||||
Operators monitor the health of a network segment to support a | Operators monitor the health of a network segment to support a | |||
variety of operational tasks [RFC8404] including procedures to | variety of operational tasks [RFC8404] including procedures to | |||
provide early warning and trigger action: to diagnose network | provide early warning and trigger action: to diagnose network | |||
problems, to manage security threats (including DoS), to evaluate | problems, to manage security threats (including DoS), to evaluate | |||
equipment or protocol performance, or to respond to user performance | equipment or protocol performance, or to respond to user performance | |||
questions. Information about transport flows can assist in setting | questions. Information about transport flows can assist in setting | |||
buffer sizes, and help identify whether link/network tuning is | buffer sizes, and help identify whether link/network tuning is | |||
effective. Information can also support debugging and diagnosis of | effective. Information can also support debugging and diagnosis of | |||
the root causes of faults that concern a particular user's traffic | the root causes of faults that concern a particular user's traffic | |||
and can support post-mortem investigation after an anomaly. | 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. | |||
Network segments vary in their complexity. The design trade-offs for | Network segments vary in their complexity. The design trade-offs for | |||
radio networks are often very different from those of wired networks | radio networks are often very different from those of wired networks | |||
[RFC8462]. A radio-based network (e.g., cellular mobile, enterprise | [RFC8462]. A radio-based network (e.g., cellular mobile, enterprise | |||
Wireless LAN (WLAN), satellite access/back-haul, point-to-point | Wireless LAN (WLAN), satellite access/back-haul, point-to-point | |||
radio) add a subsystem that performs radio resource management, with | radio) adds a subsystem that performs radio resource management, with | |||
impact on the available capacity, and potentially loss/reordering of | impact on the available capacity, and potentially loss/reordering of | |||
packets. This impact can differ by traffic type, and can be | packets. This impact can differ by traffic type, and can be | |||
correlated with link propagation and interference. These can impact | correlated with link propagation and interference. These can impact | |||
the cost and performance of a provided service, and is expected to | the cost and performance of a provided service, and is expected to | |||
increase in importance as operators bring together heterogeneous | increase in importance as operators bring together heterogeneous | |||
types of network equipment and deploy opportunistic methods to access | types of network equipment and deploy opportunistic methods to access | |||
shared radio spectrum. | shared radio spectrum. | |||
2.3.6. Tooling and Network Operations | 2.4.7. Tooling and Network Operations | |||
A variety and open source and proprietary tools have been deployed | A variety of open source and proprietary tools have been deployed | |||
that use the transport header information observable with widely used | that use the transport header information observable with widely used | |||
protocols such as TCP or RTP/UDP/IP. Tools that dissect network | protocols such as TCP or RTP/UDP/IP. Tools that dissect network | |||
traffic flows can alert to potential problems that are hard to derive | traffic flows can alert to potential problems that are hard to derive | |||
from volume measurements, link statistics or device measurements | from volume measurements, link statistics or device measurements | |||
alone. | alone. | |||
Changes to the transport, whether to protect the transport headers, | Any introduction of a new transport protocol, protocol feature, or | |||
introduce a new transport protocol, protocol feature, or application | application might require changes to such tools, and so could impact | |||
might require changes to such tools, and so could impact operational | operational practice and policies. Such changes have associated | |||
practice and policies. Such changes have associated costs that are | costs that are incurred by the network operators that need to update | |||
incurred by the network operators that need to update their tooling | their tooling or develop alternative practises that work without | |||
or develop alternative practises that work without access to the | access to the changed/removed information. | |||
changed/removed information. | ||||
The use of encryption has the desirable effect of preventing | The use of encryption has the desirable effect of preventing | |||
unintended observation of the payload data and these tools seldom | unintended observation of the payload data and these tools seldom | |||
seek to observe the payload, or other application details. A flow | seek to observe the payload, or other application details. A flow | |||
that hides its transport header information could imply "don't touch" | that hides its transport header information could imply "don't touch" | |||
to some operators. This might limit a trouble-shooting response to | to some operators. This might limit a trouble-shooting response to | |||
"can't help, no trouble found". | "can't help, no trouble found". | |||
An alternative that does not require access to observable transport | An alternative that does not require access to observable transport | |||
headers is to access endpoint diagnostic tools or to include user | headers is to access endpoint diagnostic tools or to include user | |||
skipping to change at page 17, line 34 ¶ | skipping to change at page 18, line 37 ¶ | |||
and the associated costs can be small. Equally, more extensive | and the associated costs can be small. Equally, more extensive | |||
changes to the transport tend to require more extensive, and more | changes to the transport tend to require more extensive, and more | |||
expensive, changes to tooling and operational practice. Protocol | expensive, changes to tooling and operational practice. Protocol | |||
designers can mitigate these costs by explicitly choosing to expose | designers can mitigate these costs by explicitly choosing to expose | |||
selected information as invariants that are guaranteed not to change | selected information as invariants that are guaranteed not to change | |||
for a particular protocol (e.g., the header invariants and the spin- | for a particular protocol (e.g., the header invariants and the spin- | |||
bit in QUIC [I-D.ietf-quic-transport]). Specification of common log | bit in QUIC [I-D.ietf-quic-transport]). Specification of common log | |||
formats and development of alternative approaches can also help | formats and development of alternative approaches can also help | |||
mitigate the costs of transport changes. | mitigate the costs of transport changes. | |||
2.4. To Support Header Compression | 2.5. To Mitigate the Effects of Constrained Networks | |||
Some link and network segments are constrained by the capacity they | ||||
can offer, by the time it takes to access capacity (e.g., due to | ||||
under-lying radio resource management methods), or by asymmetries in | ||||
the design (e.g., many link are designed so that the capacity | ||||
available is different in the forward and return directions; some | ||||
radio technologies have different access methods in the forward and | ||||
return directions resulting from differences in the power budget). | ||||
The impact of path constraints can be mitigated using a proxy | ||||
operating at or above the transport layer to use an alternate | ||||
transport protocol. | ||||
In many cases, one or both endpoints are unaware of the | ||||
characteristics of the constraining link or network segment and | ||||
mitigations are applied below the transport layer: Packet | ||||
classification and QoS methods (described in various sections) can be | ||||
beneficial in differentially prioritising certain traffic when there | ||||
is a capacity constraint or additional delay in scheduling link | ||||
transmissions. Another common mitigation is to apply header | ||||
compression over the specific link or subnetwork (see Section 2.5.1). | ||||
2.5.1. To Provide 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. This has been widely | transport protocol headers on a per-hop basis. This has been widely | |||
used with low bandwidth dial-up access links, and still finds | used with low bandwidth dial-up access links, and still finds | |||
application on wireless links that are subject to capacity | application on wireless links that are subject to capacity | |||
constraints. These methods are effective for bit-congestive links | constraints. These methods are effective for bit-congestive links | |||
sending small packets (e.g., reducing the cost for sending control | sending small packets (e.g., reducing the cost for sending control | |||
packets or small data packets over radio links). | packets or small data packets over radio links). | |||
Examples of header compression include use with TCP/IP and RTP/UDP/IP | Examples of header compression include use with TCP/IP and RTP/UDP/IP | |||
flows [RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful | flows [RFC2507], [RFC6846], [RFC2508], [RFC5795], [RFC8724]. | |||
compression depends on observing the transport headers and | Successful compression depends on observing the transport headers and | |||
understanding of the way fields change between packets, and is hence | understanding of the way fields change between packets, and is hence | |||
incompatible with header encryption. Devices that compress transport | incompatible with header encryption. Devices that compress transport | |||
headers are dependent on a stable header format, implying | headers are dependent on a stable header format, implying | |||
ossification of that format. | ossification of that 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 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.5. To Verify SLA Compliance | 2.6. 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). It can also be used | compliance with Service Level Agreements (SLAs). It can also be used | |||
to understand whether a service is providing differential treatment | to understand whether a service is providing differential treatment | |||
to certain flows. | 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. | |||
skipping to change at page 18, line 41 ¶ | skipping to change at page 20, line 19 ¶ | |||
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. Research, Development and Deployment | 3. Research, Development and Deployment | |||
Independently observed data is important to ensure the health of the | Research and development of new protocols and mechanisms need to be | |||
research and development communities and provides data need to | informed by measurement data (as described in the previous section). | |||
evaluate new proposals for standardisation. Data can also help | Data can also help promote acceptance of proposed standards | |||
promote acceptance of proposed specifications by the wider community | specifications by the wider community (e.g., as a method to judge the | |||
(e.g., as a method to judge the safety for Internet deployment). | safety for Internet deployment). | |||
Open standards motivate a desire to include independent observation | ||||
and evaluation of performance data, which in turn demands control/ | Observed data is important to ensure the health of the research and | |||
understanding about where and when measurement samples are collected. | development communities, and provides data needed to evaluate new | |||
This requires consideration of the methods used to observe | proposals for standardisation. Open standards motivate a desire to | |||
information and the appropriate balance between encrypting all and no | include independent observation and evaluation of performance and | |||
transport header information. | deployment data. Independent data helps compare different methods, | |||
judge the level of deployment and ensure the wider applicability of | ||||
the results. This is important when considering when a protocol or | ||||
mechanism should be standardised for use in the general Internet. | ||||
This, 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 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 tool and procedures that observe transport protocols, | implications of tools and procedures that observe transport | |||
but does not endorse or condemn any specific practices. | protocols, but does not endorse or condemn any specific practises. | |||
3.1. Independent Measurement | 3.1. Independent Measurement | |||
Encrypting transport header information has implications on the way | Encrypting transport header information has implications on the way | |||
network data is collected and analysed. Independent observation by | network data is collected and analysed. Independent observation by | |||
multiple actors is currently used by the transport community to | multiple actors is currently used by the transport community to | |||
maintain an accurate understanding of the network. When providing or | maintain an accurate understanding of the network within transport | |||
using such information, it is important to consider the privacy of | area working groups, IRTF research groups, and the broader research | |||
the user and their incentive for providing accurate and detailed | community. This is important to be able to provide accountability, | |||
information. | and demonstrate that protocols behave as intended, although when | |||
providing or using such information, it is important to consider the | ||||
privacy of the user and their incentive for providing accurate and | ||||
detailed information. | ||||
Protocols that expose the state of the transport protocol in their | Protocols that expose the state of the transport protocol in their | |||
header (e.g., timestamps used to calculate the RTT, packet numbers | header (e.g., timestamps used to calculate the RTT, packet numbers | |||
used to assess congestion and requests for retransmission) provide an | used to assess congestion and requests for retransmission) provide an | |||
incentive for a sending endpoint to provide consistent information, | incentive for a sending endpoint to provide consistent information, | |||
because a protocol will not work otherwise. An in-network observer | because a protocol will not work otherwise. An on-path observer can | |||
can have confidence that well-known (and ossified) transport header | have confidence that well-known (and ossified) transport header | |||
information represents the actual state of the endpoints, when this | information represents the actual state of the endpoints, when this | |||
information is necessary for the protocol's correct operation. | information is necessary for the protocol's correct operation. | |||
Encryption of transport header information could reduce the range of | Encryption of transport header information could reduce the range of | |||
actors that can observe useful data. This would limit the | actors that can observe useful data. This would limit the | |||
information sources available to the Internet community to understand | information sources available to the Internet community to understand | |||
the operation of new transport protocols, reducing information to | the operation of new transport protocols, reducing information to | |||
inform design decisions and standardisation of the new protocols and | inform design decisions and standardisation of the new protocols and | |||
related operational practises. The cooperating dependence of | related operational practises. The cooperating dependence of | |||
network, application, and host to provide communication performance | network, application, and host to provide communication performance | |||
skipping to change at page 19, line 47 ¶ | skipping to change at page 21, line 34 ¶ | |||
devices and within service platforms) can observe performance, and | devices and within service platforms) can observe performance, and | |||
when performance cannot be independently verified by all parties. | when performance cannot be independently verified by all parties. | |||
3.2. Measurable Transport Protocols | 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, and aides | |||
helps understand the interactions between cooperating protocols and | understanding of the interactions between cooperating protocols and | |||
network mechanisms, the implications of sharing capacity with other | network mechanisms, the implications of sharing capacity with other | |||
traffic and the impact of different patterns of usage. The ability | traffic and the impact of different patterns of usage. The ability | |||
of other stakeholders to review transport header traces helps develop | of other stakeholders to review transport header traces helps develop | |||
insight into performance and traffic contribution of specific | insight into the performance and the 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 | Encryption enables a transport protocol to choose which internal | |||
state to reveal to the network, what information to encrypt, and what | state to reveal to devices on the network path, what information to | |||
fields to grease [RFC8701]. A new design can provide summary | encrypt, and what fields to grease [RFC8701]. A new design can | |||
information regarding its performance, congestion control state, | provide summary information regarding its performance, congestion | |||
etc., or to make available explicit measurement information. For | control state, etc., or to make available explicit measurement | |||
example, [I-D.ietf-quic-transport] specifies a way for a QUIC | information. For example, [I-D.ietf-quic-transport] specifies a way | |||
endpoint to optionally set the spin-bit to reflect to explicitly | for a QUIC endpoint to optionally set the spin-bit to explicitly | |||
reveal the RTT of an encrypted transport session to the on-path | reveal the RTT of an encrypted transport session to the on-path | |||
network devices. There is a choice of what information to expose. | network devices. There is a choice of what information to expose. | |||
For some operational uses, the information has to contain sufficient | For some operational uses, the information has to contain sufficient | |||
detail to understand, and possibly reconstruct, the network traffic | detail to understand, and possibly reconstruct, the network traffic | |||
pattern for further testing. The interpretation of the information | pattern for further testing. The interpretation of the information | |||
needs to consider whether this information reflects the actual | needs to consider whether this information reflects the actual | |||
transport state of the endpoints. This might require the trust of | transport state of the endpoints. This might require the trust of | |||
transport protocol implementers, to correctly reveal the desired | transport protocol implementers, to correctly reveal the desired | |||
information. | 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. At | experiment with and deploy a wide range of protocol mechanisms. At | |||
the time of writing, there has been interest in a wide range of new | the time of writing, there has been interest in a wide range of new | |||
transport methods, e.g., Larger Initial Window, Proportional Rate | transport methods, e.g., Larger Initial Window, Proportional Rate | |||
Reduction (PRR), congestion control methods based on measuring | Reduction (PRR), congestion control methods based on measuring | |||
bottleneck bandwidth and round-trip propagation time, the | bottleneck bandwidth and round-trip propagation time, the | |||
introduction of AQM techniques and new forms of ECN response (e.g., | introduction of AQM techniques and new forms of ECN response (e.g., | |||
Data Centre TCP, DCTP, and methods proposed for L4S). The growth and | Data Centre TCP, DCTCP, and methods proposed for L4S). The growth | |||
diversity of applications and protocols using the Internet also | and diversity of applications and protocols using the Internet also | |||
continues to expand. For each new method or application, it is | continues to expand. For each new method or application, it is | |||
desirable to build a body of data reflecting its behaviour under a | desirable to build a body of data reflecting its behaviour under a | |||
wide range of deployment scenarios, traffic load, and interactions | wide range of deployment scenarios, traffic load, and interactions | |||
with other deployed/candidate methods. | with other deployed/candidate methods. | |||
3.3. Other Sources of Information | 3.3. Other Sources of Information | |||
Some measurements that traditionally rely on observable transport | Some measurements that traditionally rely on observable transport | |||
information could be completed by utilising endpoint-based logging | information could be completed by utilising endpoint-based logging | |||
(e.g., based on Quic-Trace [Quic-Trace]). Such information has a | (e.g., based on Quic-Trace [Quic-Trace] and qlog | |||
diversity of uses, including developers wishing to debug/understand | [I-D.marx-qlog-main-schema]). Such information has a diversity of | |||
the transport/application protocols with which they work, researchers | uses, including developers wishing to debug/understand the transport/ | |||
seeking to spot trends and anomalies, and to characterise variants of | application protocols with which they work, researchers seeking to | |||
protocols. A standard format for endpoint logging could allow these | spot trends and anomalies, and to characterise variants of protocols. | |||
to be shared (after appropriate anonymisation) to understand | A standard format for endpoint logging could allow these to be shared | |||
performance and pathologies. | (after appropriate anonymisation) to understand performance and | |||
pathologies. | ||||
When measurement datasets are made available by servers or client | When measurement datasets are made available by servers or client | |||
endpoints, additional metadata, such as the state of the network and | endpoints, additional metadata, such as the state of the network and | |||
conditions in which the system was observed, is often necessary to | conditions in which the system was observed, is often necessary to | |||
interpret this data to answer questions about network performance or | interpret this data to answer questions about network performance or | |||
understand a pathology. Collecting and coordinating such metadata is | understand a pathology. Collecting and coordinating such metadata is | |||
more difficult when the observation point is at a different location | more difficult when the observation point is at a different location | |||
to the bottleneck or device under evaluation [RFC7799]. | to the bottleneck or device under evaluation [RFC7799]. | |||
Despite being applicable in some scenarios, endpoint logs do not | Despite being applicable in some scenarios, endpoint logs do not | |||
provide equivalent information to in-network measurements. In | provide equivalent information to on-path measurements made by | |||
particular, endpoint logs contain only a part of the information to | devices in the network. In particular, endpoint logs contain only a | |||
understand the operation of network devices and identify issues such | part of the information to understand the operation of network | |||
as link performance or capacity sharing between multiple flows. An | devices and identify issues such as link performance or capacity | |||
analysis can require coordination between actors at different layers | sharing between multiple flows. An analysis can require coordination | |||
to successfully characterise flows and correlate the performance or | between actors at different layers to successfully characterise flows | |||
behaviour of a specific mechanism with an equipment configuration and | and correlate the performance or behaviour of a specific mechanism | |||
traffic using operational equipment along a network path (e.g., | with an equipment configuration and traffic using operational | |||
combining transport and network measurements to explore congestion | equipment along a network path (e.g., combining transport and network | |||
control dynamics, to understand the implications of traffic on | measurements to explore congestion control dynamics, to understand | |||
designs for active queue management or circuit breakers). | the implications of traffic on designs for active queue management or | |||
circuit breakers). | ||||
Another source of information could arise from operations, | Another source of information could arise from operations, | |||
administration and management (OAM) (see Section 6) information data | administration and management (OAM) (see Section 6) information data | |||
records [I-D.ietf-ippm-ioam-data] that could be embedded into header | records could be embedded into header information at different layers | |||
information at different layers to support functions such as | to support functions such as performance evaluation, path-tracing, | |||
performance evaluation, path-tracing, path verification information, | path verification information, classification and a diversity of | |||
classification and a diversity of other uses. | other uses. | |||
In-situ OAM (IOAM) data fields [I-D.ietf-ippm-ioam-data] can be | ||||
encapsulated into a variety of protocols to record operational and | ||||
telemetry information in an existing packet, while that packet | ||||
traverses a part of the path between two points in a network (e.g., | ||||
within a particular IOAM management domain). The IOAM-Data-Fields | ||||
are independent from the protocols into which the IOAM-Data-Fields | ||||
are encapsulated. For example, IOAM can provide proof that a certain | ||||
traffic flow takes a pre-defined path, SLA verification for the live | ||||
data traffic, and statistics relating to traffic distribution. | ||||
4. Encryption and Authentication of Transport Headers | 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 well-known transport | ossification from network devices that inspect well-known transport | |||
headers. Once a network device observes a transport header and | headers. Once a network device observes a transport header and | |||
becomes reliant upon using it, the overall use of that field can | becomes reliant upon using it, the overall use of that field can | |||
become ossified, preventing new versions of the protocol and | become ossified, preventing new versions of the protocol and | |||
skipping to change at page 22, line 19 ¶ | skipping to change at page 24, line 17 ¶ | |||
the presence of certain header fields exposed in TLS 1.2 | the presence of certain header fields exposed in TLS 1.2 | |||
[RFC5426]. | [RFC5426]. | |||
o The design of Multipath TCP (MPTCP) [RFC8684] had to account for | o The design of Multipath TCP (MPTCP) [RFC8684] had to account for | |||
middleboxes (known as "TCP Normalizers") that monitor the | middleboxes (known as "TCP Normalizers") that monitor the | |||
evolution of the window advertised in the TCP header and then | evolution of the window advertised in the TCP header and then | |||
reset connections when the window did not grow as expected. | reset connections when the window did not grow as 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, and some middleboxes that disrupt connections that send | |||
before completion of the three-way handshake. | data before completion of the three-way handshake. | |||
o Other examples of TCP 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 made | correctly rewrite the SACK information to match the changes made | |||
to the fixed TCP header, preventing correct SACK operation. | to the fixed TCP header, preventing correct SACK operation. | |||
In all these cases, middleboxes with a hard-coded, but incomplete, | In all these cases, middleboxes with a hard-coded, but incomplete, | |||
understanding of a specific transport behaviour (i.e., TCP), | understanding of a specific transport behaviour (i.e., TCP), | |||
interacted poorly with transport protocols after the transport | interacted poorly with transport protocols after the transport | |||
behaviour was changed. In some case, the middleboxes modified or | behaviour was changed. In some cases, the middleboxes modified or | |||
replaced information in the 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 ossified mechanisms being | the transport headers, and therefore stops ossified mechanisms being | |||
used that directly rely on or infer semantics of the transport header | used that directly rely on or infer semantics of the transport header | |||
information. This encryption is normally combined with | information. This encryption is normally combined with | |||
authentication of the protected information. RFC 8546 summarises | authentication of the protected information. RFC 8546 summarises | |||
this approach, stating that it is "The wire image, not the protocol's | this approach, stating that it is "The wire image, not the protocol's | |||
specification, determines how third parties on the network paths | specification, determines how third parties on the network paths | |||
among protocol participants will interact with that protocol" | among protocol participants will interact with that protocol" | |||
skipping to change at page 23, line 28 ¶ | skipping to change at page 25, line 25 ¶ | |||
Whatever the reasons, the IETF is designing protocols that include | Whatever the reasons, the IETF is designing protocols that include | |||
transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to | transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to | |||
supplement the already widespread payload encryption, and to further | supplement the already widespread payload encryption, and to further | |||
limit exposure of transport metadata to the network. | limit exposure of transport metadata to the network. | |||
If a transport protocol uses header encryption, the designers have to | If a transport protocol uses header encryption, the designers have to | |||
decide whether to encrypt all, or a part of, the transport layer | decide whether to encrypt all, or a part of, the transport layer | |||
information. Section 4 of [RFC8558] states: "Anything exposed to the | information. Section 4 of [RFC8558] states: "Anything exposed to the | |||
path should be done with the intent that it be used by the network | 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 | elements on the path". | |||
observable in the network, or can define new fields designed to | ||||
explicitly expose observable transport layer information to the | Certain transport header fields can be made observable to on-path | |||
network. Where exposed fields are intended to be immutable (i.e., | network devices, or can define new fields designed to explicitly | |||
can be observed, but not modified by a network device), the endpoints | expose observable transport layer information to the network. Where | |||
are encouraged to use authentication to provide a cryptographic | exposed fields are intended to be immutable (i.e., can be observed, | |||
integrity check that can detect if these immutable fields have been | but not modified by a network device), the endpoints are encouraged | |||
modified by network devices. Authentication can help to prevent | to use authentication to provide a cryptographic integrity check that | |||
attacks that rely on sending packets that fake exposed control | can detect if these immutable fields have been modified by network | |||
signals in transport headers (e.g., TCP RST spoofing). Making a part | devices. Authentication can help to prevent attacks that rely on | |||
of a transport header observable or exposing new header fields can | sending packets that fake exposed control signals in transport | |||
lead to ossification of that part of a header as network devices come | headers (e.g., TCP RST spoofing). Making a part of a transport | |||
to rely on observations of the exposed fields. | 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 | The use of transport header authentication and encryption therefore | |||
exposes a tussle between middlebox vendors, operators, applications | exposes a tussle between middlebox vendors, operators, researchers, | |||
developers and users: | applications developers, and end-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. | the use of transport header encryption can improve application and | |||
end-user privacy by reducing leakage of transport metadata to | ||||
operators that deploy middleboxes. | ||||
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 network operators and researchers seeking to | |||
networks, and researchers and analysts seeking to understand the | understand the dynamics of protocols and traffic patterns, since | |||
dynamics of protocols and traffic patterns. | it reduces the information that is available to them. | |||
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 | Security work typically employs a design technique that seeks to | |||
expose only what is needed [RFC3552]. This approach provides | expose only what is needed [RFC3552]. This approach provides | |||
incentives to not reveal any information that is not necessary for | incentives to not reveal any information that is not necessary for | |||
the end-to-end communication. The IAB has provided guidelines for | the end-to-end communication. The IETF has provided guidelines for | |||
writing Security Considerations for IETF specifications [RFC3552]. | writing Security Considerations for IETF specifications [RFC3552]. | |||
Endpoint design choices impacting privacy also need to be considered | Endpoint design choices impacting privacy also need to be considered | |||
as a part of the design process [RFC6973]. The IAB has provided | as a part of the design process [RFC6973]. The IAB has provided | |||
guidance for analyzing and documenting privacy considerations within | guidance for analyzing and documenting privacy considerations within | |||
IETF specifications [RFC6973]. | 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 example transport | |||
protects the immutable transport header fields, but can still | authentication mechanism is TCP-Authentication (TCP-AO) [RFC5925]. | |||
expose the transport header information in the clear, allows in- | This TCP option authenticates the IP pseudo header, TCP header, | |||
network devices to observe these fields. An integrity check is | and TCP data. TCP-AO protects the transport layer, preventing | |||
not able to prevent in-network modification, but can prevent a | attacks from disabling the TCP connection itself and provides | |||
receiving endpoint from accepting changes and avoid impact on the | replay protection. Such authentication might interact with | |||
transport protocol operation, including some types of attack. | middleboxes, depending on their behaviour [RFC3234]. | |||
An example transport authentication mechanism is TCP- | ||||
Authentication (TCP-AO) [RFC5925]. This TCP option authenticates | ||||
the IP pseudo header, TCP header, and TCP data. TCP-AO protects | ||||
the transport layer, preventing attacks from disabling the TCP | ||||
connection itself and provides replay protection. Such | ||||
authentication might interact with middleboxes, depending on their | ||||
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 modification by network | |||
The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also | devices on the path. The IPsec Encapsulating Security Payload | |||
provide authentication and integrity without confidentiality using | (ESP) [RFC4303] can also provide authentication and integrity | |||
the NULL encryption algorithm [RFC2410]. SRTP [RFC3711] is | without confidentiality using the NULL encryption algorithm | |||
another example of a transport protocol that allows header | [RFC2410]. SRTP [RFC3711] is another example of a transport | |||
authentication. | protocol that allows header authentication. | |||
Integrity Check Transport protocols usually employ integrity checks | ||||
on the transport header information. Security method usually | ||||
employ stronger checks and can combine this with authentication. | ||||
An integrity check that protects the immutable transport header | ||||
fields, but can still expose the transport header information in | ||||
the clear, allows on-path network devices to observe these fields. | ||||
An integrity check is not able to prevent modification by network | ||||
devices on the path, but can prevent a receiving endpoint from | ||||
accepting changes and avoid impact on the transport protocol | ||||
operation, including some types of attack. | ||||
Selectively Encrypting Transport Headers and Payload: A transport | Selectively Encrypting Transport Headers and Payload: A transport | |||
protocol design that encrypts selected header fields, allows | protocol design that encrypts selected header fields, allows | |||
specific transport header fields to be made observable by network | specific transport header fields to be made observable by network | |||
devices. This information is explicitly exposed either in a | devices on the path. This information is explicitly exposed | |||
transport header field or lower layer protocol header. A design | either in a transport header field or lower layer protocol header. | |||
that only exposes immutable fields can also perform end-to-end | A design that only exposes immutable fields can also perform end- | |||
authentication of these fields across the path to prevent | to-end authentication of these fields across the path to prevent | |||
undetected modification of 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 | on-path network devices can modify the transport behaviour (e.g., | |||
extended headers described in [I-D.trammell-plus-abstract-mech]). | the extended headers described in | |||
An example of a method that encrypts some, but not all, transport | [I-D.trammell-plus-abstract-mech]). An example of a method that | |||
header information is GRE-in-UDP [RFC8086] when used with GRE | encrypts some, but not all, transport header information is GRE- | |||
encryption. | in-UDP [RFC8086] when used with GRE 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 have to be made to use variable format | |||
format fields. Instead, fields of a specific type ought to always | fields. Instead, fields of a specific type ought to be sent with | |||
be sent with the same level of confidentiality or integrity | the same level of confidentiality or integrity protection. | |||
protection. | ||||
Greasing: Protocols often provide extensibility features, reserving | Greasing: Protocols often provide extensibility features, reserving | |||
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 on-path network devices have emerged | |||
ossify to require a certain value in a field, or re-use a field | that ossify to require a certain value in a field, or re-use a | |||
for another purpose. When the specification is later updated, it | field for another purpose. When the specification is later | |||
is impossible to deploy the new use of the field, and forwarding | updated, it is impossible to deploy the new use of the field, and | |||
of the protocol could even become conditional on a specific header | forwarding of the protocol could even become conditional on a | |||
field value. | specific header 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 [RFC8701]. This | presence of observable transport header fields at random | |||
prevents a network device ossifying the use of a specific | [RFC8701]. This prevents a network device ossifying the use of a | |||
observable field and can ease future deployment of new uses of the | specific observable field and can ease future deployment of new | |||
value or codepoint. This is not a security mechanism, although | uses of the value or code-point. This is not a security | |||
the use can be combined with an authentication mechanism. | mechanism, although the use can be combined with an authentication | |||
mechanism. | ||||
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 an on-path network device. | |||
to expose transport information in a network-layer extension header | Another approach is to expose transport information in a network- | |||
(see Section 5.1). Both are examples of explicit information | layer extension header (see Section 5.1). Both are examples of | |||
intended to be used by network devices on the path [RFC8558]. | explicit information intended to be used by network devices on the | |||
path [RFC8558]. | ||||
Whatever the mechanism used to expose the information, a decision to | Whatever the mechanism used to expose the information, a decision to | |||
expose only specific information, places the transport endpoint in | expose only specific information places the transport endpoint in | |||
control of what to expose outside of the encrypted transport header. | control of what to expose outside of the encrypted transport header. | |||
This decision can then be made independently of the transport | This decision can then be made independently of the transport | |||
protocol functionality. This can be done by exposing part of the | protocol functionality. This can be done by exposing part of the | |||
transport header or as a network layer option/extension. | transport header or as a network layer 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 that | At the network-layer, packets can carry optional headers that | |||
explicitly expose transport header information to the on-path devices | explicitly expose transport header information to the on-path devices | |||
operating at the network layer (Section 2.2.2). For example, an | operating at the network layer (Section 2.3.2). For example, an | |||
endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide | endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide | |||
explicit transport layer information that can be observed and used by | explicit transport layer information that can be observed and used by | |||
network devices on the path. New hop-by-hop options are not | network devices on the path. New hop-by-hop options are not | |||
recommended in RFC 8200 [RFC8200] "because nodes may be configured to | recommended in RFC 8200 [RFC8200] "because nodes may be configured to | |||
ignore the Hop-by-Hop Options header, drop packets containing a Hop- | ignore the Hop-by-Hop Options header, drop packets containing a Hop- | |||
by-Hop Options header, or assign packets containing a Hop-by-Hop | by-Hop Options header, or assign packets containing a Hop-by-Hop | |||
Options header to a slow processing path. Designers considering | Options header to a slow processing path. Designers considering | |||
defining new hop-by-hop options need to be aware of this likely | defining new hop-by-hop options need to be aware of this likely | |||
behavior." | behavior." | |||
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.) | format. (See Section 2.2.) | |||
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 27, line 27 ¶ | skipping to change at page 29, line 27 ¶ | |||
o On the one hand, explicitly exposing derived fields containing | o On the one hand, explicitly exposing derived fields containing | |||
relevant transport information (e.g., metrics for loss, latency, | relevant transport information (e.g., metrics for loss, latency, | |||
etc) can avoid network devices needing to derive this information | etc) can avoid network devices needing to derive this information | |||
from other header fields. This could result in development and | from other header fields. This could result in development and | |||
evolution of transport-independent tools around a common | evolution of transport-independent tools around a common | |||
observable header, and permit transport protocols to also evolve | observable header, and permit transport protocols to also evolve | |||
independently of this ossified header [RFC8558]. | independently of this ossified header [RFC8558]. | |||
o On the other hand, protocols and implementations might be designed | o On the other hand, protocols and implementations might be designed | |||
to avoid consistently exposing external information that reflects | to avoid consistently exposing external information that | |||
the actual internal information used by the protocol itself. An | corresponds to the actual internal information used by the | |||
endpoint/protocol could choose to expose transport header | protocol itself. An endpoint/protocol could choose to expose | |||
information to optimise the benefit it gets from the network | transport header information to optimise the benefit it gets from | |||
[RFC8558]. The value of this information would be enhanced if the | the network [RFC8558]. The value of this information for | |||
exposed information could be verified to match the protocol's | analysing operation of the transport layer would be enhanced if | |||
observed behavior. | the exposed information could be verified to match the transport | |||
protocol's observed behavior. | ||||
The motivation to reflect actual transport header information and the | The motivation to include actual transport header information and the | |||
implications of network devices using this information has to be | implications of network devices using this information has to be | |||
considered when proposing such a method. RFC 8558 summarises this as | considered when proposing such a method. RFC 8558 summarises this as | |||
"When signals from endpoints to the path are independent from the | "When signals from endpoints to the path are independent from the | |||
signals used by endpoints to manage the flow's state mechanics, they | signals used by endpoints to manage the flow's state mechanics, they | |||
may be falsified by an endpoint without affecting the peer's | may be falsified by an endpoint without affecting the peer's | |||
understanding of the flow's state. For encrypted flows, this | understanding of the flow's state. For encrypted flows, this | |||
divergence is not detectable by on-path devices." [RFC8558]. | divergence is not detectable by on-path devices [RFC8558]. | |||
6. Addition of Transport OAM Information to Network-Layer Headers | 6. Addition of Transport OAM Information to Network-Layer Headers | |||
If the transport headers are encrypted, on-path devices can make | Even when the transport headers are encrypted, on-path devices can | |||
measurements by utilising additional protocol headers carrying | make measurements by utilising additional protocol headers carrying | |||
operations, administration and management (OAM) information in an | OAM information in an additional packet header. OAM information can | |||
additional packet header. Using network-layer approaches to reveal | be included with packets to perform functions such as identification | |||
information has the potential that the same method (and hence same | of transport protocols and flows, to aide understanding of network or | |||
observation and analysis tools) can be consistently used by multiple | transport performance, or to support network operations or mitigate | |||
transport protocols. This approach also could be applied to methods | the effects of specific network segments. | |||
beyond OAM (see Section 5). There can also be less desirable | ||||
implications from separating the operation of the transport protocol | Using network-layer approaches to reveal information has the | |||
from the measurement framework. | potential that the same method (and hence same observation and | |||
analysis tools) can be consistently used by multiple transport | ||||
protocols. This approach also could be applied to methods beyond OAM | ||||
(see Section 5). There can also be less desirable implications from | ||||
separating the operation of the transport protocol from the | ||||
measurement framework. | ||||
6.1. Use of OAM within a Maintenance Domain | 6.1. Use of OAM within a Maintenance Domain | |||
OAM information can be added at the ingress to a maintenance domain | OAM information can be restricted to a maintenance domain, typically | |||
(e.g., an Ethernet protocol header with timestamps and sequence | owned and operated by a single entity. OAM information can be added | |||
number information using a method such as 802.11ag or in-situ OAM | at the ingress to the maintenance domain (e.g., an Ethernet protocol | |||
[I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol). | header with timestamps and sequence number information using a method | |||
This additional header information is not delivered to the endpoints | such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data], or as a | |||
and is typically removed at the egress of the maintenance domain. | part of the encapsulation protocol). This additional header | |||
information is not delivered to the endpoints and is typically | ||||
removed at the egress of the maintenance domain. | ||||
Although some types of measurements are supported, this approach does | Although some types of measurements are supported, this approach does | |||
not cover the entire range of measurements described in this | not cover the entire range of measurements described in this | |||
document. In some cases, it can be difficult to position measurement | document. In some cases, it can be difficult to position measurement | |||
tools at the appropriate segments/nodes and there can be challenges | tools at the appropriate segments/nodes and there can be challenges | |||
in correlating the downstream/upstream information when in-band OAM | in correlating the downstream/upstream information when in-band OAM | |||
data is inserted by an on-path device. | data is inserted by an on-path device. | |||
6.2. Use of OAM across Multiple Maintenance Domains | 6.2. Use of OAM across Multiple Maintenance Domains | |||
OAM information can also be added at the network layer by the sender | OAM information can also be added at the network layer by the sender | |||
as an IPv6 extension header or an IPv4 option, or in an | as an IPv6 extension header or an IPv4 option, or in an | |||
encapsulation/tunnel header that also includes an extension header or | encapsulation/tunnel header that also includes an extension header or | |||
option. This information can be used across multiple network | option. This information can be used across multiple network | |||
segments, or between the transport endpoints. | 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 carries 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 a receiving transport endpoint | information could be authenticated by a receiving transport endpoint | |||
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 need to be explicitly enabled at the sender. | been proposed. This needs to be explicitly enabled at the 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. | |||
This document has described some current practises, and the | This document has described some current practises, and the | |||
implications for some stakeholders, when transport layer header | implications for some stakeholders, when transport layer header | |||
encryption is used. It does not judge whether these practises are | encryption is used. It does not judge whether these practises are | |||
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 choices about what transport header | |||
to encrypt, and whether it might be beneficial to make an explicit | fields to encrypt, and whether it might be beneficial to make an | |||
choice to expose certain fields to the network. In making such a | explicit choice to expose certain fields to devices on the network | |||
decision, it is important to balance: | path. In making such a 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 user privacy implications. Transports that chose | that might have user privacy implications. Transports that chose | |||
to expose some header fields need to make a privacy assessment to | to expose some header fields need to make a privacy assessment to | |||
understand the privacy cost versus benefit trade-off in making | understand the privacy cost versus benefit trade-off in making | |||
that information available. The design of the QUIC spin bit to | that information available. The design of the QUIC spin bit to | |||
the network is an example considered such analysis. | the network is an example of such considered 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 | |||
skipping to change at page 30, line 11 ¶ | skipping to change at page 32, line 22 ¶ | |||
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 | |||
that encrypt their information will impact network operations, | that encrypt their information will impact network operations, | |||
unless operators can develop alternative practises that work | unless operators can develop alternative practises that work | |||
without access to the transport header. | without access to the transport header. | |||
o Pace of Evolution: Removing obstacles to change can enable an | o Pace of Evolution: Removing obstacles to change can enable an | |||
increased pace of evolution. If a protocol changes its transport | increased pace of evolution. If a protocol changes its transport | |||
header format (wire image) or their transport behaviour, this can | header format (wire image), or its transport behaviour, this can | |||
result in the currently deployed tools and methods becoming no | result in the currently deployed tools and methods becoming no | |||
longer relevant. Where this needs to be accompanied by | longer relevant. Where this needs to be accompanied by | |||
development of appropriate operational support functions and | development of appropriate operational support functions and | |||
procedures, it can incur a cost in new tooling to catch-up with | procedures, it can incur a cost in new tooling to catch-up with | |||
each change. Protocols that consistently expose observable data | each change. Protocols that consistently expose observable data | |||
do not require such development, but can suffer from ossification | do not require such development, but can suffer from ossification | |||
and need to consider if the exposed protocol metadata has privacy | and need to consider if the exposed protocol metadata has privacy | |||
implications. There is no single deployment context, and | implications. There is no single deployment context, and | |||
therefore designers need to consider the diversity of operational | therefore designers need to consider the diversity of operational | |||
networks (ISPs, enterprises, Distributed DoS (DDoS) mitigation and | networks (ISPs, enterprises, DDoS mitigation and firewall | |||
firewall maintainers, etc.). | maintainers, etc.). | |||
o Supporting Common Specifications: Common, open, specifications can | o Supporting Common Specifications: Common, open, transport | |||
stimulate engagement by developers, users, researchers, and the | specifications can stimulate engagement by developers, users, | |||
broader community. Increased protocol diversity can be beneficial | researchers, and the broader community. Increased protocol | |||
in meeting new requirements, but the ability to innovate without | diversity can be beneficial in meeting new requirements, but the | |||
public scrutiny risks point solutions that optimise for specific | ability to innovate without public scrutiny risks point solutions | |||
cases, but that can accidentally disrupt operations of/in | that optimise for specific cases, and that can accidentally | |||
different parts of the network. The social contract that | disrupt operations of/in different parts of the network. The | |||
maintains the stability of the Internet relies on accepting common | social contract that maintains the stability of the Internet | |||
interworking specifications, and on it being possible to detect | relies on accepting common transport specifications, and on it | |||
violations. It is important to find new ways of maintaining that | being possible to detect violations. The existence of independent | |||
community trust as increased use of transport header encryption | measurements, transparency, and public scrutiny of transport | |||
limits visibility into transport behaviour. | protocol behaviour, help the community to enforce the social norm | |||
that protocol implementations behave fairly and conform (at least | ||||
mostly) to the specifications. It is important to find new ways | ||||
of maintaining that community trust as increased use of transport | ||||
header encryption limits visibility into transport behaviour (see | ||||
also Section 5.3). | ||||
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, and/or | benchmarking network devices, endpoint stacks, and/or | |||
configurations. This can help understand complex feature | configurations. This can help understand complex 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 | |||
skipping to change at page 31, line 29 ¶ | skipping to change at page 33, line 45 ¶ | |||
what can be observed. This document does not make recommendations | what can be observed. This document does not make recommendations | |||
about what information ought to be exposed, to whom it ought to be | about what information ought to be exposed, to whom it ought to be | |||
observable, or how this will be achieved. There are also design | observable, or how this will be achieved. There are also design | |||
choices about where observable fields are placed. For example, one | choices about where observable fields are placed. For example, one | |||
location could be a part of the transport header outside of the | location could be a part of the transport header outside of the | |||
encryption envelope, another alternative is to carry the information | encryption envelope, another alternative is to carry the information | |||
in a network-layer option or extension header. New transport | in a network-layer option or extension header. New transport | |||
protocol designs ought to explicitly identify any fields that are | protocol designs ought to explicitly identify any fields that are | |||
intended to be observed, consider if there are alternative ways of | intended to be observed, consider if there are alternative ways of | |||
providing the information, and reflect on the implications of | providing the information, and reflect on the implications of | |||
observable fields being used by network devices, and how this might | observable fields being used by on-path network devices, and how this | |||
impact user privacy and protocol evolution when these fields become | might impact user privacy and protocol evolution when these fields | |||
ossified. | become ossified. | |||
As [RFC7258] notes, "Making networks unmanageable to mitigate | As [RFC7258] notes, "Making networks unmanageable to mitigate | |||
(pervasive monitoring) is not an acceptable outcome, but ignoring | (pervasive monitoring) is not an acceptable outcome, but ignoring | |||
(pervasive monitoring) would go against the consensus documented | (pervasive monitoring) would go against the consensus documented | |||
here." Providing explicit information can help avoid traffic being | here." Providing explicit information can help avoid traffic being | |||
inappropriately classified, impacting application performance. An | inappropriately classified, impacting application performance. An | |||
appropriate balance will emerge over time as real instances of this | appropriate balance will emerge over time as real instances of this | |||
tension are analysed [RFC7258]. This balance between information | tension are analysed [RFC7258]. This balance between information | |||
exposed and information hidden ought to be carefully considered when | exposed and information hidden ought to be carefully considered when | |||
specifying new transport protocols. | specifying new transport protocols. | |||
skipping to change at page 32, line 10 ¶ | skipping to change at page 34, line 24 ¶ | |||
throughout this document. | throughout this document. | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as Transport Features by [RFC8095]. As currently | are identified as Transport Features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
protocol or layer on top of the transport protocol [RFC8922]. | protocol or layer on top of the transport protocol [RFC8922]. | |||
Confidentiality and strong integrity checks have properties that can | Confidentiality and strong integrity checks have properties that can | |||
also be incorporated into the design of a transport protocol or to | also be incorporated into the design of a transport protocol or to | |||
modify an existing transport. Integrity checks can protect an | modify an existing transport. Integrity checks can protect an | |||
endpoint from undetected modification of protocol fields by network | endpoint from undetected modification of protocol fields by on-path | |||
devices, whereas encryption and obfuscation or greasing can further | network devices, whereas encryption and obfuscation or greasing can | |||
prevent these headers being utilised by network devices [RFC8701]. | further prevent these headers being utilised by network devices | |||
Preventing observation of headers provides an opportunity for greater | [RFC8701]. Preventing observation of headers provides an opportunity | |||
freedom to update the protocols and can ease experimentation with new | for greater freedom to update the protocols and can ease | |||
techniques and their final deployment in endpoints. A protocol | experimentation with new techniques and their final deployment in | |||
specification needs to weigh the costs of ossifying common headers, | endpoints. A protocol specification needs to weigh the costs of | |||
versus the potential benefits of exposing specific information that | ossifying common headers, versus the potential benefits of exposing | |||
could be observed along the network path to provide tools to manage | specific information that could be observed along the network path to | |||
new variants of protocols. | provide tools to manage new variants of protocols. | |||
Header encryption can provide confidentiality of some or all of the | Header encryption can provide confidentiality of some or all of the | |||
transport header information. This prevents an on-path device from | transport header information. This prevents an on-path device from | |||
knowledge of the header field. It therefore prevents mechanisms | gaining knowledge of the header field. It therefore prevents | |||
being built that directly rely on the information or seeks to infer | mechanisms being built that directly rely on the information or seeks | |||
semantics of an exposed header field. Reduced visibility into | to infer semantics of an exposed header field. Reduced visibility | |||
transport metadata can limit the ability to measure and characterise | into transport metadata can limit the ability to measure and | |||
traffic, and conversely can provide privacy benefits. | characterise traffic, and conversely can provide privacy benefits. | |||
Extending the transport payload security context to also include the | Extending the transport payload security context to also include the | |||
transport protocol header protects both information with the same | transport protocol header protects both types of information with the | |||
key. A privacy concern would arise if this key was shared with a | same key. A privacy concern would arise if this key was shared with | |||
third party, e.g., providing access to transport header information | a third party, e.g., providing access to transport header information | |||
to debug a performance issue, would also result in exposing the | to debug a performance issue, would also result in exposing the | |||
transport payload data to the same third party. Such risks would be | transport payload data to the same third party. Such risks would be | |||
mitigated using a layered security design that provides one domain of | mitigated using a layered security design that provides one domain of | |||
protection and associated keys for the transport payload and | protection and associated keys for the transport payload and | |||
encrypted transport headers; and a separate domain of protection and | encrypted transport headers; and a separate domain of protection and | |||
associated keys for any observable transport header fields. | associated keys for any observable transport header fields. | |||
Exposed transport headers are sometimes utilised as a part of the | Exposed transport headers are sometimes utilised as a part of the | |||
information to detect anomalies in network traffic. "While PM is an | information to detect anomalies in network traffic. "While PM is an | |||
attack, other forms of monitoring that might fit the definition of PM | attack, other forms of monitoring that might fit the definition of PM | |||
skipping to change at page 33, line 14 ¶ | skipping to change at page 35, line 28 ¶ | |||
packet). These techniques are currently used by some operators to | packet). These techniques are currently used by some operators to | |||
also defend from distributed DoS attacks. | also defend from distributed DoS attacks. | |||
Exposed transport header fields can also form a part of the | Exposed transport header fields can also form a part of the | |||
information used by the receiver of a transport protocol to protect | information used by the receiver of a transport protocol to protect | |||
the transport layer from data injection by an attacker. In | the transport layer from data injection by an attacker. In | |||
evaluating this use of exposed header information, it is important to | evaluating this use of exposed header information, it is important to | |||
consider whether it introduces a significant DoS threat. For | consider whether it introduces a significant DoS threat. For | |||
example, an attacker could construct a DoS attack by sending packets | example, an attacker could construct a DoS attack by sending packets | |||
with a sequence number that falls within the currently accepted range | with a sequence number that falls within the currently accepted range | |||
of sequence numbers at the receiving endpoint, this would then | of sequence numbers at the receiving endpoint. This would then | |||
introduce additional work at the receiving endpoint, even though the | introduce additional work at the receiving endpoint, even though the | |||
data in the attacking packet might not finally be delivered by the | data in the attacking packet might not finally be delivered by the | |||
transport layer. This is sometimes known as a "shadowing attack". | transport layer. This is sometimes known as a "shadowing attack". | |||
An attack can, for example, disrupt receiver processing, trigger loss | An attack can, for example, disrupt receiver processing, trigger loss | |||
and retransmission, or make a receiving endpoint perform unproductive | and retransmission, or make a receiving endpoint perform unproductive | |||
decryption of packets that cannot be successfully decrypted (forcing | decryption of packets that cannot be successfully decrypted (forcing | |||
a receiver to commit decryption resources, or to update and then | a receiver to commit decryption resources, or to update and then | |||
restore protocol state). | restore protocol state). | |||
One mitigation to off-path attack is to deny knowledge of what header | One mitigation to off-path attack is to deny knowledge of what header | |||
skipping to change at page 33, line 38 ¶ | skipping to change at page 36, line 5 ¶ | |||
[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 is attempted before a receiver discards an injected | decryption is attempted before a receiver discards an injected | |||
packet. | packet. | |||
Open standards motivate a desire for this evaluation to include | The existence of open transport protocol standards, and a research | |||
independent observation and evaluation of performance data, which in | and operations community with a history of independent observation | |||
turn suggests control over where and when measurement samples are | and evaluation of performance data, encourages fairness and | |||
collected. This requires consideration of the appropriate balance | conformance to those standards. This suggests careful consideration | |||
between encrypting all and no transport header information. Open | will be made over where, and when, measurement samples are collected. | |||
data, and accessibility to tools that can help understand trends in | An appropriate balance between encrypting some or all of the | |||
application deployment, network traffic and usage patterns can all | transport header information needs to be considered. Open data, and | |||
contribute to understanding security challenges. | accessibility to tools that can help understand trends in application | |||
deployment, network traffic and usage patterns can all contribute to | ||||
understanding security challenges. | ||||
The Security and Privacy Considerations in the Framework for Large- | The Security and Privacy Considerations in the Framework for Large- | |||
Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain | Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain | |||
considerations for Active and Passive measurement techniques and | considerations for Active and Passive measurement techniques and | |||
supporting material on measurement context. | supporting material on measurement context. | |||
Addition of observable transport information to the path increases | Addition of observable transport information to the path increases | |||
the information available to an observer and may, when this | the information available to an observer and may, when this | |||
information can be linked to a node or user, reduce the privacy of | information can be linked to a node or user, reduce the privacy of | |||
the user. See the security considerations of [RFC8558]. | the user. See the security considerations of [RFC8558]. | |||
skipping to change at page 34, line 39 ¶ | skipping to change at page 37, line 10 ¶ | |||
This work has received funding from the UK Engineering and Physical | This work has received funding from the UK Engineering and Physical | |||
Sciences Research Council under grant EP/R04144X/1. | Sciences Research Council under grant EP/R04144X/1. | |||
11. Informative References | 11. Informative References | |||
[bufferbloat] | [bufferbloat] | |||
Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in | Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in | |||
the Internet. Communications of the ACM, 55(1):57-65", | the Internet. Communications of the ACM, 55(1):57-65", | |||
January 2012. | January 2012. | |||
[I-D.ietf-6man-ipv6-alt-mark] | ||||
Fioccola, G., Zhou, T., Cociglio, M., and F. Qin, "IPv6 | ||||
Application of the Alternate Marking Method", draft-ietf- | ||||
6man-ipv6-alt-mark-00 (work in progress), May 2020. | ||||
[I-D.ietf-ippm-ioam-data] | [I-D.ietf-ippm-ioam-data] | |||
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields | Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields | |||
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in | for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in | |||
progress), July 2020. | progress), July 2020. | |||
[I-D.ietf-quic-transport] | [I-D.ietf-quic-transport] | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", draft-ietf-quic-transport-29 (work | and Secure Transport", draft-ietf-quic-transport-29 (work | |||
in progress), June 2020. | in progress), June 2020. | |||
[I-D.ietf-rtcweb-overview] | ||||
Alvestrand, H., "Overview: Real Time Protocols for | ||||
Browser-based Applications", draft-ietf-rtcweb-overview-19 | ||||
(work in progress), November 2017. | ||||
[I-D.ietf-tls-dtls13] | [I-D.ietf-tls-dtls13] | |||
Rescorla, E., Tschofenig, H., and N. Modadugu, "The | Rescorla, E., Tschofenig, H., and N. Modadugu, "The | |||
Datagram Transport Layer Security (DTLS) Protocol Version | Datagram Transport Layer Security (DTLS) Protocol Version | |||
1.3", draft-ietf-tls-dtls13-38 (work in progress), May | 1.3", draft-ietf-tls-dtls13-38 (work in progress), May | |||
2020. | 2020. | |||
[I-D.ietf-tsvwg-rtcweb-qos] | [I-D.ietf-tsvwg-rtcweb-qos] | |||
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | |||
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | |||
qos-18 (work in progress), August 2016. | qos-18 (work in progress), August 2016. | |||
[I-D.marx-qlog-main-schema] | ||||
Marx, R., "Main logging schema for qlog", draft-marx-qlog- | ||||
main-schema-02 (work in progress), November 2020. | ||||
[I-D.trammell-plus-abstract-mech] | [I-D.trammell-plus-abstract-mech] | |||
Trammell, B., "Abstract Mechanisms for a Cooperative Path | Trammell, B., "Abstract Mechanisms for a Cooperative Path | |||
Layer under Endpoint Control", draft-trammell-plus- | Layer under Endpoint Control", draft-trammell-plus- | |||
abstract-mech-00 (work in progress), September 2016. | abstract-mech-00 (work in progress), September 2016. | |||
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | |||
Techniques and Their Merits, IEEE Comm. Surveys & | Techniques and Their Merits, IEEE Comm. Surveys & | |||
Tutorials. 26;18(3) p2149-2196", November 2014. | Tutorials. 26;18(3) p2149-2196", November 2014. | |||
[Measurement] | [Measurement] | |||
skipping to change at page 37, line 33 ¶ | skipping to change at page 40, line 5 ¶ | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
DOI 10.17487/RFC4585, July 2006, | DOI 10.17487/RFC4585, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4585>. | <https://www.rfc-editor.org/info/rfc4585>. | |||
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | |||
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | |||
DOI 10.17487/RFC4737, November 2006, | DOI 10.17487/RFC4737, November 2006, | |||
<https://www.rfc-editor.org/info/rfc4737>. | <https://www.rfc-editor.org/info/rfc4737>. | |||
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | ||||
RFC 4960, DOI 10.17487/RFC4960, September 2007, | ||||
<https://www.rfc-editor.org/info/rfc4960>. | ||||
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion | ||||
Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March | ||||
2008, <https://www.rfc-editor.org/info/rfc5166>. | ||||
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful | [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful | |||
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, | Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, | |||
<https://www.rfc-editor.org/info/rfc5218>. | <https://www.rfc-editor.org/info/rfc5218>. | |||
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. | [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. | |||
Whitner, "Improved Packet Reordering Metrics", RFC 5236, | Whitner, "Improved Packet Reordering Metrics", RFC 5236, | |||
DOI 10.17487/RFC5236, June 2008, | DOI 10.17487/RFC5236, June 2008, | |||
<https://www.rfc-editor.org/info/rfc5236>. | <https://www.rfc-editor.org/info/rfc5236>. | |||
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", | [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", | |||
skipping to change at page 39, line 5 ¶ | skipping to change at page 41, line 30 ¶ | |||
"RObust Header Compression (ROHC): A Profile for TCP/IP | "RObust Header Compression (ROHC): A Profile for TCP/IP | |||
(ROHC-TCP)", RFC 6846, DOI 10.17487/RFC6846, January 2013, | (ROHC-TCP)", RFC 6846, DOI 10.17487/RFC6846, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6846>. | <https://www.rfc-editor.org/info/rfc6846>. | |||
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
Morris, J., Hansen, M., and R. Smith, "Privacy | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
Considerations for Internet Protocols", RFC 6973, | Considerations for Internet Protocols", RFC 6973, | |||
DOI 10.17487/RFC6973, July 2013, | DOI 10.17487/RFC6973, July 2013, | |||
<https://www.rfc-editor.org/info/rfc6973>. | <https://www.rfc-editor.org/info/rfc6973>. | |||
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 | ||||
Flow Label for Load Balancing in Server Farms", RFC 7098, | ||||
DOI 10.17487/RFC7098, January 2014, | ||||
<https://www.rfc-editor.org/info/rfc7098>. | ||||
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations | [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations | |||
on Filtering of IPv4 Packets Containing IPv4 Options", | on Filtering of IPv4 Packets Containing IPv4 Options", | |||
BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, | BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, | |||
<https://www.rfc-editor.org/info/rfc7126>. | <https://www.rfc-editor.org/info/rfc7126>. | |||
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | |||
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May | Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May | |||
2014, <https://www.rfc-editor.org/info/rfc7258>. | 2014, <https://www.rfc-editor.org/info/rfc7258>. | |||
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | |||
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | |||
<https://www.rfc-editor.org/info/rfc7413>. | <https://www.rfc-editor.org/info/rfc7413>. | |||
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. | ||||
Zimmermann, "A Roadmap for Transmission Control Protocol | ||||
(TCP) Specification Documents", RFC 7414, | ||||
DOI 10.17487/RFC7414, February 2015, | ||||
<https://www.rfc-editor.org/info/rfc7414>. | ||||
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | |||
Recommendations Regarding Active Queue Management", | Recommendations Regarding Active Queue Management", | |||
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | |||
<https://www.rfc-editor.org/info/rfc7567>. | <https://www.rfc-editor.org/info/rfc7567>. | |||
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
Aitken, P., and A. Akhter, "A Framework for Large-Scale | Aitken, P., and A. Akhter, "A Framework for Large-Scale | |||
Measurement of Broadband Performance (LMAP)", RFC 7594, | Measurement of Broadband Performance (LMAP)", RFC 7594, | |||
DOI 10.17487/RFC7594, September 2015, | DOI 10.17487/RFC7594, September 2015, | |||
<https://www.rfc-editor.org/info/rfc7594>. | <https://www.rfc-editor.org/info/rfc7594>. | |||
skipping to change at page 42, line 15 ¶ | skipping to change at page 44, line 43 ¶ | |||
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. | [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. | |||
Paasch, "TCP Extensions for Multipath Operation with | Paasch, "TCP Extensions for Multipath Operation with | |||
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March | Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March | |||
2020, <https://www.rfc-editor.org/info/rfc8684>. | 2020, <https://www.rfc-editor.org/info/rfc8684>. | |||
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And | [RFC8701] Benjamin, D., "Applying Generate Random Extensions And | |||
Sustain Extensibility (GREASE) to TLS Extensibility", | Sustain Extensibility (GREASE) to TLS Extensibility", | |||
RFC 8701, DOI 10.17487/RFC8701, January 2020, | RFC 8701, DOI 10.17487/RFC8701, January 2020, | |||
<https://www.rfc-editor.org/info/rfc8701>. | <https://www.rfc-editor.org/info/rfc8701>. | |||
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. | ||||
Zuniga, "SCHC: Generic Framework for Static Context Header | ||||
Compression and Fragmentation", RFC 8724, | ||||
DOI 10.17487/RFC8724, April 2020, | ||||
<https://www.rfc-editor.org/info/rfc8724>. | ||||
[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, | ||||
"Differentiated Services Code Point (DSCP) Packet Markings | ||||
for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January | ||||
2021, <https://www.rfc-editor.org/info/rfc8837>. | ||||
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. | [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. | |||
Wood, "A Survey of the Interaction between Security | Wood, "A Survey of the Interaction between Security | |||
Protocols and Transport Services", RFC 8922, | Protocols and Transport Services", RFC 8922, | |||
DOI 10.17487/RFC8922, October 2020, | DOI 10.17487/RFC8922, October 2020, | |||
<https://www.rfc-editor.org/info/rfc8922>. | <https://www.rfc-editor.org/info/rfc8922>. | |||
Appendix A. Revision information | Appendix A. Revision information | |||
-00 This is an individual draft for the IETF community. | -00 This is an individual draft for the IETF community. | |||
skipping to change at page 46, line 36 ¶ | skipping to change at page 49, line 36 ¶ | |||
comments. | comments. | |||
OPSEC:: No additional changes were requested in the OPSEC review. | OPSEC:: No additional changes were requested in the OPSEC review. | |||
IETF LC:: Tom Herbert: Please refer to 8200 on EH :: addressed in | IETF LC:: Tom Herbert: Please refer to 8200 on EH :: addressed in | |||
response to Joel above. Michael Richardson, Fernando Gont, Tom | response to Joel above. Michael Richardson, Fernando Gont, Tom | |||
Herbert: Continuation of discussion on domains where EH might be (or | Herbert: Continuation of discussion on domains where EH might be (or | |||
not) useful and the tussle on what information to reveal. Unclear | not) useful and the tussle on what information to reveal. Unclear | |||
yet what additional text should be changed within this ID. | yet what additional text should be changed within this ID. | |||
Authors' Addresses | ------------ | |||
- 21 Revised after IESG review: | ||||
Revision 21 includes revised text after comments from Zahed, Erik | ||||
Kline, Rob Wilton, Eric Vyncke, Roman Danyliw, and Benjamin Kaduk. | ||||
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 | |||
URI: http://www.erg.abdn.ac.uk/ | URI: http://www.erg.abdn.ac.uk/ | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
Scotland | Scotland | |||
EMail: csp@csperkins.org | EMail: csp@csperkins.org | |||
URI: https://csperkins.org/ | URI: https://csperkins.org/ | |||
End of changes. 122 change blocks. | ||||
408 lines changed or deleted | 568 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/ |