draft-fairhurst-tsvwg-transport-encrypt-09.txt | draft-fairhurst-tsvwg-transport-encrypt-10.txt | |||
---|---|---|---|---|
TSVWG G. Fairhurst | TSVWG G. Fairhurst | |||
Internet-Draft University of Aberdeen | Internet-Draft University of Aberdeen | |||
Intended status: Informational C.S. Perkins | Intended status: Informational C. Perkins | |||
Expires: December 14, 2018 University of Glasgow | Expires: February 28, 2019 University of Glasgow | |||
June 14, 2018 | August 27, 2018 | |||
The Impact of Transport Header Confidentiality on Network Operation and | The Impact of Transport Header Confidentiality on Network Operation and | |||
Evolution of the Internet | Evolution of the Internet | |||
draft-fairhurst-tsvwg-transport-encrypt-09 | draft-fairhurst-tsvwg-transport-encrypt-10 | |||
Abstract | Abstract | |||
This document describes implications of applying end-to-end | This document describes implications of applying end-to-end | |||
encryption at the transport layer. It identifies in-network uses of | encryption at the transport layer. It identifies in-network uses of | |||
transport layer header information. It then reviews the implications | transport layer header information. It then reviews the implications | |||
of developing end-to-end transport protocols that use authentication | of developing end-to-end transport protocols that use authentication | |||
to protect the integrity of transport information or encryption to | to protect the integrity of transport information or encryption to | |||
provide confidentiality of the transport protocol header and expected | provide confidentiality of the transport protocol header and expected | |||
implications of transport protocol design and network operation. | implications of transport protocol design and network operation. | |||
Since transport measurement and analysis of the impact of network | Since transport measurement and analysis of the impact of network | |||
characteristics have been important to the design of current | characteristics have been important to the design of current | |||
transport protocols, it also considers the impact on transport and | transport protocols, it also considers the impact on transport and | |||
application evolution. | application evolution. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://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 December 14, 2018. | This Internet-Draft will expire on February 28, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (http://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Simplified BSD License text | to this document. Code Components extracted from this document must | |||
as described in Section 4.e of the Trust Legal Provisions and are | include Simplified BSD License text as described in Section 4.e of | |||
provided without warranty as described in the Simplified BSD License. | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Current uses of Transport Headers within the Network . . . . . 8 | 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Observing Transport Information in the Network . . . . . . 9 | 3. Current uses of Transport Headers within the Network . . . . 9 | |||
2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9 | 3.1. Observing Transport Information in the Network . . . . . 9 | |||
2.1.2. Metrics derived from Transport Layer Headers . . . . . 10 | 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15 | |||
2.1.3. Metrics derived from Network Layer Headers . . . . . . 13 | 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 18 | |||
2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14 | 3.4. Observing Headers to Implement Network Policy . . . . . . 19 | |||
2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 15 | 4. Encryption and Authentication of Transport Headers . . . . . 19 | |||
2.2.2. Use by Operators to Plan and Provision Networks . . . 15 | 4.1. Authenticating the Transport Protocol Header . . . . . . 21 | |||
2.2.3. Service Performance Measurement . . . . . . . . . . . 16 | 4.2. Encrypting the Transport Payload . . . . . . . . . . . . 22 | |||
2.2.4. Measuring Transport to Support Network Operations . . 16 | 4.3. Encrypting the Transport Header . . . . . . . . . . . . . 22 | |||
2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17 | 4.4. Authenticating Transport Information and Selectively | |||
2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18 | Encrypting the Transport Header . . . . . . . . . . . . . 22 | |||
2.4. Observing Headers to Implement Network Policy . . . . . . 19 | 4.5. Optional Encryption of Header Information . . . . . . . . 23 | |||
3. Encryption and Authentication of Transport Headers . . . . . . 19 | 5. Addition of Transport Information to Network-Layer Protocol | |||
3.1. Authenticating the Transport Protocol Header . . . . . . . 21 | Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21 | 6. Implications of Protecting the Transport Headers . . . . . . 24 | |||
3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21 | 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 24 | |||
3.4. Authenticating Transport Information and Selectively | 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 25 | |||
Encrypting the Transport Header . . . . . . . . . . . . . 22 | 6.3. Accountability and Internet Transport Protocols . . . . . 25 | |||
3.5. Optional Encryption of Header Information . . . . . . . . 22 | 6.4. Impact on Research, Development and Deployment . . . . . 26 | |||
4. Addition of Transport Information to Network-Layer Protocol | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
5. Implications of Protecting the Transport Headers . . . . . . . 23 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | |||
5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 | |||
5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24 | 11. Informative References . . . . . . . . . . . . . . . . . . . 31 | |||
5.3. Accountability and Internet Transport Protocols . . . . . 25 | Appendix A. Revision information . . . . . . . . . . . . . . . . 37 | |||
5.4. Impact on Research, Development and Deployment . . . . . . 25 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | ||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | ||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 | ||||
10.2. Informative References . . . . . . . . . . . . . . . . . 31 | ||||
Appendix A. Revision information . . . . . . . . . . . . . . . . . 36 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
1. Introduction | 1. Introduction | |||
This document describes implications of applying end-to-end | This document describes implications of applying end-to-end | |||
encryption at the transport layer. It reviews the implications of | encryption at the transport layer. It reviews the implications of | |||
developing end-to-end transport protocols that use encryption to | developing end-to-end transport protocols that use encryption to | |||
provide confidentiality of the transport protocol header and expected | provide confidentiality of the transport protocol header and expected | |||
implications of transport protocol design and network operation. It | implications of transport protocol design and network operation. It | |||
also considers anticipated implications on transport and application | also considers anticipated implications on transport and application | |||
evolution. | evolution. | |||
2. Context and Rationale | ||||
The transport layer provides end-to-end interactions between | The transport layer provides end-to-end interactions between | |||
endpoints (processes) using an Internet path. Transport protocols | endpoints (processes) using an Internet path. Transport protocols | |||
layer directly over the network-layer service and are sent in the | layer directly over the network-layer service and are sent in the | |||
payload of network-layer packets. They support end-to-end | payload of network-layer packets. They support end-to-end | |||
communication between applications, supported by higher-layer | communication between applications, supported by higher-layer | |||
protocols, running on the end systems (or transport endpoints). This | protocols, running on the end systems (or transport endpoints). This | |||
simple architectural view hides one of the core functions of the | simple architectural view hides one of the core functions of the | |||
transport, however, to discover and adapt to the properties of the | transport, however, to discover and adapt to the properties of the | |||
Internet path that is currently being used. The design of Internet | Internet path that is currently being used. The design of Internet | |||
transport protocols is as much about trying to avoid the unwanted | transport protocols is as much about trying to avoid the unwanted | |||
side effects of congestion on a flow and other capacity-sharing | side effects of congestion on a flow and other capacity-sharing | |||
flows, avoiding congestion collapse, adapting to changes in the path | flows, avoiding congestion collapse, adapting to changes in the path | |||
characteristics, etc., as it is about end-to-end feature negotiation, | characteristics, etc., as it is about end-to-end feature negotiation, | |||
flow control and optimising for performance of a specific | flow control and optimising for performance of a specific | |||
application. | application. | |||
To achieve stable Internet operations the IETF transport community | To achieve stable Internet operations the IETF transport community | |||
has to date relied heavily on measurement and insights of the network | has to date relied heavily on measurement and insights of the network | |||
operations community to understand the trade-offs, and to inform | operations community to understand the trade-offs, and to inform | |||
selection of appropriate mechanisms, to ensure a safe, reliable, and | selection of appropriate mechanisms, to ensure a safe, reliable, and | |||
robust Internet (e.g., [RFC1273]). In turn, the network operations | robust Internet (e.g., [RFC1273]). In turn, the network operations | |||
community relies on being able to understand the pattern and | community relies on being able to understand the pattern and | |||
requirements of traffic passing over the Internet, both in aggregate | requirements of traffic passing over the Internet, both in aggregate | |||
and at the flow level. | and at the flow level. | |||
There are many motivations for deploying encrypted transports | There are many motivations for deploying encrypted transports | |||
[RFC7624] (i.e., transport protocols that use encryption to provide | [RFC7624] (i.e., transport protocols that use encryption to provide | |||
confidentiality of some or all of the transport-layer header | confidentiality of some or all of the transport-layer header | |||
information), and encryption of transport payloads (i.e. | information), and encryption of transport payloads (i.e. | |||
confidentiality of the payload data). The increasing public concerns | confidentiality of the payload data). The increasing public concerns | |||
about the interference with Internet traffic have led to a rapidly | about the interference with Internet traffic have led to a rapidly | |||
expanding deployment of encryption to protect end-user privacy, in | expanding deployment of encryption to protect end-user privacy, in | |||
protocols like QUIC [I-D.ietf-quic-transport], but also expected to | protocols like QUIC [I-D.ietf-quic-transport], but also expected to | |||
form a basis of future protocol designs. | form a basis of future protocol designs. | |||
Some network operators and access providers, have come to rely on the | Some network operators and access providers, have come to rely on the | |||
in-network measurement of transport properties and the functionality | in-network measurement of transport properties and the functionality | |||
provided by middleboxes to both support network operations and | provided by middleboxes to both support network operations and | |||
enhance performance. There can therefore be implications when | enhance performance. There can therefore be implications when | |||
working with encrypted transport protocols that hide transport header | working with encrypted transport protocols that hide transport header | |||
information from the network. These present architectural challenges | information from the network. These present architectural challenges | |||
and considerations in the way transport protocols are designed, and | and considerations in the way transport protocols are designed, and | |||
ability to characterise and compare different transport solutions | ability to characterise and compare different transport solutions | |||
[Measure], Section 2.2. Implementations of network devices are | ||||
[Measure], Section 3.2. Implementations of network devices are | ||||
encouraged to avoid side-effects when protocols are updated. | encouraged to avoid side-effects when protocols are updated. | |||
Introducing cryptographic integrity checks to header fields can also | Introducing cryptographic integrity checks to header fields can also | |||
prevent undetected manipulation of the field by network devices, or | prevent undetected manipulation of the field by network devices, or | |||
undetected addition of information to a packet. However, this does | undetected addition of information to a packet. However, this does | |||
not prevent inspection of the information by a device on path, and it | not prevent inspection of the information by a device on path, and it | |||
is possible that such devices could develop mechanisms that rely on | is possible that such devices could develop mechanisms that rely on | |||
the presence of such a field, or a known value in the field. | the presence of such a field, or a known value in the field. | |||
Reliance on the presence and semantics of specific header information | Reliance on the presence and semantics of specific header information | |||
leads to ossification: An endpoint could be required to supply a | leads to ossification: An endpoint could be required to supply a | |||
specific header to receive the network service that it desires. In | specific header to receive the network service that it desires. In | |||
some cases, this could be benign or advantageous to the protocol | some cases, this could be benign or advantageous to the protocol | |||
(e.g., recognising the start of a connection, or explicitly exposing | (e.g., recognising the start of a connection, or explicitly exposing | |||
protocol information can be expected to provide more consistent | protocol information can be expected to provide more consistent | |||
decisions by on-path devices than the use of diverse methods to infer | decisions by on-path devices than the use of diverse methods to infer | |||
semantics from other flow properties). In some cases, this is not | semantics from other flow properties). In some cases, this is not | |||
beneficial (e.g., a mechanism implemented in a network device, such | beneficial (e.g., a mechanism implemented in a network device, such | |||
as a firewall, that required a header field to have only a specific | as a firewall, that required a header field to have only a specific | |||
known set of values could prevent the device from forwarding packets | known set of values could prevent the device from forwarding packets | |||
using a different version of a protocol that introduces a new feature | using a different version of a protocol that introduces a new feature | |||
that changes the value present in this field, preventing evolution of | that changes the value present in this field, preventing evolution of | |||
the protocol). | the protocol). | |||
Examples of the impact of ossification on transport protocol design | ||||
and ease of deployment can be seen in the case of Multipath TCP | ||||
(MPTCP) and the TCP Fast Open option. The design of MPTCP had to be | ||||
revised to account for middleboxes, so called "TCP Normalizers", that | ||||
monitor the evolution of the window advertised in the TCP headers and | ||||
that reset connections if the window does not grow as expected. | ||||
Similarly, TCP Fast Open has had issues with middleboxes that remove | ||||
unknown TCP options, that drop segments with unknown TCP options, | ||||
that drop segments that contain data and have the SYN bit set, that | ||||
drop packets with SYN/ACK that acknowledge data, or that disrupt | ||||
connections that send data before the three-way handshake completes. | ||||
In both cases, the issue was caused by middleboxes that had a hard- | ||||
coded understanding of transport behaviour, and that interacted | ||||
poorly with transports that tried to change that behaviour. Other | ||||
examples have included middleboxes that rewrite TCP sequence and | ||||
acknowledgement numbers but are unaware of the (newer) SACK option | ||||
and don't correctly rewrite selective acknowledgements to match the | ||||
changes made to the fixed TCP header; or devices that inspect, and | ||||
change, TCP MSS options that can interfere with path MTU discovery. | ||||
A protocol design that uses header encryption can provide | A protocol design that uses header encryption can provide | |||
confidentiality of some or all of the protocol header information. | confidentiality of some or all of the protocol header information. | |||
This prevents an on-path device from knowledge of the header field. | This prevents an on-path device from knowledge of the header field. | |||
It therefore prevents mechanisms being built that directly rely on | It therefore prevents mechanisms being built that directly rely on | |||
the information or seeks to imply semantics of an exposed header | the information or seeks to imply semantics of an exposed header | |||
field. Using encryption to provide confidentiality of the transport | field. Using encryption to provide confidentiality of the transport | |||
layer brings some well-known privacy and security benefits and can | layer brings some well-known privacy and security benefits and can | |||
therefore help reduce ossification of the transport layer. In | therefore help reduce ossification of the transport layer. In | |||
particular, it is important that protocols either do not expose | particular, it is important that protocols either do not expose | |||
information where the usage may change in future protocols, or that | information where the usage may change in future protocols, or that | |||
skipping to change at page 5, line 20 ¶ | skipping to change at page 5, line 29 ¶ | |||
transport protocol. | transport protocol. | |||
A level of ossification of the transport header can offer trade-offs | A level of ossification of the transport header can offer trade-offs | |||
around authentication, and confidentiality of transport protocol | around authentication, and confidentiality of transport protocol | |||
headers and has the potential to explicitly support for other uses of | headers and has the potential to explicitly support for other uses of | |||
this header information. For example, a design that provides | this header information. For example, a design that provides | |||
confidentiality of protocol header information can impact the | confidentiality of protocol header information can impact the | |||
following activities that rely on measurement and analysis of traffic | following activities that rely on measurement and analysis of traffic | |||
flows: | flows: | |||
Network Operations and Research: Observable transport headers enable | Network Operations and Research: Observable transport headers enable | |||
both operators and the research community to measure and analyse | both operators and the research community to measure and analyse | |||
protocol performance, network anomalies, and failure pathologies. | protocol performance, network anomalies, and failure pathologies. | |||
This information can help inform capacity planning, and assist in | This information can help inform capacity planning, and assist in | |||
determining the need for equipment and/or configuration changes by | determining the need for equipment and/or configuration changes by | |||
network operators. | network operators. | |||
The data can also inform Internet engineering research, and help | The data can also inform Internet engineering research, and help | |||
in the development of new protocols, methodologies, and | in the development of new protocols, methodologies, and | |||
procedures. Concealing the transport protocol header information | procedures. Concealing the transport protocol header information | |||
makes the stream performance unavailable to passive observers | makes the stream performance unavailable to passive observers | |||
along the path, and likely leads to the development of alternative | along the path, and likely leads to the development of alternative | |||
methods to collect or infer that data. | methods to collect or infer that data. | |||
Providing confidentiality of the transport payload, but leaving | Providing confidentiality of the transport payload, but leaving | |||
some, or all, of the transport headers unencrypted, possibly with | some, or all, of the transport headers unencrypted, possibly with | |||
authentication, can provide the majority of the privacy and | authentication, can provide the majority of the privacy and | |||
security benefits while allowing some measurement. | security benefits while allowing some measurement. | |||
Protection from Denial of Service: Observable transport headers | Protection from Denial of Service: Observable transport headers | |||
currently provide useful input to classify traffic and detect | currently provide useful input to classify traffic and detect | |||
anomalous events (e.g., changes in application behaviour, | anomalous events (e.g., changes in application behaviour, | |||
distributed denial of service attacks). To be effective, this | distributed denial of service attacks). To be effective, this | |||
protection needs to be able to uniquely disambiguate unwanted | protection needs to be able to uniquely disambiguate unwanted | |||
traffic. An inability to separate this traffic using packet | traffic. An inability to separate this traffic using packet | |||
header information may result in less-efficient identification of | header information may result in less-efficient identification of | |||
unwanted traffic or development of different methods (e.g. rate- | unwanted traffic or development of different methods (e.g. rate- | |||
limiting of uncharacterised traffic). | limiting of uncharacterised traffic). | |||
Network Troubleshooting and Diagnostics: Encrypting transport header | Network Troubleshooting and Diagnostics: Encrypting transport | |||
information eliminates the incentive for operators to troubleshoot | header information eliminates the incentive for operators to | |||
what they cannot interpret. A flow experiencing packet loss or | troubleshoot what they cannot interpret. A flow experiencing | |||
jitter looks like an unaffected flow when only observing network | packet loss or jitter looks like an unaffected flow when only | |||
layer headers (if transport sequence numbers and flow identifiers | observing network layer headers (if transport sequence numbers and | |||
are obscured). This limits understanding of the impact of packet | flow identifiers are obscured). This limits understanding of the | |||
loss or latency on the flows, or even localizing the network | impact of packet loss or latency on the flows, or even localizing | |||
segment causing the packet loss or latency. Encrypted traffic may | the network segment causing the packet loss or latency. Encrypted | |||
imply "don't touch" to some, and could limit a trouble-shooting | traffic may imply "don't touch" to some, and could limit a | |||
response to "can't help, no trouble found". The additional | trouble-shooting response to "can't help, no trouble found". The | |||
mechanisms that will need to be introduced to help reconstruct | additional mechanisms that will need to be introduced to help | |||
transport-level metrics add complexity and operational costs | reconstruct transport-level metrics add complexity and operational | |||
(e.g., in deploying additional functions in equipment or adding | costs (e.g., in deploying additional functions in equipment or | |||
traffic overhead). | adding traffic overhead). | |||
Network Traffic Analysis: Hiding transport protocol header | Network Traffic Analysis: Hiding transport protocol header | |||
information can make it harder to determine which transport | information can make it harder to determine which transport | |||
protocols and features are being used across a network segment and | protocols and features are being used across a network segment and | |||
to measure trends in the pattern of usage. This could impact the | to measure trends in the pattern of usage. This could impact the | |||
ability for an operator to anticipate the need for network | ability for an operator to anticipate the need for network | |||
upgrades and roll-out. It can also impact the on-going traffic | upgrades and roll-out. It can also impact the on-going traffic | |||
engineering activities performed by operators (such as determining | engineering activities performed by operators (such as determining | |||
which parts of the path contribute delay, jitter or loss). While | which parts of the path contribute delay, jitter or loss). While | |||
the impact may, in many cases, be small there are scenarios where | the impact may, in many cases, be small there are scenarios where | |||
operators directly support particular services (e.g., to | operators directly support particular services (e.g., to | |||
troubleshoot issues relating to Quality of Service, QoS; the | troubleshoot issues relating to Quality of Service, QoS; the | |||
ability to perform fast re-routing of critical traffic, or support | ability to perform fast re-routing of critical traffic, or support | |||
to mitigate the characteristics of specific radio links). The more | to mitigate the characteristics of specific radio links). The | |||
complex the underlying infrastructure the more important this | more complex the underlying infrastructure the more important this | |||
impact. | impact. | |||
Open and Verifiable Network Data: Hiding transport protocol header | Open and Verifiable Network Data: Hiding transport protocol header | |||
information can reduce the range of actors that can capture useful | information can reduce the range of actors that can capture useful | |||
measurement data. For example, one approach could be to employ an | measurement data. For example, one approach could be to employ an | |||
existing transport protocol that reveals little information (e.g., | existing transport protocol that reveals little information (e.g., | |||
UDP), and perform traditional transport functions at higher layers | UDP), and perform traditional transport functions at higher layers | |||
protecting the confidentiality of transport information. Such a | protecting the confidentiality of transport information. Such a | |||
design, limits the information sources available to the Internet | design, limits the information sources available to the Internet | |||
community to understand the operation of new transport protocols, | community to understand the operation of new transport protocols, | |||
so preventing access to the information necessary to inform design | so preventing access to the information necessary to inform design | |||
decisions and standardisation of the new protocols and related | decisions and standardisation of the new protocols and related | |||
operational practices. | operational practices. | |||
skipping to change at page 8, line 48 ¶ | skipping to change at page 9, line 8 ¶ | |||
support. The choice of whether future transport protocols encrypt | support. The choice of whether future transport protocols encrypt | |||
their protocol headers therefore needs to be taken based not solely | their protocol headers therefore needs to be taken based not solely | |||
on security and privacy considerations, but also taking into account | on security and privacy considerations, but also taking into account | |||
the impact on operations, standards, and research. Any new Internet | the impact on operations, standards, and research. Any new Internet | |||
transport need to provide appropriate transport mechanisms and | transport need to provide appropriate transport mechanisms and | |||
operational support to assure the resulting traffic can not result in | operational support to assure the resulting traffic can not result in | |||
persistent congestion collapse [RFC2914]. This document suggests | persistent congestion collapse [RFC2914]. This document suggests | |||
that the balance between information exposed and concealed should be | that the balance between information exposed and concealed should be | |||
carefully considered when specifying new protocols. | carefully considered when specifying new protocols. | |||
2. Current uses of Transport Headers within the Network | 3. Current uses of Transport Headers within the Network | |||
Despite transport headers having end-to-end meaning, some of these | Despite transport headers having end-to-end meaning, some of these | |||
transport headers have come to be used in various ways within the | transport headers have come to be used in various ways within the | |||
Internet. In response to pervasive monitoring [RFC7624] revelations | Internet. In response to pervasive monitoring [RFC7624] revelations | |||
and the IETF consensus that "Pervasive Monitoring is an Attack" | and the IETF consensus that "Pervasive Monitoring is an Attack" | |||
[RFC7258], efforts are underway to increase encryption of Internet | [RFC7258], efforts are underway to increase encryption of Internet | |||
traffic,. Applying confidentiality to transport header fields would | traffic,. Applying confidentiality to transport header fields would | |||
affect how protocol information is used [I-D.mm-wg-effect-encrypt]. | affect how protocol information is used [RFC8404]. To understand | |||
To understand these implications, it is first necessary to understand | these implications, it is first necessary to understand how transport | |||
how transport layer headers are currently observed and/or modified by | layer headers are currently observed and/or modified by middleboxes | |||
middleboxes within the network. | within the network. | |||
Transport protocols can be designed to encrypt or authenticate | Transport protocols can be designed to encrypt or authenticate | |||
transport header fields. Authentication at the transport layer can | transport header fields. Authentication at the transport layer can | |||
be used to detect any changes to an immutable header field that were | be used to detect any changes to an immutable header field that were | |||
made by a network device along a path. The intentional modification | made by a network device along a path. The intentional modification | |||
of transport headers by middleboxes (such as Network Address | of transport headers by middleboxes (such as Network Address | |||
Translation, NAT, or Firewalls) is not considered. Common issues | Translation, NAT, or Firewalls) is not considered. Common issues | |||
concerning IP address sharing are described in [RFC6269]. | concerning IP address sharing are described in [RFC6269]. | |||
2.1. Observing Transport Information in the Network | 3.1. Observing Transport Information in the Network | |||
If in-network observation of transport protocol headers is needed, | If in-network observation of transport protocol headers is needed, | |||
this requires knowledge of the format of the transport header: | this requires knowledge of the format of the transport header: | |||
o Flows need to be identified at the level required to perform the | o Flows need to be identified at the level required to perform the | |||
observation; | observation; | |||
o The protocol and version of the header need to be visible. As | o The protocol and version of the header need to be visible. As | |||
protocols evolve over time and there may be a need to introduce | protocols evolve over time and there may be a need to introduce | |||
new transport headers. This may require interpretation of | new transport headers. This may require interpretation of | |||
protocol version information or connection setup information; | protocol version information or connection setup information; | |||
o The location and syntax of any observed transport headers needs to | o The location and syntax of any observed transport headers needs to | |||
be known. IETF transport protocols can specify this information. | be known. IETF transport protocols can specify this information. | |||
The following subsections describe various ways that observable | The following subsections describe various ways that observable | |||
transport information has been utilised. | transport information has been utilised. | |||
2.1.1. Flow Identification | 3.1.1. Flow Identification | |||
Transport protocol header information (together with information in | Transport protocol header information (together with information in | |||
the network header), has been used to identify a flow and the | the network header), has been used to identify a flow and the | |||
connection state of the flow, together with the protocol options | connection state of the flow, together with the protocol options | |||
being used. In some usages, a low-numbered (well-known) transport | being used. In some usages, a low-numbered (well-known) transport | |||
port number has been used to identify a protocol (although port | port number has been used to identify a protocol (although port | |||
information alone is not sufficient to guarantee identification of a | information alone is not sufficient to guarantee identification of a | |||
protocol, since applications can use arbitrary ports, multiple | protocol, since applications can use arbitrary ports, multiple | |||
sessions can be multiplexed on a single port, and ports can be re- | sessions can be multiplexed on a single port, and ports can be re- | |||
used by subsequent sessions). | used by subsequent sessions). | |||
skipping to change at page 10, line 23 ¶ | skipping to change at page 10, line 31 ¶ | |||
number in the transport header. UDP-based protocols can use, but | number in the transport header. UDP-based protocols can use, but | |||
sometimes do not use, well-known port numbers. Some flows can | sometimes do not use, well-known port numbers. Some flows can | |||
instead be identified by signalling protocols or through the use of | instead be identified by signalling protocols or through the use of | |||
magic numbers placed in the first byte(s) of the datagram payload. | magic numbers placed in the first byte(s) of the datagram payload. | |||
Flow identification is a common function. For example, performed by | Flow identification is a common function. For example, performed by | |||
measurement activities, QoS classification, firewalls, Denial of | measurement activities, QoS classification, firewalls, Denial of | |||
Service, DOS, prevention. It becomes more complex and less easily | Service, DOS, prevention. It becomes more complex and less easily | |||
achieved when multiplexing is used at or above the transport layer. | achieved when multiplexing is used at or above the transport layer. | |||
2.1.2. Metrics derived from Transport Layer Headers | 3.1.2. Metrics derived from Transport Layer Headers | |||
Some actors manage their portion of the Internet by characterizing | Some actors manage their portion of the Internet by characterizing | |||
the performance of link/network segments. Passive monitoring uses | the performance of link/network segments. Passive monitoring uses | |||
observed traffic to makes inferences from transport headers to derive | observed traffic to makes inferences from transport headers to derive | |||
these measurements. A variety of open source and commercial tools | these measurements. A variety of open source and commercial tools | |||
have been deployed that utilise this information. The following | have been deployed that utilise this information. The following | |||
metrics can be derived from transport header information: | metrics can be derived from transport header information: | |||
Traffic Rate and Volume: Header information e.g., (sequence number, | Traffic Rate and Volume: Header information e.g., (sequence number, | |||
length) allows derivation of volume measures per-application, to | length) allows derivation of volume measures per-application, to | |||
characterise the traffic that uses a network segment or the | characterise the traffic that uses a network segment or the | |||
pattern of network usage. This may be measured per endpoint or | pattern of network usage. This may be measured per endpoint or | |||
for an aggregate of endpoints (e.g., by an operator to assess | for an aggregate of endpoints (e.g., by an operator to assess | |||
subscriber usage). It can also be used to trigger measurement- | subscriber usage). It can also be used to trigger measurement- | |||
based traffic shaping and to implement QoS support within the | based traffic shaping and to implement QoS support within the | |||
network and lower layers. Volume measures can be valuable for | network and lower layers. Volume measures can be valuable for | |||
capacity planning (providing detail of trends rather than the | capacity planning (providing detail of trends rather than the | |||
volume per subscriber). | volume per subscriber). | |||
Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from | Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., | |||
sequence number) and has been used as a metric for performance | from sequence number) and has been used as a metric for | |||
assessment and to characterise transport behaviour. Understanding | performance assessment and to characterise transport behaviour. | |||
the root cause of loss can help an operator determine whether this | Understanding the root cause of loss can help an operator | |||
requires corrective action. Network operators have used the | determine whether this requires corrective action. Network | |||
variation in patterns of loss as a key performance metric, | operators have used the variation in patterns of loss as a key | |||
utilising this to detect changes in the offered service. | performance metric, utilising this to detect changes in the | |||
offered service. | ||||
There are various causes of loss, including: corruption of link | There are various causes of loss, including: corruption of link | |||
frames (e.g., interference on a radio link), buffer overflow | frames (e.g., interference on a radio link), buffer overflow | |||
(e.g., due to congestion), policing (traffic management), buffer | (e.g., due to congestion), policing (traffic management), buffer | |||
management (e.g., Active Queue Management, AQM [RFC7567]), | management (e.g., Active Queue Management, AQM [RFC7567]), | |||
inadequate provision of traffic preemption. Understanding flow | inadequate provision of traffic preemption. Understanding flow | |||
loss rate requires either maintaining per flow packet counters or | loss rate requires either maintaining per flow packet counters or | |||
by observing sequence numbers in transport headers. Loss can be | by observing sequence numbers in transport headers. Loss can be | |||
monitored at the interface level by devices in the network. It is | monitored at the interface level by devices in the network. It is | |||
often important to understand the conditions under which packet | often important to understand the conditions under which packet | |||
skipping to change at page 11, line 26 ¶ | skipping to change at page 11, line 32 ¶ | |||
Observation of transport feedback information (observing loss | Observation of transport feedback information (observing loss | |||
reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK) | reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK) | |||
can increase understanding of the impact of loss and help identify | can increase understanding of the impact of loss and help identify | |||
cases where loss may have been wrongly identified, or the | cases where loss may have been wrongly identified, or the | |||
transport did not require the lost packet. It is sometimes more | transport did not require the lost packet. It is sometimes more | |||
important to understand the pattern of loss, than the loss rate, | important to understand the pattern of loss, than the loss rate, | |||
because losses can often occur as bursts, rather than randomly- | because losses can often occur as bursts, rather than randomly- | |||
timed events. | timed events. | |||
Throughput and Goodput: The throughput achieved by a flow can be | Throughput and Goodput: The throughput achieved by a flow can be | |||
determined even when a flow is encrypted, providing the individual | determined even when a flow is encrypted, providing the individual | |||
flow can be identified. Goodput [RFC7928] is a measure of useful | flow can be identified. Goodput [RFC7928] is a measure of useful | |||
data exchanged (the ratio of useful/total volume of traffic sent | data exchanged (the ratio of useful/total volume of traffic sent | |||
by a flow). This requires ability to differentiate loss and | by a flow). This requires ability to differentiate loss and | |||
retransmission of packets (e.g., by observing packet sequence | retransmission of packets (e.g., by observing packet sequence | |||
numbers in the TCP or the Real Time Protocol, RTP, headers | numbers in the TCP or the Real Time Protocol, RTP, headers | |||
[RFC3550]). | [RFC3550]). | |||
Latency: Latency is a key performance metric that impacts application | Latency: Latency is a key performance metric that impacts | |||
response time and user-perceived response time. It often | application response time and user-perceived response time. It | |||
indirectly impacts throughput and flow completion time. Latency | often indirectly impacts throughput and flow completion time. | |||
determines the reaction time of the transport protocol itself, | Latency determines the reaction time of the transport protocol | |||
impacting flow setup, congestion control, loss recovery, and other | itself, impacting flow setup, congestion control, loss recovery, | |||
transport mechanisms. The observed latency can have many | and other transport mechanisms. The observed latency can have | |||
components [Latency]. Of these, unnecessary/unwanted queuing in | many components [Latency]. Of these, unnecessary/unwanted queuing | |||
network buffers has often been observed as a significant factor. | in network buffers has often been observed as a significant | |||
Once the cause of unwanted latency has been identified, this can | factor. Once the cause of unwanted latency has been identified, | |||
often be eliminated. | 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 | |||
can measure the experienced round trip time (RTT) using packet | can measure the experienced round trip time (RTT) using packet | |||
sequence numbers, and acknowledgements, or by observing header | sequence numbers, and acknowledgements, or by observing header | |||
timestamp information. Such information allows an observation | timestamp information. Such information allows an observation | |||
point in the network to determine not only the path RTT, but also | point in the network to determine not only the path RTT, but also | |||
to measure the upstream and downstream contribution to the RTT. | to measure the upstream and downstream contribution to the RTT. | |||
This has been used to locate a source of latency, e.g., by | This has been used to locate a source of latency, e.g., by | |||
observing cases where the ratio of median to minimum RTT is large | observing cases where the ratio of median to minimum RTT is large | |||
for a part of a path. | for a part of a path. | |||
The service offered by operators can benefit from latency | The service offered by operators can benefit from latency | |||
information to understand the impact of deployment and tune | information to understand the impact of deployment and tune | |||
deployed services. Latency metrics are key to evaluating and | deployed services. Latency metrics are key to evaluating and | |||
deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | |||
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | |||
could identify excessively large buffers, indicating where to | could identify excessively large buffers, indicating where to | |||
skipping to change at page 12, line 15 ¶ | skipping to change at page 12, line 21 ¶ | |||
This has been used to locate a source of latency, e.g., by | This has been used to locate a source of latency, e.g., by | |||
observing cases where the ratio of median to minimum RTT is large | observing cases where the ratio of median to minimum RTT is large | |||
for a part of a path. | for a part of a path. | |||
The service offered by operators can benefit from latency | The service offered by operators can benefit from latency | |||
information to understand the impact of deployment and tune | information to understand the impact of deployment and tune | |||
deployed services. Latency metrics are key to evaluating and | deployed services. Latency metrics are key to evaluating and | |||
deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit | |||
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | |||
could identify excessively large buffers, indicating where to | could identify excessively large buffers, indicating where to | |||
deploy or configure AQM. An AQM method is often deployed in | deploy or configure AQM. An AQM method is often deployed in | |||
combination with other techniques, such as scheduling [RFC7567] | combination with other techniques, such as scheduling [RFC7567] | |||
[I-D.ietf-aqm-fq-codel] and although parameter-less methods are | [RFC8290] and although parameter-less methods are desired | |||
desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D | [RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often | |||
.ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all | cannot scale across all possible deployment scenarios. | |||
possible deployment scenarios. | ||||
Variation in delay: Some network applications are sensitive to small | Variation in delay: Some network applications are sensitive to small | |||
changes in packet timing. To assess the performance of such | changes in packet timing. To assess the performance of such | |||
applications, it can be necessary to measure the variation in | applications, it can be necessary to measure the variation in | |||
delay observed along a portion of the path [RFC3393] [RFC5481]. | delay observed along a portion of the path [RFC3393] [RFC5481]. | |||
The requirements resemble those for the measurement of latency. | The requirements resemble those for the measurement of latency. | |||
Flow Reordering: Significant flow reordering can impact time-critical | Flow Reordering: Significant flow reordering can impact time- | |||
applications and can be interpreted as loss by reliable | critical applications and can be interpreted as loss by reliable | |||
transports. Many transport protocol techniques are impacted by | transports. Many transport protocol techniques are impacted by | |||
reordering (e.g., triggering TCP retransmission, or re-buffering | reordering (e.g., triggering TCP retransmission, or re-buffering | |||
of real-time applications). Packet reordering can occur for many | of real-time applications). Packet reordering can occur for many | |||
reasons (from equipment design to misconfiguration of forwarding | reasons (from equipment design to misconfiguration of forwarding | |||
rules). Since this impacts transport performance, network tools | rules). Since this impacts transport performance, network tools | |||
are needed to detect and measure unwanted/excessive reordering. | are needed to detect and measure unwanted/excessive reordering. | |||
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 promise to simplify network equipment design as well as the | have promise to simplify network equipment design as well as the | |||
potential to improve robustness of the transport service. | potential to improve robustness of the transport service. | |||
Measurements of reordering can help understand the present level | Measurements of reordering can help understand the present level | |||
of reordering within deployed infrastructure, and inform decisions | of reordering within deployed infrastructure, and inform decisions | |||
about how to progress such mechanisms. | about how to progress such mechanisms. | |||
skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 16 ¶ | |||
rate, etc. | rate, etc. | |||
Metrics have been defined that evaluate whether a network has | Metrics have been defined that evaluate whether a network has | |||
maintained packet order on a packet-by-packet basis [RFC4737] and | maintained packet order on a packet-by-packet basis [RFC4737] and | |||
[RFC5236]. | [RFC5236]. | |||
Techniques for measuring reordering typically observe packet sequence | Techniques for measuring reordering typically observe packet sequence | |||
numbers. Some protocols provide in-built monitoring and reporting | numbers. Some protocols provide in-built monitoring and reporting | |||
functions. Transport fields in the RTP header [RFC3550] [RFC4585] | functions. Transport fields in the RTP header [RFC3550] [RFC4585] | |||
can be observed to derive traffic volume measurements and provide | can be observed to derive traffic volume measurements and provide | |||
information on the progress and quality of a session using RTP. As | information on the progress and quality of a session using RTP. As | |||
with other measurement, metadata is often important to understand the | with other measurement, metadata is often important to understand the | |||
context under which the data was collected, including the time, | context under which the data was collected, including the time, | |||
observation point, and way in which metrics were accumulated. The | observation point, and way in which metrics were accumulated. The | |||
RTCP protocol directly reports some of this information in a form | RTCP protocol directly reports some of this information in a form | |||
that can be directly visible in the network. A user of summary | that can be directly visible in the network. A user of summary | |||
measurement data needs to trust the source of this data and the | measurement data needs to trust the source of this data and the | |||
method used to generate the summary information. | method used to generate the summary information. | |||
2.1.3. Metrics derived from Network Layer Headers | 3.1.3. Metrics derived from Network Layer Headers | |||
Some transport information is made visible in the network-layer | Some transport information is made visible in the network-layer | |||
protocol header. These header fields are not encrypted and have been | protocol header. These header fields are not encrypted and have been | |||
utilised to make flow observations. | utilised to make flow observations. | |||
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose | Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged | |||
flow information in the IPv6 Flow Label field of the network-layer | expose flow information in the IPv6 Flow Label field of the | |||
header (e.g., [RFC8085]). This can be used to inform network-layer | network-layer header (e.g., [RFC8085]). This can be used to | |||
queuing, forwarding (e.g., for Equal Cost Multi-Path, ECMP, | inform network-layer queuing, forwarding (e.g., for Equal Cost | |||
routing, and Link Aggregation, LAG). This can provide useful | Multi-Path, ECMP, routing, and Link Aggregation, LAG). This can | |||
information to assign packets to flows in the data collected by | provide useful information to assign packets to flows in the data | |||
measurement campaigns. Although important to characterising a | collected by measurement campaigns. Although important to | |||
path, it does not directly provide performance data. | characterising a path, it does not directly provide performance | |||
data. | ||||
Use Network-Layer Differentiated Services Code Point Point: Applicati | Use Network-Layer Differentiated Services Code Point Point: | |||
ons can expose their delivery expectations to the network by | Applications can expose their delivery expectations to the network | |||
setting the Differentiated Services Code Point (DSCP) field of | by setting the Differentiated Services Code Point (DSCP) field of | |||
IPv4 and IPv6 packets. This can be used to inform network-layer | IPv4 and IPv6 packets. This can be used to inform network-layer | |||
queuing and forwarding, and can also provide information on the | queuing and forwarding, and can also provide information on the | |||
relative importance of packet information collected by measurement | relative importance of packet information collected by measurement | |||
campaigns, but does not directly provide performance data. | campaigns, but does not directly provide performance data. | |||
This field provides explicit information that can be used in place | This field provides explicit information that can be used in place | |||
of inferring traffic requirements (e.g., by inferring QoS | of inferring traffic requirements (e.g., by inferring QoS | |||
requirements from port information via a multi-field classifier). | requirements from port information via a multi-field classifier). | |||
The DSCP value can therefore impact the quality of experience for | The DSCP value can therefore impact the quality of experience for | |||
a flow. Observations of service performance need to consider this | a flow. Observations of service performance need to consider this | |||
field when a network path has support for differentiated service | field when a network path has support for differentiated service | |||
treatment. | treatment. | |||
Use of Explicit Congestion Marking: ECN [RFC3168] is an optional | Use of Explicit Congestion Marking: ECN [RFC3168] is an optional | |||
transport mechanism that uses a code point in the network-layer | transport mechanism that uses a code point in the network-layer | |||
header. Use of ECN can offer gains in terms of increased | header. Use of ECN can offer gains in terms of increased | |||
throughput, reduced delay, and other benefits when used over a | throughput, reduced delay, and other benefits when used over a | |||
path that includes equipment that supports an AQM method that | path that includes equipment that supports an AQM method that | |||
performs Congestion Experienced (CE) marking of IP packets | performs Congestion Experienced (CE) marking of IP packets | |||
[RFC8087]. | [RFC8087]. | |||
ECN exposes the presence of congestion on a network path to the | ECN exposes the presence of congestion on a network path to the | |||
transport and network layer. The reception of CE-marked packets | transport and network layer. The reception of CE-marked packets | |||
can therefore be used to monitor the presence and estimate the | can therefore be used to monitor the presence and estimate the | |||
level of incipient congestion on the upstream portion of the path | level of incipient congestion on the upstream portion of the path | |||
from the point of observation (Section 2.5 of [RFC8087]). Because | from the point of observation (Section 2.5 of [RFC8087]). Because | |||
ECN marks are carried in the IP protocol header, it is much easier | ECN marks are carried in the IP protocol header, it is much easier | |||
to measure ECN than to measure packet loss. However, interpreting | to measure ECN than to measure packet loss. However, interpreting | |||
the marking behaviour (i.e., assessing congestion and diagnosing | the marking behaviour (i.e., assessing congestion and diagnosing | |||
faults) requires context from the transport layer (path RTT, | faults) requires context from the transport layer (path RTT, | |||
visibility of loss - that could be due to queue overflow, | visibility of loss - that could be due to queue overflow, | |||
congestion response, etc) [RFC7567]. | congestion response, etc) [RFC7567]. | |||
Some ECN-capable network devices can provide richer (more frequent | Some ECN-capable network devices can provide richer (more frequent | |||
and fine-grained) indication of their congestion state. Setting | and fine-grained) indication of their congestion state. Setting | |||
congestion marks proportional to the level of congestion (e.g., | congestion marks proportional to the level of congestion (e.g., | |||
skipping to change at page 14, line 40 ¶ | skipping to change at page 15, line 5 ¶ | |||
ECN-enabled AQM-based networks [RFC8087]. | ECN-enabled AQM-based networks [RFC8087]. | |||
AQM and ECN offer a range of algorithms and configuration options, | AQM and ECN offer a range of algorithms and configuration options, | |||
it is therefore important for tools to be available to network | it is therefore important for tools to be available to network | |||
operators and researchers to understand the implication of | operators and researchers to understand the implication of | |||
configuration choices and transport behaviour as use of ECN | configuration choices and transport behaviour as use of ECN | |||
increases and new methods emerge [RFC7567] [RFC8087]. ECN- | increases and new methods emerge [RFC7567] [RFC8087]. ECN- | |||
monitoring is expected to become important as AQM is deployed that | monitoring is expected to become important as AQM is deployed that | |||
supports ECN [RFC8087]. | supports ECN [RFC8087]. | |||
2.2. Transport Measurement | 3.2. Transport Measurement | |||
The common language between network operators and application/content | The common language between network operators and application/content | |||
providers/users is packet transfer performance at a layer that all | providers/users is packet transfer performance at a layer that all | |||
can view and analyse. For most packets, this has been transport | can view and analyse. For most packets, this has been transport | |||
layer, until the emergence of QUIC, with the obvious exception of | layer, until the emergence of QUIC, with the obvious exception of | |||
Virtual Private Networks (VPNs) and IPsec. | Virtual Private Networks (VPNs) and IPsec. | |||
When encryption conceals more layers in each packet, people seeking | When encryption conceals more layers in each packet, people seeking | |||
understanding of the network operation rely more on pattern | understanding of the network operation rely more on pattern | |||
inferences and other heuristics reliance on pattern inferences and | inferences and other heuristics reliance on pattern inferences and | |||
accuracy suffers. For example, the traffic patterns between server | accuracy suffers. For example, the traffic patterns between server | |||
and browser are dependent on browser supplier and version, even when | and browser are dependent on browser supplier and version, even when | |||
the sessions use the same server application (e.g., web e-mail | the sessions use the same server application (e.g., web e-mail | |||
access). It remains to be seen whether more complex inferences can be | access). It remains to be seen whether more complex inferences can | |||
mastered to produce the same monitoring accuracy (see section 2.1.1 | be mastered to produce the same monitoring accuracy (see section | |||
of [I-D.mm-wg-effect-encrypt]). | 2.1.1 of [RFC8404]). | |||
When measurement datasets are made available by servers or client | When measurement datasets are made available by servers or client | |||
endpoints, additional metadata, such as the state of the network, is | endpoints, additional metadata, such as the state of the network, is | |||
often required to interpret this data. Collecting and coordinating | often required to interpret this data. Collecting and coordinating | |||
such metadata is more difficult when the observation point is at a | such metadata is more difficult when the observation point is at a | |||
different location to the bottleneck/device under evaluation. | different location to the bottleneck/device under evaluation. | |||
Packet sampling techniques can be used to scale the processing | Packet sampling techniques can be used to scale the processing | |||
involved in observing packets on high rate links. This exports only | involved in observing packets on high rate links. This exports only | |||
the packet header information of (randomly) selected packets. The | the packet header information of (randomly) selected packets. The | |||
utility of these measurements depends on the type of bearer and | utility of these measurements depends on the type of bearer and | |||
number of mechanisms used by network devices. Simple routers are | number of mechanisms used by network devices. Simple routers are | |||
relatively easy to manage, a device with more complexity demands | relatively easy to manage, a device with more complexity demands | |||
understanding of the choice of many system parameters. This level of | understanding of the choice of many system parameters. This level of | |||
complexity exists when several network methods are combined. | complexity exists when several network methods are combined. | |||
This section discusses topics concerning observation of transport | This section discusses topics concerning observation of transport | |||
flows, with a focus on transport measurement. | flows, with a focus on transport measurement. | |||
2.2.1. Point of Measurement | 3.2.1. Point of Measurement | |||
Often measurements can only be understood in the context of the other | Often measurements can only be understood in the context of the other | |||
flows that share a bottleneck. A simple example is monitoring of | flows that share a bottleneck. A simple example is monitoring of | |||
AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub | AQM. For example, FQ-CODEL [RFC8290], combines sub queues | |||
queues (statistically assigned per flow), management of the queue | (statistically assigned per flow), management of the queue length | |||
length (CODEL), flow-scheduling, and a starvation prevention | (CODEL), flow-scheduling, and a starvation prevention mechanism. | |||
mechanism. Usually such algorithms are designed to be self-tuning, | Usually such algorithms are designed to be self-tuning, but current | |||
but current methods typically employ heuristics that can result in | methods typically employ heuristics that can result in more loss | |||
more loss under certain path conditions (e.g., large RTT, effects of | under certain path conditions (e.g., large RTT, effects of multiple | |||
multiple bottlenecks [RFC7567]). | bottlenecks [RFC7567]). | |||
In-network measurements can distinguish between upstream and | In-network measurements can distinguish between upstream and | |||
downstream metrics with respect to a measurement point. These are | downstream metrics with respect to a measurement point. These are | |||
particularly useful for locating the source of problems or to assess | particularly useful for locating the source of problems or to assess | |||
the performance of a network segment or a particular device | the performance of a network segment or a particular device | |||
configuration. By correlating observations of headers at multiple | configuration. By correlating observations of headers at multiple | |||
points along the path (e.g., at the ingress and egress of a network | points along the path (e.g., at the ingress and egress of a network | |||
segment), an observer can determine the contribution of a portion of | segment), an observer can determine the contribution of a portion of | |||
the path to an observed metric (to locate a source of delay, jitter, | the path to an observed metric (to locate a source of delay, jitter, | |||
loss, reordering, congestion marking, etc.). | loss, reordering, congestion marking, etc.). | |||
2.2.2. Use by Operators to Plan and Provision Networks | 3.2.2. Use by Operators to Plan and Provision Networks | |||
Traffic measurements (e.g., traffic volume, loss, latency) is used by | Traffic measurements (e.g., traffic volume, loss, latency) is used by | |||
operators to help plan deployment of new equipment and configurations | operators to help plan deployment of new equipment and configurations | |||
in their networks. Data is also important to equipment vendors who | in their networks. Data is also important to equipment vendors who | |||
need to understand traffic trends and patterns of usage as inputs to | need to understand traffic trends and patterns of usage as inputs to | |||
decisions about planning products and provisioning for new | decisions about planning products and provisioning for new | |||
deployments. This measurement information can also be correlated | deployments. This measurement information can also be correlated | |||
with billing information when this is also collected by an operator. | with billing information when this is also collected by an operator. | |||
A network operator supporting traffic that uses transport header | A network operator supporting traffic that uses transport header | |||
encryption may not have access to per-flow measurement data. Trends | encryption may not have access to per-flow measurement data. Trends | |||
in aggregate traffic can be observed and can be related to the | in aggregate traffic can be observed and can be related to the | |||
endpoint addresses being used, but it may not be possible to | endpoint addresses being used, but it may not be possible to | |||
correlate patterns in measurements with changes in transport | correlate patterns in measurements with changes in transport | |||
protocols (e.g., the impact of changes in introducing a new transport | protocols (e.g., the impact of changes in introducing a new transport | |||
protocol mechanism). This increases the dependency on other indirect | protocol mechanism). This increases the dependency on other indirect | |||
sources of information to inform planning and provisioning. | sources of information to inform planning and provisioning. | |||
2.2.3. Service Performance Measurement | 3.2.3. Service Performance Measurement | |||
Traffic measurements (e.g., traffic volume, loss, latency) can be | Traffic measurements (e.g., traffic volume, loss, latency) can be | |||
used by various actors to help analyse the performance offered to the | used by various actors to help analyse the performance offered to the | |||
users of a network segment, and inform operational practice. | users of a network segment, and inform operational practice. | |||
While active measurements may be used in-network, passive | While active measurements may be used in-network, passive | |||
measurements can have advantages in terms of eliminating unproductive | measurements can have advantages in terms of eliminating unproductive | |||
test traffic, reducing the influence of test traffic on the overall | test traffic, reducing the influence of test traffic on the overall | |||
traffic mix, and the ability to choose the point of measurement | traffic mix, and the ability to choose the point of measurement | |||
Section 2.2.1. However, passive measurements may rely on observing | Section 3.2.1. However, passive measurements may rely on observing | |||
transport headers. | transport headers. | |||
2.2.4. Measuring Transport to Support Network Operations | 3.2.4. Measuring Transport to Support Network Operations | |||
Information provided by tools observing transport headers can help | Information provided by tools observing transport headers can help | |||
determine whether mechanisms are needed in the network to prevent | determine whether mechanisms are needed in the network to prevent | |||
flows from acquiring excessive network capacity. Operators can | flows from acquiring excessive network capacity. Operators can | |||
implement operational practices to manage traffic flows (e.g., to | implement operational practices to manage traffic flows (e.g., to | |||
prevent flows from acquiring excessive network capacity under severe | prevent flows from acquiring excessive network capacity under severe | |||
congestion) by deploying rate-limiters, traffic shaping or network | congestion) by deploying rate-limiters, traffic shaping or network | |||
transport circuit breakers [RFC8084]. | transport circuit breakers [RFC8084]. | |||
Congestion Control Compliance of Traffic: Congestion control is a key | Congestion Control Compliance of Traffic: Congestion control is a | |||
transport function [RFC2914]. Many network operators implicitly | key transport function [RFC2914]. Many network operators | |||
accept that TCP traffic to comply with a behaviour that is | implicitly accept that TCP traffic to comply with a behaviour that | |||
acceptable for use in the shared Internet. TCP algorithms have | is acceptable for use in the shared Internet. TCP algorithms have | |||
been continuously improved over decades, and they have reached a | been continuously improved over decades, and they have reached a | |||
level of efficiency and correctness that custom application-layer | level of efficiency and correctness that custom application-layer | |||
mechanisms will struggle to easily duplicate [RFC8085]. | mechanisms will struggle to easily duplicate [RFC8085]. | |||
A standards-compliant TCP stack provides congestion control may | A standards-compliant TCP stack provides congestion control may | |||
therefore be judged safe for use across the Internet. | therefore be judged safe for use across the Internet. | |||
Applications developed on top of well-designed transports can be | Applications developed on top of well-designed transports can be | |||
expected to appropriately control their network usage, reacting | expected to appropriately control their network usage, reacting | |||
when the network experiences congestion, by back-off and reduce | when the network experiences congestion, by back-off and reduce | |||
the load placed on the network. This is the normal expected | the load placed on the network. This is the normal expected | |||
skipping to change at page 17, line 28 ¶ | skipping to change at page 17, line 39 ¶ | |||
congestion control behaviour. Analysing observed packet sequence | congestion control behaviour. Analysing observed packet sequence | |||
numbers can be used to help build confidence that an application | numbers can be used to help build confidence that an application | |||
flow backs-off its share of the network load in the face of | flow backs-off its share of the network load in the face of | |||
persistent congestion, and hence to understand whether the | persistent congestion, and hence to understand whether the | |||
behaviour is appropriate for sharing limited network capacity. | behaviour is appropriate for sharing limited network capacity. | |||
For example, it is common to visualise plots of TCP sequence | For example, it is common to visualise plots of TCP sequence | |||
numbers versus time for a flow to understand how a flow shares | numbers versus time for a flow to understand how a flow shares | |||
available capacity, deduce its dynamics in response to congestion, | available capacity, deduce its dynamics in response to congestion, | |||
etc. | etc. | |||
Congestion Control Compliance for UDP traffic UDP provides a minimal | Congestion Control Compliance for UDP traffic UDP provides a minimal | |||
message-passing datagram transport that has no inherent congestion | message-passing datagram transport that has no inherent congestion | |||
control mechanisms. Because congestion control is critical to the | control mechanisms. Because congestion control is critical to the | |||
stable operation of the Internet, applications and other protocols | stable operation of the Internet, applications and other protocols | |||
that choose to use UDP as a transport are required to employ | that choose to use UDP as a transport are required to employ | |||
mechanisms to prevent congestion collapse, avoid unacceptable | mechanisms to prevent congestion collapse, avoid unacceptable | |||
contributions to jitter/latency, and to establish an acceptable | contributions to jitter/latency, and to establish an acceptable | |||
share of capacity with concurrent traffic [RFC8085]. | share of capacity with concurrent traffic [RFC8085]. | |||
A network operator needs tools to understand if datagram flows | A network operator needs tools to understand if datagram flows | |||
comply with congestion control expectations and therefore whether | comply with congestion control expectations and therefore whether | |||
there is a need to deploy methods such as rate-limiters, transport | there is a need to deploy methods such as rate-limiters, transport | |||
circuit breakers or other methods to enforce acceptable usage for | circuit breakers or other methods to enforce acceptable usage for | |||
the offered service. | the offered service. | |||
UDP flows that expose a well-known header by specifying the format | UDP flows that expose a well-known header by specifying the format | |||
of header fields can allow information to be observed to gain | of header fields can allow information to be observed to gain | |||
understanding of the dynamics of a flow and its congestion control | understanding of the dynamics of a flow and its congestion control | |||
behaviour. For example, tools exist to monitor various aspects of | behaviour. For example, tools exist to monitor various aspects of | |||
the RTP and RTCP header information of real-time flows (see | the RTP and RTCP header information of real-time flows (see | |||
Section 2.1.2. | Section 3.1.2. | |||
3.3. Use for Network Diagnostics and Troubleshooting | ||||
2.3. Use for Network Diagnostics and Troubleshooting | ||||
Transport header information can be useful for a variety of | Transport header information can be useful for a variety of | |||
operational tasks [I-D.mm-wg-effect-encrypt]: to diagnose network | operational tasks [RFC8404]: to diagnose network problems, assess | |||
problems, assess network provider performance, evaluate equipment/ | network provider performance, evaluate equipment/protocol | |||
protocol performance, capacity planning, management of security | performance, capacity planning, management of security threats | |||
threats (including denial of service), and responding to user | (including denial of service), and responding to user performance | |||
performance questions. Sections 3.1.2 and 5 of [I-D.mm-wg-effect- | questions. Sections 3.1.2 and 5 of [RFC8404] provide further | |||
encrypt] provide further examples. These tasks seldom involve the | examples. These tasks seldom involve the need to determine the | |||
need to determine the contents of the transport payload, or other | contents of the transport payload, or other application details. | |||
application details. | ||||
A network operator supporting traffic that uses transport header | A network operator supporting traffic that uses transport header | |||
encryption can see only encrypted transport headers. This prevents | encryption can see only encrypted transport headers. This prevents | |||
deployment of performance measurement tools that rely on transport | deployment of performance measurement tools that rely on transport | |||
protocol information. Choosing to encrypt all the information | protocol information. Choosing to encrypt all the information | |||
reduces the operator's ability to observe transport performance, and | reduces the operator's ability to observe transport performance, and | |||
may limit the ability of network operators to trace problems, make | may limit the ability of network operators to trace problems, make | |||
appropriate QoS decisions, or response to other queries about the | appropriate QoS decisions, or response to other queries about the | |||
network service. For some this will be blessing, for others it may | network service. For some this will be blessing, for others it may | |||
be a curse. For example, operational performance data about | be a curse. For example, operational performance data about | |||
encrypted flows needs to be determined by traffic pattern analysis, | encrypted flows needs to be determined by traffic pattern analysis, | |||
rather than relying on traditional tools. This can impact the | rather than relying on traditional tools. This can impact the | |||
ability of the operator to respond to faults, it could require | ability of the operator to respond to faults, it could require | |||
reliance on endpoint diagnostic tools or user involvement in | reliance on endpoint diagnostic tools or user involvement in | |||
diagnosing and troubleshooting unusual use cases or non-trivial | diagnosing and troubleshooting unusual use cases or non-trivial | |||
problems. A key need here is for tools to provide useful information | problems. A key need here is for tools to provide useful information | |||
during network anomalies (e.g., significant reordering, high or | during network anomalies (e.g., significant reordering, high or | |||
intermittent loss). Although many network operators utilise transport | intermittent loss). Although many network operators utilise | |||
information as a part of their operational practice, the network will | transport information as a part of their operational practice, the | |||
not break because transport headers are encrypted, and this may | network will not break because transport headers are encrypted, and | |||
require alternative tools may need to be developed and deployed. | this may require alternative tools may need to be developed and | |||
deployed. | ||||
2.3.1. Examples of measurements | 3.3.1. Examples of measurements | |||
Measurements can be used to monitor the health of a portion of the | Measurements can be used to monitor the health of a portion of the | |||
Internet, to provide early warning of the need to take action. They | Internet, to provide early warning of the need to take action. They | |||
can assist in debugging and diagnosing the root causes of faults that | can assist in debugging and diagnosing the root causes of faults that | |||
concern a particular user's traffic. They can also be used to | concern a particular user's traffic. They can also be used to | |||
support post-mortem investigation after an anomaly to determine the | support post-mortem investigation after an anomaly to determine the | |||
root cause of a problem. | root cause of a problem. | |||
In some case, measurements may involve active injection of test | In some case, measurements may involve active injection of test | |||
traffic to complete a measurement. However, most operators do not | traffic to complete a measurement. However, most operators do not | |||
have access to user equipment, and injection of test traffic may be | have access to user equipment, and injection of test traffic may be | |||
associated with costs in running such tests (e.g., the implications | associated with costs in running such tests (e.g., the implications | |||
of bandwidth tests in a mobile network are obvious). Some active | of bandwidth tests in a mobile network are obvious). Some active | |||
measurements (e.g., response under load or particular workloads) | measurements (e.g., response under load or particular workloads) | |||
perturb other traffic, and could require dedicated access to the | perturb other traffic, and could require dedicated access to the | |||
network segment. An alternative approach is to use in-network | network segment. An alternative approach is to use in-network | |||
techniques that observe transport packet headers in operational | techniques that observe transport packet headers in operational | |||
networks to make the measurements. | networks to make the measurements. | |||
In other cases, measurement involves dissecting network traffic | In other cases, measurement involves dissecting network traffic | |||
flows. The observed transport layer information can help identify | flows. The observed transport layer information can help identify | |||
whether the link/network tuning is effective and alert to potential | whether the link/network tuning is effective and alert to potential | |||
problems that can be hard to derive from link or device measurements | problems that can be hard to derive from link or device measurements | |||
skipping to change at page 19, line 22 ¶ | skipping to change at page 19, line 36 ¶ | |||
to-point radio) has the complexity of a subsystem that performs radio | to-point radio) has the complexity of a subsystem that performs radio | |||
resource management,s with direct impact on the available capacity, | resource management,s with direct impact on the available capacity, | |||
and potentially loss/reordering of packets. The impact of the | and potentially loss/reordering of packets. The impact of the | |||
pattern of loss and congestion, differs for different traffic types, | pattern of loss and congestion, differs for different traffic types, | |||
correlation with propagation and interference can all have | correlation with propagation and interference can all have | |||
significant impact on the cost and performance of a provided service. | significant impact on the cost and performance of a provided service. | |||
The need for this type of information is expected to increase as | The need for this type of information is expected to increase as | |||
operators bring together heterogeneous types of network equipment and | operators bring together heterogeneous types of network equipment and | |||
seek to deploy opportunistic methods to access radio spectrum. | seek to deploy opportunistic methods to access radio spectrum. | |||
2.4. Observing Headers to Implement Network Policy | 3.4. Observing Headers to Implement Network Policy | |||
Information from the transport protocol can be used by a multi-field | Information from the transport protocol can be used by a multi-field | |||
classifier as a part of policy framework. Policies are commonly used | classifier as a part of policy framework. Policies are commonly used | |||
for management of the QoS or Quality of Experience (QoE) in resource- | for management of the QoS or Quality of Experience (QoE) in resource- | |||
constrained networks and by firewalls that use the information to | constrained networks and by firewalls that use the information to | |||
implement access rules (see also section 2.2.2 of [I-D.mm-wg-effect- | implement access rules (see also section 2.2.2 of [RFC8404]). | |||
encrypt]). Traffic that cannot be classified, will typically receive | Traffic that cannot be classified, will typically receive a default | |||
a default treatment. | treatment. | |||
3. Encryption and Authentication of Transport Headers | 4. Encryption and Authentication of Transport Headers | |||
End-to-end encryption can be applied at various protocol layers. It | End-to-end encryption can be applied at various protocol layers. It | |||
can be applied above the transport to encrypt the transport payload. | can be applied above the transport to encrypt the transport payload. | |||
Encryption methods can hide information from an eavesdropper in the | Encryption methods can hide information from an eavesdropper in the | |||
network. Encryption can also help protect the privacy of a user, by | network. Encryption can also help protect the privacy of a user, by | |||
hiding data relating to user/device identity or location. Neither an | hiding data relating to user/device identity or location. Neither an | |||
integrity check nor encryption methods prevent traffic analysis, and | integrity check nor encryption methods prevent traffic analysis, and | |||
usage needs to reflect that profiling of users, identification of | usage needs to reflect that profiling of users, identification of | |||
location and fingerprinting of behaviour can take place even on | location and fingerprinting of behaviour can take place even on | |||
encrypted traffic flows. | encrypted traffic flows. | |||
skipping to change at page 20, line 13 ¶ | skipping to change at page 20, line 20 ¶ | |||
There are several motivations: | There are several motivations: | |||
o One motive to use encryption is a response to perceptions that the | o One motive to use encryption is a response to perceptions that the | |||
network has become ossified by over-reliance on middleboxes that | network has become ossified by over-reliance on middleboxes that | |||
prevent new protocols and mechanisms from being deployed. This | prevent new protocols and mechanisms from being deployed. This | |||
has lead to a perception that there is too much "manipulation" of | has lead to a perception that there is too much "manipulation" of | |||
protocol headers within the network, and that designing to deploy | protocol headers within the network, and that designing to deploy | |||
in such networks is preventing transport evolution. In the light | in such networks is preventing transport evolution. In the light | |||
of this, a method that authenticates transport headers may help | of this, a method that authenticates transport headers may help | |||
improve the pace of transport development, by eliminating the need | improve the pace of transport development, by eliminating the need | |||
to always consider deployed middleboxes [I-D.trammell-plus- | to always consider deployed middleboxes | |||
abstract-mech], or potentially to only explicitly enable middlebox | [I-D.trammell-plus-abstract-mech], or potentially to only | |||
use for particular paths with particular middleboxes that are | explicitly enable middlebox use for particular paths with | |||
deliberately deployed to realise a useful function for the network | particular middleboxes that are deliberately deployed to realise a | |||
and/or users[RFC3135]. | useful function for the network and/or users[RFC3135]. | |||
o Another motivation stems from increased concerns about privacy and | o Another motivation stems from increased concerns about privacy and | |||
surveillance. Some Internet users have valued the ability to | surveillance. Some Internet users have valued the ability to | |||
protect identity, user location, and defend against traffic | protect identity, user location, and defend against traffic | |||
analysis, and have used methods such as IPsec Encapsulated | analysis, and have used methods such as IPsec Encapsulated | |||
Security Payload (ESP), Virtual Private Networks (VPNs) and other | Security Payload (ESP), Virtual Private Networks (VPNs) and other | |||
encrypted tunnel technologies. Revelations about the use of | encrypted tunnel technologies. Revelations about the use of | |||
pervasive surveillance [RFC7624] have, to some extent, eroded | pervasive surveillance [RFC7624] have, to some extent, eroded | |||
trust in the service offered by network operators, and following | trust in the service offered by network operators, and following | |||
the Snowden revelation in the USA in 2013 has led to an increased | the Snowden revelation in the USA in 2013 has led to an increased | |||
desire for people to employ encryption to avoid unwanted | desire for people to employ encryption to avoid unwanted | |||
"eavesdropping" on their communications. Concerns have also been | "eavesdropping" on their communications. Concerns have also been | |||
voiced about the addition of information to packets by third | voiced about the addition of information to packets by third | |||
parties to provide analytics, customization, advertising, cross- | parties to provide analytics, customization, advertising, cross- | |||
site tracking of users, to bill the customer, or to selectively | site tracking of users, to bill the customer, or to selectively | |||
allow or block content. Whatever the reasons, there are now | allow or block content. Whatever the reasons, there are now | |||
activities in the IETF to design new protocols that may include | activities in the IETF to design new protocols that may include | |||
some form of transport header encryption (e.g., QUIC [I-D.ietf- | some form of transport header encryption (e.g., QUIC | |||
quic-transport]). | [I-D.ietf-quic-transport]). | |||
Authentication methods (that provide integrity checks of protocols | Authentication methods (that provide integrity checks of protocols | |||
fields) have also been specified at the network layer, and this also | fields) have also been specified at the network layer, and this also | |||
protects transport header fields. The network layer itself carries | protects transport header fields. The network layer itself carries | |||
protocol header fields that are increasingly used to help forwarding | protocol header fields that are increasingly used to help forwarding | |||
decisions reflect the need of transport protocols, such as the IPv6 | decisions reflect the need of transport protocols, such as the IPv6 | |||
Flow Label [RFC6437], the DSCP and ECN. | Flow Label [RFC6437], the DSCP and ECN. | |||
The use of transport layer authentication and encryption exposes a | The use of transport layer authentication and encryption exposes a | |||
tussle between middlebox vendors, operators, applications developers | tussle between middlebox vendors, operators, applications developers | |||
skipping to change at page 21, line 15 ¶ | skipping to change at page 21, line 28 ¶ | |||
Whatever the motives, a decision to use pervasive of transport header | Whatever the motives, a decision to use pervasive of transport header | |||
encryption will have implications on the way in which design and | encryption will have implications on the way in which design and | |||
evaluation is performed, and which can in turn impact the direction | evaluation is performed, and which can in turn impact the direction | |||
of evolution of the TCP/IP stack. While the IETF can specify | of evolution of the TCP/IP stack. While the IETF can specify | |||
protocols, the success in actual deployment is often determined by | protocols, the success in actual deployment is often determined by | |||
many factors [RFC5218] that are not always clear at the time when | many factors [RFC5218] that are not always clear at the time when | |||
protocols are being defined. | protocols are being defined. | |||
The next subsections briefly review some security design options for | The next subsections briefly review some security design options for | |||
transport protocols. A Survey of Transport Security Protocols [I-D | transport protocols. A Survey of Transport Security Protocols | |||
.ietf-taps-transport-security] provides more details concerning | [I-D.ietf-taps-transport-security] provides more details concerning | |||
commonly used encryption methods at the transport layer. | commonly used encryption methods at the transport layer. | |||
3.1. Authenticating the Transport Protocol Header | 4.1. Authenticating the Transport Protocol Header | |||
Transport layer header information can be authenticated. An | Transport layer header information can be authenticated. An | |||
integrity check that protects the immutable transport header fields, | integrity check that protects the immutable transport header fields, | |||
but can still expose the transport protocol header information in the | but can still expose the transport protocol header information in the | |||
clear, allowing in-network devices to observes these fields. An | clear, allowing in-network devices to observes these fields. An | |||
integrity check can not prevent in-network modification, but can | integrity check can not prevent in-network modification, but can | |||
avoid a receiving accepting changes and avoid impact on the transport | avoid a receiving accepting changes and avoid impact on the transport | |||
protocol operation. | protocol operation. | |||
An example transport authentication mechanism is TCP-Authentication | An example transport authentication mechanism is TCP-Authentication | |||
skipping to change at page 21, line 41 ¶ | skipping to change at page 22, line 5 ¶ | |||
header, TCP header, and TCP data. TCP-AO protects the transport | header, TCP header, and TCP data. TCP-AO protects the transport | |||
layer, preventing attacks from disabling the TCP connection itself | layer, preventing attacks from disabling the TCP connection itself | |||
and provides replay protection. TCP-AO may interact with | and provides replay protection. TCP-AO may interact with | |||
middleboxes, depending on their behaviour [RFC3234]. | middleboxes, depending on their behaviour [RFC3234]. | |||
The IPsec Authentication Header (AH) [RFC4302] was designed to work | The IPsec Authentication Header (AH) [RFC4302] was designed to work | |||
at the network layer and authenticate the IP payload. This approach | at the network layer and authenticate the IP payload. This approach | |||
authenticates all transport headers, and verifies their integrity at | authenticates all transport headers, and verifies their integrity at | |||
the receiver, preventing in-network modification. | the receiver, preventing in-network modification. | |||
3.2. Encrypting the Transport Payload | 4.2. Encrypting the Transport Payload | |||
The transport layer payload can be encrypted to protect the content | The transport layer payload can be encrypted to protect the content | |||
of transport segments. This leaves transport protocol header | of transport segments. This leaves transport protocol header | |||
information in the clear. The integrity of immutable transport | information in the clear. The integrity of immutable transport | |||
header fields could be protected by combining this with an integrity | header fields could be protected by combining this with an integrity | |||
check (Section 3.1). | check (Section 4.1). | |||
Examples of encrypting the payload include Transport Layer Security | Examples of encrypting the payload include Transport Layer Security | |||
(TLS) over TCP [RFC5246] [RFC7525], Datagram TLS (DTLS) over UDP | (TLS) over TCP [RFC5246] [RFC7525], Datagram TLS (DTLS) over UDP | |||
[RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which | [RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which | |||
permits opportunistic encryption of the TCP transport payload. | permits opportunistic encryption of the TCP transport payload. | |||
3.3. Encrypting the Transport Header | 4.3. Encrypting the Transport Header | |||
The network layer payload could be encrypted (including the entire | The network layer payload could be encrypted (including the entire | |||
transport header and the payload). This method provides | transport header and the payload). This method provides | |||
confidentiality of the entire transport packet. It therefore does | confidentiality of the entire transport packet. It therefore does | |||
not expose any transport information to devices in the network, which | not expose any transport information to devices in the network, which | |||
also prevents modification along a network path. | also prevents modification along a network path. | |||
One example of encryption at the network layer is use of IPsec | One example of encryption at the network layer is use of IPsec | |||
Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This | Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This | |||
encrypts and authenticates all transport headers, preventing | encrypts and authenticates all transport headers, preventing | |||
visibility of the transport headers by in-network devices. Some | visibility of the transport headers by in-network devices. Some | |||
Virtual Private Network (VPN) methods also encrypt these headers. | Virtual Private Network (VPN) methods also encrypt these headers. | |||
3.4. Authenticating Transport Information and Selectively Encrypting | 4.4. Authenticating Transport Information and Selectively Encrypting | |||
the Transport Header | the Transport Header | |||
A transport protocol design can encrypt selected header fields, while | A transport protocol design can encrypt selected header fields, while | |||
also choosing to authenticate fields in the transport header. This | also choosing to authenticate fields in the transport header. This | |||
allows specific transport header fields to be made observable by | allows specific transport header fields to be made observable by | |||
network devices. End-to end integrity checks can prevent an endpoint | network devices. End-to end integrity checks can prevent an endpoint | |||
from undetected modification of the immutable transport headers. | from undetected modification of the immutable transport headers. | |||
Mutable fields in the transport header provide opportunities for | Mutable fields in the transport header provide opportunities for | |||
middleboxes to modify the transport behaviour (e.g., the extended | middleboxes to modify the transport behaviour (e.g., the extended | |||
headers described in [I-D.trammell-plus-abstract-mech]). This | headers described in [I-D.trammell-plus-abstract-mech]). This | |||
considers only immutable fields in the transport headers, that is, | considers only immutable fields in the transport headers, that is, | |||
fields that may be authenticated End-to-End across a path. | fields that may be authenticated End-to-End across a path. | |||
An example of a method that encrypts some, but not all, transport | An example of a method that encrypts some, but not all, transport | |||
information is GRE-in-UDP [RFC8086] when used with GRE encryption. | information is GRE-in-UDP [RFC8086] when used with GRE encryption. | |||
3.5. Optional Encryption of Header Information | 4.5. Optional Encryption of Header Information | |||
There are implications to the use of optional header encryption in | There are implications to the use of optional header encryption in | |||
the design of a transport protocol, where support of optional | the design of a transport protocol, where support of optional | |||
mechanisms can increase the complexity of the protocol and its | mechanisms can increase the complexity of the protocol and its | |||
implementation and in the management decisions that are required to | implementation and in the management decisions that are required to | |||
use variable format fields. Instead, fields of a specific type ought | use variable format fields. Instead, fields of a specific type ought | |||
to always be sent with the same level of confidentiality or integrity | to always be sent with the same level of confidentiality or integrity | |||
protection. | protection. | |||
4. Addition of Transport Information to Network-Layer Protocol Headers | 5. Addition of Transport Information to Network-Layer Protocol Headers | |||
Transport protocol information can be made visible in a network-layer | Transport protocol information can be made visible in a network-layer | |||
header. This has the advantage that this information can then be | header. This has the advantage that this information can then be | |||
observed by in-network devices. This has the advantage that a single | observed by in-network devices. This has the advantage that a single | |||
header can support all transport protocols, but there may also be | header can support all transport protocols, but there may also be | |||
less desirable implications of separating the operation of the | less desirable implications of separating the operation of the | |||
transport protocol from the measurement framework. | transport protocol from the measurement framework. | |||
Some measurements may be made by adding additional protocol headers | Some measurements may be made by adding additional protocol headers | |||
carrying operations, administration and management (OAM) information | carrying operations, administration and management (OAM) information | |||
skipping to change at page 23, line 19 ¶ | skipping to change at page 23, line 38 ¶ | |||
a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) | a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) | |||
and removing the additional header at the egress of the maintenance | and removing the additional header at the egress of the maintenance | |||
domain. This approach enables some types of measurements, but does | domain. This approach enables some types of measurements, but 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 required segments/nodes and there can be challenges in | tools at the required segments/nodes and there can be challenges in | |||
correlating the downsream/upstream information when in-band OAM data | correlating the downsream/upstream information when in-band OAM data | |||
is inserted by an on-path device. | is inserted by an on-path device. | |||
Another example of a network-layer approach is the IPv6 Performance | Another example of a network-layer approach is the IPv6 Performance | |||
and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- | and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This | |||
pdm-option]. This allows a sender to optionally include a | allows a sender to optionally include a destination option that | |||
destination option that caries header fields that can be used to | caries header fields that can be used to observe timestamps and | |||
observe timestamps and packet sequence numbers. This information | packet sequence numbers. This information could be authenticated by | |||
could be authenticated by receiving transport endpoints when the | receiving transport endpoints when the information is added at the | |||
information is added at the sender and visible at the receiving | sender and visible at the receiving endpoint, although methods to do | |||
endpoint, although methods to do this have not currently been | this have not currently been proposed. This method needs to be | |||
proposed. This method needs to be explicitly enabled at the sender. | explicitly enabled at the sender. | |||
It can be undesirable to rely on methods requiring the presence of | It can be undesirable to rely on methods requiring the presence of | |||
network options or extension headers. IPv4 network options are often | network options or extension headers. IPv4 network options are often | |||
not supported (or are carried on a slower processing path) and some | not supported (or are carried on a slower processing path) and some | |||
IPv6 networks are also known to drop packets that set an IPv6 header | IPv6 networks are also known to drop packets that set an IPv6 header | |||
extension (e.g., [RFC7872]). Another disadvantage is that protocols | extension (e.g., [RFC7872]). Another disadvantage is that protocols | |||
that separately expose header information do not necessarily have an | that separately expose header information do not necessarily have an | |||
advantage to expose the information that is utilised by the protocol | advantage to expose the information that is utilised by the protocol | |||
itself, and could manipulate this header information to gain an | itself, and could manipulate this header information to gain an | |||
advantage from the network. | advantage from the network. | |||
5. Implications of Protecting the Transport Headers | 6. Implications of Protecting the Transport Headers | |||
The choice of which fields to expose and which to encrypt is a design | The choice of which fields to expose and which to encrypt is a design | |||
choice for the transport protocol. Any selective encryption method | choice for the transport protocol. Any selective encryption method | |||
requires trading two conflicting goals for a transport protocol | requires trading two conflicting goals for a transport protocol | |||
designer to decide which header fields to encrypt. Security work | designer to decide which header fields to encrypt. Security work | |||
typically employs a design technique that seeks to expose only what | typically employs a design technique that seeks to expose only what | |||
is needed. However, there can be performance and operational | is needed. However, there can be performance and operational | |||
benefits in exposing selected information to network tools. | benefits in exposing selected information to network tools. | |||
This section explores key implications of working with encrypted | This section explores key implications of working with encrypted | |||
transport protocols. | transport protocols. | |||
5.1. Independent Measurement | 6.1. Independent Measurement | |||
Independent observation by multiple actors is important for | Independent observation by multiple actors is important for | |||
scientific analysis. Encrypting transport header encryption changes | scientific analysis. Encrypting transport header encryption changes | |||
the ability for other actors to collect and independently analyse | the ability for other actors to collect and independently analyse | |||
data. Internet transport protocols employ a set of mechanisms. Some | data. Internet transport protocols employ a set of mechanisms. Some | |||
of these need to work in cooperation with the network layer - loss | of these need to work in cooperation with the network layer - loss | |||
detection and recovery, congestion detection and congestion control, | detection and recovery, congestion detection and congestion control, | |||
some of these need to work only End-to-End (e.g., parameter | some of these need to work only End-to-End (e.g., parameter | |||
negotiation, flow-control). | negotiation, flow-control). | |||
When encryption conceals information in the transport header, it | When encryption conceals information in the transport header, it | |||
skipping to change at page 24, line 33 ¶ | skipping to change at page 25, line 5 ¶ | |||
information. Protocols that expose the state information used by the | information. Protocols that expose the state information used by the | |||
transport protocol in their header information (e.g., timestamps used | transport protocol in their header information (e.g., timestamps used | |||
to calculate the RTT, packet numbers used to asses congestion and | to calculate the RTT, packet numbers used to asses congestion and | |||
requests for retransmission) provide an incentive for the sending | requests for retransmission) provide an incentive for the sending | |||
endpoint to provide correct information, increasing confidence that | endpoint to provide correct information, increasing confidence that | |||
the observer understands the transport interaction with the network. | the observer understands the transport interaction with the network. | |||
This becomes important when considering changes to transport | This becomes important when considering changes to transport | |||
protocols, changes in network infrastructure, or the emergence of new | protocols, changes in network infrastructure, or the emergence of new | |||
traffic patterns. | traffic patterns. | |||
5.2. Characterising "Unknown" Network Traffic | 6.2. Characterising "Unknown" Network Traffic | |||
The patterns and types of traffic that share Internet capacity | The patterns and types of traffic that share Internet capacity | |||
changes with time as networked applications, usage patterns and | changes with time as networked applications, usage patterns and | |||
protocols continue to evolve. | protocols continue to evolve. | |||
If "unknown" or "uncharacterised" traffic patterns form a small part | If "unknown" or "uncharacterised" traffic patterns form a small part | |||
of the traffic aggregate passing through a network device or segment | of the traffic aggregate passing through a network device or segment | |||
of the network the path, the dynamics of the uncharacterised traffic | of the network the path, the dynamics of the uncharacterised traffic | |||
may not have a significant collateral impact on the performance of | may not have a significant collateral impact on the performance of | |||
other traffic that shares this network segment. Once the proportion | other traffic that shares this network segment. Once the proportion | |||
skipping to change at page 25, line 4 ¶ | skipping to change at page 25, line 22 ¶ | |||
of the traffic aggregate passing through a network device or segment | of the traffic aggregate passing through a network device or segment | |||
of the network the path, the dynamics of the uncharacterised traffic | of the network the path, the dynamics of the uncharacterised traffic | |||
may not have a significant collateral impact on the performance of | may not have a significant collateral impact on the performance of | |||
other traffic that shares this network segment. Once the proportion | other traffic that shares this network segment. Once the proportion | |||
of this traffic increases, the need to monitor the traffic and | of this traffic increases, the need to monitor the traffic and | |||
determine if appropriate safety measures need to be put in place. | determine if appropriate safety measures need to be put in place. | |||
Tracking the impact of new mechanisms and protocols requires traffic | Tracking the impact of new mechanisms and protocols requires traffic | |||
volume to be measured and new transport behaviours to be identified. | volume to be measured and new transport behaviours to be identified. | |||
This is especially true of protocols operating over a UDP substrate. | This is especially true of protocols operating over a UDP substrate. | |||
The level and style of encryption needs to be considered in | The level and style of encryption needs to be considered in | |||
determining how this activity is performed. On a shorter timescale, | determining how this activity is performed. On a shorter timescale, | |||
information may also need to be collected to manage denial of service | information may also need to be collected to manage denial of service | |||
attacks against the infrastructure. | attacks against the infrastructure. | |||
5.3. Accountability and Internet Transport Protocols | 6.3. Accountability and Internet Transport Protocols | |||
Information provided by tools observing transport headers can be used | Information provided by tools observing transport headers can be used | |||
to classify traffic, and to limit the network capacity used by | to classify traffic, and to limit the network capacity used by | |||
certain flows. Operators can potentially use this information to | certain flows. Operators can potentially use this information to | |||
prioritise or de-prioritise certain flows or classes of flow, with | prioritise or de-prioritise certain flows or classes of flow, with | |||
potential implications for network neutrality, or to rate limit | potential implications for network neutrality, or to rate limit | |||
malicious or otherwise undesirable flows (e.g., for Distributed | malicious or otherwise undesirable flows (e.g., for Distributed | |||
Denial of Service, DDOS, protection, or to ensure compliance with a | Denial of Service, DDOS, protection, or to ensure compliance with a | |||
traffic profile Section 2.2.4). Equally, operators could use analysis | traffic profile Section 3.2.4). Equally, operators could use | |||
of transport headers and transport flow state to demonstrate that | analysis of transport headers and transport flow state to demonstrate | |||
they are not providing differential treatment to certain flows. | that they are not providing differential treatment to certain flows. | |||
Obfuscating or hiding this information using encryption is expected | Obfuscating or hiding this information using encryption is expected | |||
to lead operators and maintainers of middleboxes (firewalls, etc.) to | to lead operators and maintainers of middleboxes (firewalls, etc.) to | |||
seek other methods to classify, and potentially other mechanisms to | seek other methods to classify, and potentially other mechanisms to | |||
condition, network traffic. | condition, network traffic. | |||
A lack of data reduces the level of precision with which flows can be | A lack of data reduces the level of precision with which flows can be | |||
classified and conditioning mechanisms are applied (e.g., rate | classified and conditioning mechanisms are applied (e.g., rate | |||
limiting, circuit breaker techniques [RFC8084], or blocking of | limiting, circuit breaker techniques [RFC8084], or blocking of | |||
uncharacterised traffic), and this needs to be considered when | uncharacterised traffic), and this needs to be considered when | |||
evaluating the impact of designs for transport encryption [RFC5218]. | evaluating the impact of designs for transport encryption [RFC5218]. | |||
5.4. Impact on Research, Development and Deployment | 6.4. Impact on Research, Development and Deployment | |||
The majority of present Internet applications use two well-known | The majority of present Internet applications use two well-known | |||
transport protocols: e.g., TCP and UDP. Although TCP represents the | transport protocols: e.g., TCP and UDP. Although TCP represents the | |||
majority of current traffic, some important real-time applications | majority of current traffic, some important real-time applications | |||
use UDP, and much of this traffic utilises RTP format headers in the | use UDP, and much of this traffic utilises RTP format headers in the | |||
payload of the UDP datagram. Since these protocol headers have been | payload of the UDP datagram. Since these protocol headers have been | |||
fixed for decades, a range of tools and analysis methods have became | fixed for decades, a range of tools and analysis methods have became | |||
common and well-understood. Over this period, the transport protocol | common and well-understood. Over this period, the transport protocol | |||
headers have mostly changed slowly, and so also the need to develop | headers have mostly changed slowly, and so also the need to develop | |||
tools track new versions of the protocol. | tools track new versions of the protocol. | |||
Looking ahead, there will be a need to update these protocols and to | Looking ahead, there will be a need to update these protocols and to | |||
develop and deploy new transport mechanisms and protocols. There are | develop and deploy new transport mechanisms and protocols. There are | |||
skipping to change at page 26, line 26 ¶ | skipping to change at page 26, line 36 ¶ | |||
opportunity for greater freedom to update the protocols and can ease | opportunity for greater freedom to update the protocols and can ease | |||
experimentation with new techniques and their final deployment in | experimentation with new techniques and their final deployment in | |||
endpoints. | endpoints. | |||
Hiding headers can limit the ability to measure and characterise | Hiding headers can limit the ability to measure and characterise | |||
traffic. Measurement data is increasingly being used to inform | traffic. Measurement data is increasingly being used to inform | |||
design decisions in networking research, during development of new | design decisions in networking research, during development of new | |||
mechanisms and protocols and in standardisation. Measurement has a | mechanisms and protocols and in standardisation. Measurement has a | |||
critical role in the design of transport protocol mechanisms and | critical role in the design of transport protocol mechanisms and | |||
their acceptance by the wider community (e.g., as a method to judge | their acceptance by the wider community (e.g., as a method to judge | |||
the safety for Internet deployment). Observation of pathologies are | the safety for Internet deployment). Observation of pathologies are | |||
also important in understanding the interactions between cooperating | also important in understanding the interactions between cooperating | |||
protocols and network mechanism, the implications of sharing capacity | protocols and network mechanism, the implications of sharing capacity | |||
with other traffic and the impact of different patterns of usage. | with other traffic and the impact of different patterns of usage. | |||
Evolution and the ability to understand (measure) the impact need to | Evolution and the ability to understand (measure) the impact need to | |||
proceed hand-in-hand. Attention needs to be paid to the expected | proceed hand-in-hand. Attention needs to be paid to the expected | |||
scale of deployment of new protocols and protocol mechanisms. | scale of deployment of new protocols and protocol mechanisms. | |||
Whatever the mechanism, experience has shown that it is often | Whatever the mechanism, experience has shown that it is often | |||
difficult to correctly implement combination of mechanisms [RFC8085]. | difficult to correctly implement combination of mechanisms [RFC8085]. | |||
These mechanisms therefore typically evolve as a protocol matures, or | These mechanisms therefore typically evolve as a protocol matures, or | |||
skipping to change at page 27, line 11 ¶ | skipping to change at page 27, line 23 ¶ | |||
a body of data reflecting its behaviour under a wide range of | a body of data reflecting its behaviour under a wide range of | |||
deployment scenarios, traffic load, and interactions with other | deployment scenarios, traffic load, and interactions with other | |||
deployed/candidate methods. | deployed/candidate methods. | |||
Open standards motivate a desire for this evaluation to include | Open standards motivate a desire for this evaluation to include | |||
independent observation and evaluation of performance data, which in | independent observation and evaluation of performance data, which in | |||
turn suggests control over where and when measurement samples are | turn suggests control over where and when measurement samples are | |||
collected. This requires consideration of the appropriate balance | collected. This requires consideration of the appropriate balance | |||
between encrypting all and no transport information. | between encrypting all and no transport information. | |||
6. Conclusions | 7. Conclusions | |||
The majority of present Internet applications use two well-known | The majority of present Internet applications use two well-known | |||
transport protocols: e.g., TCP and UDP. Although TCP represents the | transport protocols: e.g., TCP and UDP. Although TCP represents the | |||
majority of current traffic, some important real-time applications | majority of current traffic, some important real-time applications | |||
have used UDP, and much of this traffic utilises RTP format headers | have used UDP, and much of this traffic utilises RTP format headers | |||
in the payload of the UDP datagram. Since these protocol headers | in the payload of the UDP datagram. Since these protocol headers | |||
have been fixed for decades, a range of tools and analysis methods | have been fixed for decades, a range of tools and analysis methods | |||
have became common and well-understood. Over this period, the | have became common and well-understood. Over this period, the | |||
transport protocol headers have mostly changed slowly, and so also | transport protocol headers have mostly changed slowly, and so also | |||
the need to develop tools track new versions of the protocol. | the need to develop tools track new versions of the protocol. | |||
Confidentiality and strong integrity checks have properties that are | Confidentiality and strong integrity checks have properties that are | |||
being incorporated into new protocols and which have important | being incorporated into new protocols and which have important | |||
skipping to change at page 28, line 13 ¶ | skipping to change at page 28, line 19 ¶ | |||
appropriate operational support functions and procedures. | appropriate operational support functions and procedures. | |||
Protocols that change their transport header format (wire format) or | Protocols that change their transport header format (wire format) or | |||
their behaviour (e.g., algorithms that are needed to classify and | their behaviour (e.g., algorithms that are needed to classify and | |||
characterise the protocol), will require new tooling needs to be | characterise the protocol), will require new tooling needs to be | |||
developed to catch-up with the changes. If the currently deployed | developed to catch-up with the changes. If the currently deployed | |||
tools and methods are no longer relevant and performance may not be | tools and methods are no longer relevant and performance may not be | |||
correctly measured. This can increase the response-time after | correctly measured. This can increase the response-time after | |||
faults, and can impact the ability to manage the network resulting in | faults, and can impact the ability to manage the network resulting in | |||
traffic causing traffic to be treated inappropriately (e.g., rate | traffic causing traffic to be treated inappropriately (e.g., rate | |||
limiting because of being incorrectly classified/monitored). There | limiting because of being incorrectly classified/monitored). There | |||
are benefits in exposing consistent information to the network that | are benefits in exposing consistent information to the network that | |||
avoids traffic being mis-classified and then receiving a default | avoids traffic being mis-classified and then receiving a default | |||
treatment by the network. | treatment by the network. | |||
As a part of its design a new protocol specification therefore needs | As a part of its design a new protocol specification therefore needs | |||
to weigh the benefits of ossifying common headers, versus the | to weigh the benefits of ossifying common headers, versus the | |||
potential demerits of exposing specific information that could be | potential demerits of exposing specific information that could be | |||
observed along the network path to provide tools to manage new | observed along the network path to provide tools to manage new | |||
variants of protocols. Several scenarios to illustrate different | variants of protocols. Several scenarios to illustrate different | |||
ways this could evolve are provided below: | ways this could evolve are provided below: | |||
skipping to change at page 28, line 38 ¶ | skipping to change at page 28, line 44 ¶ | |||
between versions of the protocol. This ossification of the | between versions of the protocol. This ossification of the | |||
transport header allows an operator to establish tooling and | transport header allows an operator to establish tooling and | |||
procedures that enable it to provide consistent traffic management | procedures that enable it to provide consistent traffic management | |||
as the protocol evolves. In contrast to TCP (where all protocol | as the protocol evolves. In contrast to TCP (where all protocol | |||
information is exposed), evolution of the transport is facilitated | information is exposed), evolution of the transport is facilitated | |||
by providing cryptographic integrity checks of the transport | by providing cryptographic integrity checks of the transport | |||
header fields (preventing undetected middlebox changes) and | header fields (preventing undetected middlebox changes) and | |||
encryption of other protocol information (preventing observation | encryption of other protocol information (preventing observation | |||
within the network, or incentivising the use of the exposed | within the network, or incentivising the use of the exposed | |||
information, rather than inferring information from other | information, rather than inferring information from other | |||
characteristics of the flow traffic). The exposed transport | characteristics of the flow traffic). The exposed transport | |||
information can be used by operators to provide troubleshooting, | information can be used by operators to provide troubleshooting, | |||
measurement and any necessary functions appropriate to the class | measurement and any necessary functions appropriate to the class | |||
of traffic (priority, retransmission, reordering, circuit | of traffic (priority, retransmission, reordering, circuit | |||
breakers, etc). | breakers, etc). | |||
o An alternative scenario adopts different design goals, with a | o An alternative scenario adopts different design goals, with a | |||
different outcome. A protocol that encrypts all header | different outcome. A protocol that encrypts all header | |||
information forces network operators to act independently from | information forces network operators to act independently from | |||
apps/transport developments to provide the transport information | apps/transport developments to provide the transport information | |||
they need. A range of approaches may proliferate, as in current | they need. A range of approaches may proliferate, as in current | |||
skipping to change at page 29, line 40 ¶ | skipping to change at page 29, line 36 ¶ | |||
actors (e.g., developers and transport designers) achieve more | actors (e.g., developers and transport designers) achieve more | |||
control of the way in which the Internet architecture develops.In | control of the way in which the Internet architecture develops.In | |||
particular, there is a possibility that designs could evolve to | particular, there is a possibility that designs could evolve to | |||
significantly benefit of customers for a specific vendor, and that | significantly benefit of customers for a specific vendor, and that | |||
communities with very different network, applications or platforms | communities with very different network, applications or platforms | |||
could then suffer at the expense of benefits to their vendors own | could then suffer at the expense of benefits to their vendors own | |||
customer base. In such a scenario, there could be no incentive to | customer base. In such a scenario, there could be no incentive to | |||
support other applications/products or to work in other networks | support other applications/products or to work in other networks | |||
leading to reduced access for new approaches. | leading to reduced access for new approaches. | |||
7. Acknowledgements | ||||
The authors would like to thank all who have talked to him face-to- | ||||
face or via email. ... | ||||
This work has received funding from the European Union's Horizon 2020 | ||||
research and innovation programme under grant agreement No 688421.The | ||||
opinions expressed and arguments employed reflect only the authors' | ||||
view. The European Commission is not responsible for any use that | ||||
may be made of that information. | ||||
8. Security Considerations | 8. Security Considerations | |||
This document is about design and deployment considerations for | This document is about design and deployment considerations for | |||
transport protocols. Issues relating to security are discussed in | transport protocols. Issues relating to security are discussed in | |||
the various sections of the document. | the various sections of the 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 [I-D.ietf-taps- | protocol or layer on top of the transport protocol | |||
transport-security]. | [I-D.ietf-taps-transport-security]. | |||
Confidentiality and strong integrity checks have properties that can | Confidentiality and strong integrity checks have properties that can | |||
also be incorporated into the deisgn of a transport protocol. | also be incorporated into the deisgn of a transport protocol. | |||
Integrity checks can protect an endpoint from undetected modification | Integrity checks can protect an endpoint from undetected modification | |||
of protocol fields by network devices, whereas encryption and | of protocol fields by network devices, whereas encryption and | |||
obfuscation can further prevent these headers being utilised by | obfuscation can further prevent these headers being utilised by | |||
network devices. Hiding headers can therefore provide the | network devices. Hiding headers can therefore provide the | |||
opportunity for greater freedom to update the protocols and can ease | opportunity for greater freedom to update the protocols and can ease | |||
experimentation with new techniques and their final deployment in | experimentation with new techniques and their final deployment in | |||
endpoints. A protocol specification needs to weigh the benefits of | endpoints. A protocol specification needs to weigh the benefits of | |||
skipping to change at page 30, line 39 ¶ | skipping to change at page 30, line 28 ¶ | |||
field. Hiding headers can limit the ability to measure and | field. Hiding headers can limit the ability to measure and | |||
characterise traffic. | characterise traffic. | |||
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. This can be used | information to detect anomalies in network traffic. This can be used | |||
as the first line of defence yo identify potential threats from DOS | as the first line of defence yo identify potential threats from DOS | |||
or malware and redirect suspect traffic to dedicated nodes | or malware and redirect suspect traffic to dedicated nodes | |||
responsible for DOS analysis, malware detection, or to perform packet | responsible for DOS analysis, malware detection, or to perform packet | |||
scrubbing "Scrubbing" (the normalization of packets so that there are | scrubbing "Scrubbing" (the normalization of packets so that there are | |||
no ambiguities in interpretation by the ultimate destination of the | no ambiguities in interpretation by the ultimate destination of the | |||
packet). These techniques are currently used by some operators to | packet). These techniques are currently used by some operators to | |||
also defend from distributed DOS attacks. | also defend from distributed DOS attacks. | |||
Exposed transport headers are sometimes also utilised as a part of | Exposed transport headers are sometimes also utilised as a part of | |||
the information used by the receiver of a transport protocol to | the information used by the receiver of a transport protocol to | |||
protect the transport layer from data injection by an attacker. In | protect 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 | |||
skipping to change at page 31, line 9 ¶ | skipping to change at page 31, line 4 ¶ | |||
An attack can, for example, disrupt receiver processing, trigger loss | An attack can, for example, disrupt receiver processing, trigger loss | |||
and retransmission, or make a receiving endpoint perform unproductive | and retransmission, or make a receiving endpoint perform unproductive | |||
decryption of packets that cannot be successfully decrypted (forcing | decryption of packets that cannot be successfully decrypted (forcing | |||
a receiver to commit decryption resources, or to update and then | a receiver to commit decryption resources, or to update and then | |||
restore protocol state). | restore protocol state). | |||
One mitigation to off-path attack is to deny knowledge of what header | One mitigation to off-path attack is to deny knowledge of what header | |||
information is accepted by a receiver or obfusticate the accepted | information is accepted by a receiver or obfusticate the accepted | |||
header information, e.g., setting a non-predictable initial value for | header information, e.g., setting a non-predictable initial value for | |||
a sequence number during a protocol handshake, as in [RFC3550] and | a sequence number during a protocol handshake, as in [RFC3550] and | |||
[RFC6056], or a port value that can not be predicted (see section 5.1 | [RFC6056], or a port value that can not be predicted (see section 5.1 | |||
of [RFC8085]). A receiver could also require additional information | of [RFC8085]). A receiver could also require additional information | |||
to be used as a part of check before accepting packets at the | to be used as a part of check before accepting packets at the | |||
transport layer (e.g., utilising a part of the sequence number space | transport layer (e.g., utilising a part of the sequence number space | |||
that is encrypted; or by verifying an encrypted token not visible to | that is encrypted; or by verifying an encrypted token not visible to | |||
an attacker). This would also mitigate on-path attacks. An | an attacker). This would also mitigate on-path attacks. An | |||
additional processing cost can be incurred when decryption needs to | additional processing cost can be incurred when decryption needs to | |||
be attempted before a receiver is able to discard injected packets. | be attempted before a receiver is able to discard injected packets. | |||
Open standards motivate a desire for this evaluation to include | Open standards motivate a desire for this evaluation to include | |||
independent observation and evaluation of performance data, which in | independent observation and evaluation of performance data, which in | |||
turn suggests control over where and when measurement samples are | turn suggests control over where and when measurement samples are | |||
collected. This requires consideration of the appropriate balance | collected. This requires consideration of the appropriate balance | |||
between encrypting all and no transport information. Open data, and | between encrypting all and no transport information. Open data, and | |||
accessibility to tools that can help understand trends in application | accessibility to tools that can help understand trends in application | |||
deployment, network traffic and usage patterns can all contribute to | deployment, network traffic and usage patterns can all contribute to | |||
understanding security challenges. | understanding security challenges. | |||
9. IANA Considerations | 9. IANA Considerations | |||
XX RFC ED - PLEASE REMOVE THIS SECTION XXX | XX RFC ED - PLEASE REMOVE THIS SECTION XXX | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
10. References | 10. Acknowledgements | |||
10.1. Normative References | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | ||||
RFC2119, March 1997, <http://www.rfc-editor.org/info/ | ||||
rfc2119>. | ||||
10.2. Informative References | ||||
[I-D.dolson-plus-middlebox-benefits] | ||||
Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, | ||||
"Beneficial Functions of Middleboxes", Internet-Draft | ||||
draft-dolson-plus-middlebox-benefits-03, March 2017. | ||||
[I-D.ietf-aqm-codel] | The authors would like to thank Mohamed Boucadair, Spencer Dawkins, | |||
Nichols, K., Jacobson, V., McGregor, A. and J. Iyengar, | Jana Iyengar, Mirja Kuehlewind, Kathleen Moriarty, Al Morton, Chris | |||
"Controlled Delay Active Queue Management", Internet-Draft | Seal, Joe Touch, Brian Trammell, and other members of the TSVWG for | |||
draft-ietf-aqm-codel-10, October 2017. | their comments and feedback. | |||
[I-D.ietf-aqm-fq-codel] | This work has received funding from the European Union's Horizon 2020 | |||
Hoeiland-Joergensen, T., McKenney, P., | research and innovation programme under grant agreement No 688421.The | |||
dave.taht@gmail.com, d., Gettys, J. and E. Dumazet, "The | opinions expressed and arguments employed reflect only the authors' | |||
FlowQueue-CoDel Packet Scheduler and Active Queue | view. The European Commission is not responsible for any use that | |||
Management Algorithm", Internet-Draft draft-ietf-aqm-fq- | may be made of that information. | |||
codel-06, March 2016. | ||||
[I-D.ietf-aqm-pie] | This work has received funding from the UK Engineering and Physical | |||
Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A | Sciences Research Council under grant EP/R04144X/1. | |||
Lightweight Control Scheme To Address the Bufferbloat | ||||
Problem", Internet-Draft draft-ietf-aqm-pie-10, September | ||||
2016. | ||||
[I-D.ietf-ippm-6man-pdm-option] | 11. Informative References | |||
Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, | ||||
"IPv6 Performance and Diagnostic Metrics (PDM) Destination | ||||
Option", Internet-Draft draft-ietf-ippm-6man-pdm- | ||||
option-13, June 2017. | ||||
[I-D.ietf-ippm-ioam-data] | [I-D.ietf-ippm-ioam-data] | |||
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | |||
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | |||
P., Chang, R., daniel.bernier@bell.ca, d. and J. Lemon, | P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, | |||
"Data Fields for In-situ OAM", Internet-Draft draft-ietf- | "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- | |||
ippm-ioam-data-02, March 2018. | data-03 (work in progress), June 2018. | |||
[I-D.ietf-quic-transport] | [I-D.ietf-quic-transport] | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", Internet-Draft draft-ietf-quic- | and Secure Transport", draft-ietf-quic-transport-14 (work | |||
transport-03, May 2017. | in progress), August 2018. | |||
[I-D.ietf-taps-transport-security] | [I-D.ietf-taps-transport-security] | |||
Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of | Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey | |||
Transport Security Protocols", Internet-Draft draft-ietf- | of Transport Security Protocols", draft-ietf-taps- | |||
taps-transport-security-01, May 2018. | transport-security-02 (work in progress), June 2018. | |||
[I-D.ietf-tcpinc-tcpcrypt] | [I-D.ietf-tcpinc-tcpcrypt] | |||
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | |||
Q. and E. Smith, "Cryptographic protection of TCP Streams | Q., and E. Smith, "Cryptographic protection of TCP Streams | |||
(tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11, | (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in | |||
November 2017. | progress), June 2018. | |||
[I-D.ietf-tsvwg-l4s-arch] | [I-D.ietf-tsvwg-l4s-arch] | |||
Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, | Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, | |||
Low Loss, Scalable Throughput (L4S) Internet Service: | Low Loss, Scalable Throughput (L4S) Internet Service: | |||
Architecture", Internet-Draft draft-ietf-tsvwg-l4s- | Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in | |||
arch-01, October 2017. | progress), March 2018. | |||
[I-D.mm-wg-effect-encrypt] | ||||
Moriarty, K. and A. Morton, "Effects of Pervasive | ||||
Encryption on Operators", Internet-Draft draft-mm-wg- | ||||
effect-encrypt-24, March 2018. | ||||
[I-D.thomson-quic-grease] | [I-D.thomson-quic-grease] | |||
Thomson, M., "More Apparent Randomization for QUIC", | Thomson, M., "More Apparent Randomization for QUIC", | |||
Internet-Draft draft-thomson-quic-grease-00, December | draft-thomson-quic-grease-00 (work in progress), December | |||
2017. | 2017. | |||
[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", Internet-Draft draft- | Layer under Endpoint Control", draft-trammell-plus- | |||
trammell-plus-abstract-mech-00, September 2016. | abstract-mech-00 (work in progress), September 2016. | |||
[I-D.trammell-plus-statefulness] | ||||
Kuehlewind, M., Trammell, B. and J. Hildebrand, | ||||
"Transport-Independent Path Layer State Management", | ||||
Internet-Draft draft-trammell-plus-statefulness-02, | ||||
December 2016. | ||||
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | |||
Techniques and Their Merits", November 2014. | Techniques and Their Merits", November 2014. | |||
[Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- | [Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- | |||
based Protocol Design", June 2017. | based Protocol Design", June 2017. | |||
[RFC1273] Schwartz, M.F., "Measurement Study of Changes in Service- | [RFC1273] Schwartz, M., "Measurement Study of Changes in Service- | |||
Level Reachability in the Global TCP/IP Internet: Goals, | Level Reachability in the Global TCP/IP Internet: Goals, | |||
Experimental Design, Implementation, and Policy | Experimental Design, Implementation, and Policy | |||
Considerations", RFC 1273, DOI 10.17487/RFC1273, November | Considerations", RFC 1273, DOI 10.17487/RFC1273, November | |||
1991, <https://www.rfc-editor.org/info/rfc1273>. | 1991, <https://www.rfc-editor.org/info/rfc1273>. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
10.17487/RFC2474, December 1998, <http://www.rfc- | DOI 10.17487/RFC2474, December 1998, | |||
editor.org/info/rfc2474>. | <https://www.rfc-editor.org/info/rfc2474>. | |||
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC | [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | |||
2914, DOI 10.17487/RFC2914, September 2000, <https://www | RFC 2914, DOI 10.17487/RFC2914, September 2000, | |||
.rfc-editor.org/info/rfc2914>. | <https://www.rfc-editor.org/info/rfc2914>. | |||
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. | [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. | |||
Shelby, "Performance Enhancing Proxies Intended to | Shelby, "Performance Enhancing Proxies Intended to | |||
Mitigate Link-Related Degradations", RFC 3135, DOI | Mitigate Link-Related Degradations", RFC 3135, | |||
10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/ | DOI 10.17487/RFC3135, June 2001, | |||
info/rfc3135>. | <https://www.rfc-editor.org/info/rfc3135>. | |||
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
Explicit Congestion Notification (ECN) to IP", RFC 3168, | of Explicit Congestion Notification (ECN) to IP", | |||
DOI 10.17487/RFC3168, September 2001, <http://www.rfc- | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
editor.org/info/rfc3168>. | <https://www.rfc-editor.org/info/rfc3168>. | |||
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | |||
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | |||
<http://www.rfc-editor.org/info/rfc3234>. | <https://www.rfc-editor.org/info/rfc3234>. | |||
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||
Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI | Metric for IP Performance Metrics (IPPM)", RFC 3393, | |||
10.17487/RFC3393, November 2002, <https://www.rfc- | DOI 10.17487/RFC3393, November 2002, | |||
editor.org/info/rfc3393>. | <https://www.rfc-editor.org/info/rfc3393>. | |||
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. | ||||
Sooriyabandara, "TCP Performance Implications of Network | ||||
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, | ||||
December 2002, <http://www.rfc-editor.org/info/rfc3449>. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | July 2003, <https://www.rfc-editor.org/info/rfc3550>. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | ||||
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | ||||
December 2005, <http://www.rfc-editor.org/info/rfc4301>. | ||||
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, | |||
10.17487/RFC4302, December 2005, <http://www.rfc- | DOI 10.17487/RFC4302, December 2005, | |||
editor.org/info/rfc4302>. | <https://www.rfc-editor.org/info/rfc4302>. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
4303, DOI 10.17487/RFC4303, December 2005, <http://www | RFC 4303, DOI 10.17487/RFC4303, December 2005, | |||
.rfc-editor.org/info/rfc4303>. | <https://www.rfc-editor.org/info/rfc4303>. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/ | DOI 10.17487/RFC4585, July 2006, | |||
info/rfc4585>. | <https://www.rfc-editor.org/info/rfc4585>. | |||
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. | [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | |||
and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI | S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | |||
10.17487/RFC4737, November 2006, <http://www.rfc- | DOI 10.17487/RFC4737, November 2006, | |||
editor.org/info/rfc4737>. | <https://www.rfc-editor.org/info/rfc4737>. | |||
[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, <http://www.rfc- | DOI 10.17487/RFC5236, June 2008, | |||
editor.org/info/rfc5236>. | <https://www.rfc-editor.org/info/rfc5236>. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ | (TLS) Protocol Version 1.2", RFC 5246, | |||
RFC5246, August 2008, <http://www.rfc-editor.org/info/ | DOI 10.17487/RFC5246, August 2008, | |||
rfc5246>. | <https://www.rfc-editor.org/info/rfc5246>. | |||
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | |||
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, | Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, | |||
March 2009, <https://www.rfc-editor.org/info/rfc5481>. | March 2009, <https://www.rfc-editor.org/info/rfc5481>. | |||
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, | ||||
<http://www.rfc-editor.org/info/rfc5559>. | ||||
[RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP | ||||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | |||
June 2010, <http://www.rfc-editor.org/info/rfc5925>. | June 2010, <https://www.rfc-editor.org/info/rfc5925>. | |||
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | |||
Protocol Port Randomization", BCP 156, RFC 6056, DOI | Protocol Port Randomization", BCP 156, RFC 6056, | |||
10.17487/RFC6056, January 2011, <https://www.rfc- | DOI 10.17487/RFC6056, January 2011, | |||
editor.org/info/rfc6056>. | <https://www.rfc-editor.org/info/rfc6056>. | |||
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. | [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and | |||
Roberts, "Issues with IP Address Sharing", RFC 6269, DOI | P. Roberts, "Issues with IP Address Sharing", RFC 6269, | |||
10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/ | DOI 10.17487/RFC6269, June 2011, | |||
info/rfc6269>. | <https://www.rfc-editor.org/info/rfc6269>. | |||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <http://www.rfc-editor.org/info/rfc6347>. | January 2012, <https://www.rfc-editor.org/info/rfc6347>. | |||
[RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, | ||||
"IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ | ||||
RFC6437, November 2011, <http://www.rfc-editor.org/info/ | ||||
rfc6437>. | ||||
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. | [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, | |||
and K. Carlberg, "Explicit Congestion Notification (ECN) | "IPv6 Flow Label Specification", RFC 6437, | |||
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August | DOI 10.17487/RFC6437, November 2011, | |||
2012, <http://www.rfc-editor.org/info/rfc6679>. | <https://www.rfc-editor.org/info/rfc6437>. | |||
[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, <http://www.rfc-editor.org/info/rfc7258>. | 2014, <https://www.rfc-editor.org/info/rfc7258>. | |||
[RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
for Secure Use of Transport Layer Security (TLS) and | "Recommendations for Secure Use of Transport Layer | |||
Datagram Transport Layer Security (DTLS)", BCP 195, RFC | Security (TLS) and Datagram Transport Layer Security | |||
7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc- | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
editor.org/info/rfc7525>. | 2015, <https://www.rfc-editor.org/info/rfc7525>. | |||
[RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF | [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | |||
Recommendations Regarding Active Queue Management", BCP | Recommendations Regarding Active Queue Management", | |||
197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http:// | BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | |||
www.rfc-editor.org/info/rfc7567>. | <https://www.rfc-editor.org/info/rfc7567>. | |||
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., | [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., | |||
Trammell, B., Huitema, C. and D. Borkmann, | Trammell, B., Huitema, C., and D. Borkmann, | |||
"Confidentiality in the Face of Pervasive Surveillance: A | "Confidentiality in the Face of Pervasive Surveillance: A | |||
Threat Model and Problem Statement", RFC 7624, DOI | Threat Model and Problem Statement", RFC 7624, | |||
10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/ | DOI 10.17487/RFC7624, August 2015, | |||
info/rfc7624>. | <https://www.rfc-editor.org/info/rfc7624>. | |||
[RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations | [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, | |||
on the Dropping of Packets with IPv6 Extension Headers in | "Observations on the Dropping of Packets with IPv6 | |||
the Real World", RFC 7872, DOI 10.17487/RFC7872, June | Extension Headers in the Real World", RFC 7872, | |||
2016, <https://www.rfc-editor.org/info/rfc7872>. | DOI 10.17487/RFC7872, June 2016, | |||
<https://www.rfc-editor.org/info/rfc7872>. | ||||
[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. | [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and | |||
Ros, "Characterization Guidelines for Active Queue | D. Ros, "Characterization Guidelines for Active Queue | |||
Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July | Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July | |||
2016, <http://www.rfc-editor.org/info/rfc7928>. | 2016, <https://www.rfc-editor.org/info/rfc7928>. | |||
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP | [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, | |||
208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http:// | "Proportional Integral Controller Enhanced (PIE): A | |||
www.rfc-editor.org/info/rfc8084>. | Lightweight Control Scheme to Address the Bufferbloat | |||
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, | ||||
<https://www.rfc-editor.org/info/rfc8033>. | ||||
[RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage | [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", | |||
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8084>. | ||||
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | ||||
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | |||
March 2017, <http://www.rfc-editor.org/info/rfc8085>. | March 2017, <https://www.rfc-editor.org/info/rfc8085>. | |||
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- | [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- | |||
UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March | in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, | |||
2017, <http://www.rfc-editor.org/info/rfc8086>. | March 2017, <https://www.rfc-editor.org/info/rfc8086>. | |||
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using | [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using | |||
Explicit Congestion Notification (ECN)", RFC 8087, DOI | Explicit Congestion Notification (ECN)", RFC 8087, | |||
10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/ | DOI 10.17487/RFC8087, March 2017, | |||
info/rfc8087>. | <https://www.rfc-editor.org/info/rfc8087>. | |||
[RFC8095] Fairhurst, G., Ed., Trammell, B.Ed., and M. Kuehlewind, | [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | |||
Ed., "Services Provided by IETF Transport Protocols and | Ed., "Services Provided by IETF Transport Protocols and | |||
Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ | Congestion Control Mechanisms", RFC 8095, | |||
RFC8095, March 2017, <https://www.rfc-editor.org/info/ | DOI 10.17487/RFC8095, March 2017, | |||
rfc8095>. | <https://www.rfc-editor.org/info/rfc8095>. | |||
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. | [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 | |||
Performance and Diagnostic Metrics (PDM) Destination | ||||
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, | ||||
<https://www.rfc-editor.org/info/rfc8250>. | ||||
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., | ||||
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion | and G. Judd, "Data Center TCP (DCTCP): TCP Congestion | |||
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, | Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, | |||
October 2017, <https://www.rfc-editor.org/info/rfc8257>. | October 2017, <https://www.rfc-editor.org/info/rfc8257>. | |||
[Tor] The Tor Project, ., "https://www.torproject.org", June | [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. | |||
2017. | Iyengar, Ed., "Controlled Delay Active Queue Management", | |||
RFC 8289, DOI 10.17487/RFC8289, January 2018, | ||||
<https://www.rfc-editor.org/info/rfc8289>. | ||||
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, | ||||
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler | ||||
and Active Queue Management Algorithm", RFC 8290, | ||||
DOI 10.17487/RFC8290, January 2018, | ||||
<https://www.rfc-editor.org/info/rfc8290>. | ||||
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of | ||||
Pervasive Encryption on Operators", RFC 8404, | ||||
DOI 10.17487/RFC8404, July 2018, | ||||
<https://www.rfc-editor.org/info/rfc8404>. | ||||
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. | |||
-01 This draft was a result of walking away from the text for a few | -01 This draft was a result of walking away from the text for a few | |||
days and then reorganising the content. | days and then reorganising the content. | |||
-02 This draft fixes textual errors. | -02 This draft fixes textual errors. | |||
skipping to change at page 37, line 29 ¶ | skipping to change at page 37, line 33 ¶ | |||
-05 Corrections received and helpful inputs from Mohamed Boucadair. | -05 Corrections received and helpful inputs from Mohamed Boucadair. | |||
-06 Updated following comments from Stephen Farrell, and feedback via | -06 Updated following comments from Stephen Farrell, and feedback via | |||
email. Added a draft conclusion section to sketch some strawman | email. Added a draft conclusion section to sketch some strawman | |||
scenarios that could emerge. | scenarios that could emerge. | |||
-07 Updated following comments from Al Morton, Chris Seal, and other | -07 Updated following comments from Al Morton, Chris Seal, and other | |||
feedback via email. | feedback via email. | |||
-08 Updated to address comments sent to the TSVWG mailing list by | -08 Updated to address comments sent to the TSVWG mailing list by | |||
Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 11/05/ | Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on | |||
2018, and Spencer Dawkins. | 11/05/2018, and Spencer Dawkins. | |||
-09 Updated security considerations. | -09 Updated security considerations. | |||
-10 Updated references, split the Introduction, and added a paragraph | ||||
giving some examples of why ossification has been an issue. | ||||
Authors' Addresses | Authors' Addresses | |||
Godred Fairhurst | Godred Fairhurst | |||
University of Aberdeen | University of Aberdeen | |||
Department of Engineering | Department of Engineering | |||
Fraser Noble Building | Fraser Noble Building | |||
Aberdeen, AB24 3UE | Aberdeen AB24 3UE | |||
Scotland | Scotland | |||
Email: gorry@erg.abdn.ac.uk | EMail: gorry@erg.abdn.ac.uk | |||
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. 164 change blocks. | ||||
418 lines changed or deleted | 405 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/ |