draft-fairhurst-tsvwg-transport-encrypt-04.txt | draft-fairhurst-tsvwg-transport-encrypt-05.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.S. Perkins | |||
Expires: March 29, 2018 University of Glasgow | Expires: June 20, 2018 University of Glasgow | |||
September 27, 2017 | December 19, 2017 | |||
The Impact of Transport Header Encryption on Operation and Evolution of | The Impact of Transport Header Encryption on Network Operation and | |||
the Internet | Evolution of the Internet | |||
draft-fairhurst-tsvwg-transport-encrypt-04 | draft-fairhurst-tsvwg-transport-encrypt-05 | |||
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 some in-network | encryption at the transport layer. It identifies in-network uses of | |||
uses of transport layer header information that can be used with a | transport layer header information. It then reviews the implications | |||
transport header integrity check. It reviews the implication of | of developing encrypted end-to-end transport protocols on transport | |||
developing encrypted end-to-end transport protocols and examines the | protocol design and the implications on network operation. Since | |||
implication of developing and deploying encrypted end-to-end | transport measurement and analysis of the impact of network | |||
transport protocols. Since transport measurement and analysis of the | characteristics have been important to the design of current | |||
impact of network characteristics have been important to the design | transport protocols, it also considers some anticipated implications | |||
of current transport protocols, it also considers some anticipated | on transport and application evolution. | |||
implications on transport and 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 http://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 March 29, 2018. | This Internet-Draft will expire on June 20, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 (http://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Current uses of Transport Headers within the Network . . . 6 | 2. Current uses of Transport Headers within the Network . . . . . 7 | |||
1.1.1. Observing Transport Information in the Network . . . . 7 | 2.1. Observing Transport Information in the Network . . . . . . 7 | |||
1.1.1.1. Flow Identification . . . . . . . . . . . . . . . 7 | 2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 7 | |||
1.1.1.2. Metrics derived from Transport Layer Headers . . . 7 | 2.1.2. Metrics derived from Transport Layer Headers . . . . . 8 | |||
1.1.1.3. Metrics derived from Network Layer Headers . . . . 10 | 2.1.3. Metrics derived from Network Layer Headers . . . . . . 11 | |||
1.1.2. Transport Measurement . . . . . . . . . . . . . . . . 12 | 2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 12 | |||
1.1.2.1. Point of Measurement . . . . . . . . . . . . . . . 12 | 2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 13 | |||
1.1.2.2. Use by Operators to Plan and Provision Networks . 13 | 2.2.2. Use by Operators to Plan and Provision Networks . . . 14 | |||
1.1.2.3. Service Performance Measurement . . . . . . . . . 13 | 2.2.3. Service Performance Measurement . . . . . . . . . . . 14 | |||
1.1.2.4. Measuring Transport to Support Network Operations 13 | 2.2.4. Measuring Transport to Support Network Operations . . 14 | |||
1.1.3. Use for Network Diagnostics and Troubleshooting . . . 15 | 2.3. Use for Network Diagnostics and Troubleshooting . . . . . 15 | |||
1.1.4. Observing Headers to Implement Network Policy . . . . 15 | 2.4. Observing Headers to Implement Network Policy . . . . . . 16 | |||
2. Encryption and Authentication of Transport Headers . . . . . . 15 | 3. Encryption and Authentication of Transport Headers . . . . . . 16 | |||
2.1. Authenticating the Transport Protocol Header . . . . . . . 17 | 3.1. Authenticating the Transport Protocol Header . . . . . . . 18 | |||
2.2. Encrypting the Transport Payload . . . . . . . . . . . . . 17 | 3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 18 | |||
2.3. Encrypting the Transport Header . . . . . . . . . . . . . 18 | 3.3. Encrypting the Transport Header . . . . . . . . . . . . . 18 | |||
2.4. Authenticating Transport Information and Selectively | 3.4. Authenticating Transport Information and Selectively | |||
Encrypting the Transport Header . . . . . . . . . . . . . 18 | Encrypting the Transport Header . . . . . . . . . . . . . 19 | |||
2.5. Adding Transport Information to Network-Layer Protocol | 3.5. Adding Transport Information to Network-Layer Protocol | |||
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 18 | Headers . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3. Implications of Protecting the Transport Headers . . . . . . . 19 | 4. Implications of Protecting the Transport Headers . . . . . . . 20 | |||
3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19 | 4.1. Independent Measurement . . . . . . . . . . . . . . . . . 20 | |||
3.2. Characterising "Unknown" Network Traffic . . . . . . . . . 20 | 4.2. Characterising "Unknown" Network Traffic . . . . . . . . . 21 | |||
3.3. Accountability and Internet Transport Protocols . . . . . 20 | 4.3. Accountability and Internet Transport Protocols . . . . . 21 | |||
3.4. Impact on Research, Development and Deployment . . . . . . 21 | 4.4. Impact on Research, Development and Deployment . . . . . . 22 | |||
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 22 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . . 26 | Appendix A. Revision information . . . . . . . . . . . . . . . . . 28 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
1. Introduction | 1. Introduction | |||
This document discusses the implications of end-to-end encryption | This document discusses the implications of end-to-end encryption | |||
applied at the transport layer, and examines the impact on transport | applied at the transport layer, and examines the impact on transport | |||
protocol design, usage, and network operations and management. It | protocol design, transport usage, and network operations and | |||
also considers anticipated implications on transport and application | management. It also considers anticipated implications on transport | |||
evolution. | and application evolution. | |||
The transport layer provides the first end-to-end interactions across | The transport layer provides the first end-to-end interactions across | |||
the Internet. Transport protocols layer directly over the network- | the Internet. Transport protocols layer directly over the network- | |||
layer service and are sent in the payload of network-layer packets. | layer service and are sent in the payload of network-layer packets. | |||
They support end-to-end communication between applications, supported | They support end-to-end communication between applications, supported | |||
by higher-layer protocols, running on the end systems (or transport | by higher-layer protocols, running on the end systems (or transport | |||
endpoint). This simple architectural view hides one of the core | endpoints). This simple architectural view hides one of the core | |||
functions of the transport, however - to discover and adapt to the | functions of the transport, however - to discover and adapt to the | |||
properties of the Internet path that is currently being used. The | properties of the Internet path that is currently being used. The | |||
design of Internet transport protocols is as much about trying to | design of Internet transport protocols is as much about trying to | |||
avoid the unwanted side effects of congestion on a flow and other | avoid the unwanted side effects of congestion on a flow and other | |||
capacity-sharing flows, avoiding congestion collapse, adapting to | capacity-sharing flows, avoiding congestion collapse, adapting to | |||
changes in the path characteristics, etc., as it is about end-to-end | changes in the path characteristics, etc., as it is about end-to-end | |||
feature negotiation, flow control and optimising for performance of a | feature negotiation, flow control and optimising for performance of a | |||
specific application. | specific 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 select appropriate mechanisms, to ensure a safe, | selection of appropriate mechanisms, to ensure a safe, reliable, and | |||
reliable and robust Internet. In turn, the network operations | robust Internet (e.g., [RFC1273]). In turn, the network operations | |||
community relies on being able to understand the traffic passing over | community relies on being able to understand the pattern and | |||
the Internet, both in aggregate and at the flow level -- inspecting | requirements of traffic passing over the Internet, both in aggregate | |||
transport layer headers to help understand traffic dynamics. | and at the flow level - inspecting transport layer headers to help | |||
understand traffic dynamics. | ||||
There are many motivations for deploying encrypted transports, and | There are many motivations for deploying encrypted transports, and | |||
encryption of transport payloads. The increasing public concerns | encryption of transport payloads. 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. At the same time, network operators and access | protocols like QUIC. At the same time, network operators and access | |||
providers, especially in mobile networks, have come to rely on the | providers, especially in mobile networks, 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. | enhance performance (e.g., [I-D.dolson-plus-middlebox-benefits]). | |||
This document considers some implications of working with encrypted | This document considers some implications of working with encrypted | |||
transport protocols, and discusses trade-offs around authentication, | transport protocols, and discusses trade-offs around authentication, | |||
encryption of transport protocol headers. It describes some of the | and encryption of transport protocol headers. It describes some of | |||
architectural challenges and considerations in the way transport | the architectural challenges and considerations in the way transport | |||
protocols are designed when using encryption [Measure]. | protocols are designed when using encryption [Measure]. | |||
Encryption of the transport layer brings some well-known privacy and | Encryption of the transport layer brings some well-known privacy and | |||
security benefits, but also introduces various costs that need to be | security benefits, but also introduces various costs that need to be | |||
considered. Specifically, it can impact the following activities | considered. Specifically, it can impact the following activities | |||
that rely on measurement and analysis of traffic flows: | that rely on measurement and analysis of traffic flows: | |||
o Network Operations and Research: Observable transport headers | Network Operations and Research: Observable transport headers enable | |||
enable 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. This data also can inform Internet engineering | network operators. | |||
research, and help the develop of new protocols and procedures. | ||||
Encryption of the entire transport protocol, including header | ||||
information, will restrict the availability of data, and might | ||||
lead to the development of alternative, and potentially more | ||||
intrusive, methods to acquire the needed data. Encrypting the | ||||
transport payload, but leaving some, or all, of the transport | ||||
headers unencrypted but authenticated can provide the majority of | ||||
the privacy and security benefits while allowing some measurement. | ||||
o Network Troubleshooting and diagnostics: Encrypting transport | This data information can inform Internet engineering research, | |||
header information eliminates the incentive for operators to | and help the development of new protocols, methodologies, and | |||
troubleshoot what they cannot interpret. A flow experiencing | procedures. Encryption of the entire transport protocol, | |||
packet loss looks like an unaffected flow when only observing | including header information, will restrict the availability of | |||
network layer headers (if transport sequence numbers and flow | data, and might lead to the development of alternative, and | |||
identifiers are obscured). This limits understanding of the impact | potentially more intrusive, methods to acquire the needed data. | |||
of packet loss on the flows that share a network segment. | ||||
Encrypted traffic therefore implies "don't touch", and a likely | ||||
trouble-shooting response will be "can't help, no trouble found". | ||||
The additional mechanisms that will need to be introduced to help | ||||
reconstruct transport-level metrics add complexity and operational | ||||
costs [I-D.mm-wg-effect-encrypt]. | ||||
o Network Traffic Analysis: The use of encryption can make it harder | Encrypting the transport payload, but leaving some, or all, of the | |||
to determine which transport protocols and features are being used | transport headers unencrypted, possibly with authentication, can | |||
provide the majority of the privacy and security benefits while | ||||
allowing some measurement. | ||||
Protection from Denial of Service: Observable transport headers can | ||||
provide useful input to classification of traffic and detection of | ||||
anomalous events, such as distributed denial of service attacks. | ||||
To be effective, this protection needs to be able to uniquely | ||||
disambiguate unwanted traffic. An inability to separate this | ||||
traffic using packet header information is expected to lead to | ||||
less precise pattern matching techniques or resort to | ||||
indiscriminately (rate) limiting uncharacterised traffic. | ||||
Network Troubleshooting and Diagnostics: Encrypting transport header | ||||
information eliminates the incentive for operators to troubleshoot | ||||
what they cannot interpret. A flow experiencing packet loss looks | ||||
like an unaffected flow when only observing network layer headers | ||||
(if transport sequence numbers and flow identifiers are obscured). | ||||
This limits understanding of the impact of packet loss on the | ||||
flows that share a network segment. Encrypted traffic therefore | ||||
implies "don't touch", and a likely trouble-shooting response will | ||||
be "can't help, no trouble found". The additional mechanisms that | ||||
will need to be introduced to help reconstruct transport-level | ||||
metrics add complexity and operational costs [I-D.mm-wg-effect- | ||||
encrypt]. | ||||
Network Traffic Analysis: The use of encryption can make it harder to | ||||
determine which transport protocols and features are being used | ||||
across a network segment. The trends in usage. This could impact | across a network segment. The trends in usage. This could impact | |||
the ability for an operator to anticipate the need for network | the 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. While the impact | engineering activities performed by operators. While the impact | |||
may, in many cases, be small there are scenarios where operators | may, in many cases, be small there are scenarios where operators | |||
directly support particular services (e.g., in radio links, or to | directly support particular services (e.g., in radio links, or to | |||
troubleshoot issues realting to Quality of Service, QoS). The more | troubleshoot issues relating to Quality of Service, QoS; the | |||
complex the underlying infrastructure the more important this | ability to perform fast re-routing of critical traffic, or support | |||
to mitigate the characteristics of specific radio links). The | ||||
more complex the underlying infrastructure the more important this | ||||
impact. | impact. | |||
o Open and Verifiable Network Data: The use of transport header | Open and Verifiable Network Data: The use of transport header | |||
encryption reduces the range of actors that can capture useful | encryption reduces the range of actors that can capture useful | |||
measurement data. This is, of course, its goal. Doing so, | measurement data. This is, of course, its goal. Doing so, | |||
however, limits the information sources available to the Internet | however, limits the information sources available to the Internet | |||
community to understand the operation of transport protocols, so | community to understand the operation of transport protocols, so | |||
preventing access to the information necessary to inform design | preventing access to the information necessary to inform design | |||
decisions and standards for new protocols and related operational | decisions and standards for new protocols and related operational | |||
practices. There are dangers in a model where only endpoints | practices. | |||
(i.e., at user devices and within service platforms) can observe | ||||
performance, and this cannot be independently verified. To ensure | There are dangers in a model where only endpoints (i.e., at user | |||
the health of the standards and research communities, we need | devices and within service platforms) can observe performance, and | |||
independently captured data to develop on the behaviour of the | this cannot be independently verified. | |||
transports. Independently verifiable performance metrics might | ||||
also important in order to demonstrate regulatory compliance in | To ensure the health of the standards and research communities, we | |||
some jurisdictions. | need independently captured data to develop new transport protocol | |||
mechanisms based on the behaviour experienced in deployed | ||||
networks. | ||||
Independently verifiable performance metrics might also important | ||||
in order to demonstrate regulatory compliance in some | ||||
jurisdictions. | ||||
The last point leads us to consider the impact of encrypting all the | The last point leads us to consider the impact of encrypting all the | |||
transport headers the specification and development of protocols and | transport headers the specification and development of protocols and | |||
standards. It has potential impact on: | standards. It has potential impact on: | |||
o Understanding Feature Interactions: An appropriate vantage point, | o Understanding Feature Interactions: An appropriate vantage point, | |||
coupled with timing information about traffic flows, provides a | coupled with timing information about traffic flows, provides a | |||
valuable tool for benchmarking equipment and/or configurations, | valuable tool for benchmarking equipment, functions, and/or | |||
and to understand complex feature interactions. Transport header | configurations, and to understand complex feature interactions. | |||
encryption limits the ability to diagnose and explore interactions | Transport header encryption limits the ability to diagnose and | |||
between features at different protocol layers, a side-effect of | explore interactions between features at different protocol | |||
not allowing a choice of vantage point from which this information | layers, a side-effect of not allowing a choice of vantage point | |||
is observed. | from which this information is observed. | |||
o Supporting Common Specifications: The Transmission Control Protocl | o Supporting Common Specifications: The Transmission Control | |||
(TCP) is the predominant transport protocol. Its many variants | Protocol (TCP) is the predominant transport protocol used over | |||
have broadly consistent approaches to avoiding congestion | Internet paths. Its many variants have broadly consistent | |||
collapse, and to ensuring the stability of the network. Increased | approaches to avoiding congestion collapse, and to ensuring the | |||
use of transport layer encryption can overcome ossification, | stability of the network. Increased use of transport layer | |||
allowing deployment of new transports with different types of | encryption can overcome ossification, allowing deployment of new | |||
congestion control. This flexibility can be beneficial, but it | transports with different types of congestion control. This | |||
comes at the cost of fragmenting the ecosystem. There's little | flexibility can be beneficial, but it comes at the cost of | |||
doubt that developers will try to produce high quality transports | fragmenting the ecosystem. There's little doubt that developers | |||
for their target uses, but it is not clear there are sufficient | will try to produce high quality transports for their target uses, | |||
incentives to ensure good practice that benefits the wide | but it is not clear there are sufficient incentives to ensure good | |||
diversity of requirements for the Internet community as a whole. | practice that benefits the wide diversity of requirements for the | |||
Increased diversity, and the ability to innovate without public | Internet community as a whole. Increased diversity, and the | |||
scrutiny, risks point solutions that optimise for specific needs, | ability to innovate without public scrutiny, risks point solutions | |||
but accidentally disrupt operations of/in different parts of the | that optimise for specific needs, but accidentally disrupt | |||
network. The social compact that maintains the stability of the | operations of/in different parts of the network. The social | |||
network relies on accepting common specifications, and on the | contract that maintains the stability of the network relies on | |||
ability to verify that others also conform. | accepting common specifications, and on the ability to verify that | |||
others also conform. | ||||
o Operational practice: Published transport specifications allow | o Operational practice: Published transport specifications allow | |||
operators to check compliance. This can bring assurance to those | operators to check compliance. This can bring assurance to those | |||
operating networks, often avoiding the need to deploy complex | operating networks, often avoiding the need to deploy complex | |||
techniques that routinely monitor and manage TCP/IP traffic flows | techniques that routinely monitor and manage TCP/IP traffic flows | |||
(e.g. Avoiding the capital and operational costs of deploying | (e.g. Avoiding the capital and operational costs of deploying | |||
flow rate-limiting and network circuit-breaker methods). This | flow rate-limiting and network circuit-breaker methods [RFC8084]). | |||
should continue when encrypted transport headers are used, but | This should continue when encrypted transport headers are used, | |||
methods need to confirm that the traffic produced conforms to the | but methods need to confirm that the traffic produced conforms to | |||
expectations of the operator or developer. | the expectations of the operator or developer. | |||
o Restricting research and development: The use of encryption may | o Restricting research and development: The use of encryption may | |||
impede independent research into new mechanisms, measurement of | impede independent research into new mechanisms, measurement of | |||
behaviour, and development initiatives. Experience shows that | behaviour, and development initiatives. Experience shows that | |||
transport protocols are complicated to design and complex to | transport protocols are complicated to design and complex to | |||
deploy, and that individual mechanisms need to be evaluated while | deploy, and that individual mechanisms need to be evaluated while | |||
considering other mechanism, across a broad range of network | considering other mechanisms, across a broad range of network | |||
topologies and with attention to the impact on traffic sharing the | topologies and with attention to the impact on traffic sharing the | |||
capacity. Adopting pervasive encryption of transport information | capacity. Adopting pervasive encryption of transport information | |||
could eliminate the independent self-checks that have previously | could eliminate the independent self-checks that have previously | |||
been in place from research and academic contributors (e.g., the | been in place from research and academic contributors (e.g., the | |||
role of the IRTF ICCRG, and research publications in reviewing new | role of the IRTF ICCRG, and research publications in reviewing new | |||
transport mechanisms and assessing the impact of their | transport mechanisms and assessing the impact of their | |||
experimental deployment). | experimental deployment). | |||
Pervasive use of transport header encryption can impact the ways that | Pervasive use of transport header encryption can impact the ways that | |||
protocols are designed, standardised, deployed, and operated. The | protocols are designed, standardised, deployed, and operated. The | |||
choice of whether future transport protocols encrypt their protocol | choice of whether future transport protocols encrypt their protocol | |||
headers therefore needs to be taken based not solely on security and | headers therefore needs to be taken based not solely on security and | |||
privacy considerations, but also taking into account the impact on | privacy considerations, but also taking into account the impact on | |||
operations, standards, and research. A network that is secure but | operations, standards, and research. A network that is secure but | |||
unusable due to persistent congestion collapse is not an improvement, | unusable due to persistent congestion collapse is not an improvement, | |||
and while that would be an extreme outcome proposals that impose high | and while that would be an extreme outcome proposals that impose high | |||
costs for very limited benefits need to be considered carefully, to | costs for very limited benefits need to be considered carefully, to | |||
ensure the benefits outweigh the costs. | ensure the benefits outweigh the costs. | |||
1.1. Current uses of Transport Headers within the Network | 2. Current uses of Transport Headers within the Network | |||
The transport layer is the first end-to-end layer in the network | Despite transport headers having end-to-end meaning, some of these | |||
stack. Despite headers having end-to-end meaning, some transport | transport headers have come to be used in various ways within the | |||
headers have come to be used in various ways within the Internet. In | Internet. In response to pervasive monitoring [RFC7624] revelations | |||
response to pervasive monitoring [RFC7624] revelations and the IETF | and the IETF consensus that "Pervasive Monitoring is an Attack" | |||
consensus that "Pervasive Monitoring is an Attack" [RFC7258], efforts | [RFC7258], efforts are underway to increase encryption of Internet | |||
are underway to increase encryption of Internet traffic, which would | traffic, which would prevent visibility of transport headers. This | |||
prevent visibility of transport headers. This affects on how network | affects on how network protocols are designed and used [I-D.mm-wg- | |||
protocols are designed and used [I-D.mm-wg-effect-encrypt]. To | effect-encrypt]. To understand these implications, it is first | |||
understand these implications, it is first necessary to understand | necessary to understand how transport layer headers are currently | |||
how transport layer headers are currently observed and/or modified by | observed and/or modified by middleboxes within the network. | |||
middleboxes 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 methods at the transport | transport header fields. Authentication methods at the transport | |||
layer can be sued to detect any changes to an immutable header field | layer can be used to detect any changes to an immutable header field | |||
that were made by a network device along a path. The intentional | that were made by a network device along a path. The intentional | |||
modification of transport headers by middleboxes (such as Network | modification of transport headers by middleboxes (such as Network | |||
Address Translation with Protocol Translation, NAT-PT, or Firewalls) | Address Translation, NAT, or Firewalls) is not considered. Common | |||
is not considered. | issues concerning IP address sharing are described in [RFC6269]. | |||
1.1.1. Observing Transport Information in the Network | 2.1. Observing Transport Information in the Network | |||
In-network observation of transport protocol headers requires | In-network observation of transport protocol headers requires | |||
knowledge of the format of the transport header: | knowledge of the format of the transport header: | |||
o Flows need to be identified at the level required for monitoring; | o Flows need to be identified at the level required for monitoring; | |||
o The protocol and version of the header need to be observable. As | o The protocol and version of the header need to be observable. 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 Location and syntax of any transport headers to be observed. IETF | o Location and syntax of any transport headers to be observed. IETF | |||
transport protocols specify this information. | transport protocols specify this information. | |||
The following subsections describe various ways that observable | The following subsections describe various ways that observable | |||
transport information may be utilised. | transport information may be utilised. | |||
1.1.1.1. Flow Identification | 2.1.1. Flow Identification | |||
Transport protocol header information (with information in the | ||||
network header), can identify a flow and the connection state of the | ||||
flow, together with the protocol options being used. In some usages, | ||||
a low-numbered (well-known ) port number can identify a protocol | ||||
(although port information alone is not sufficient to guarantee | ||||
identification of a protocol). Transport protocols, such as TCP and | ||||
Stream Control Transport Protocol (SCTP) specify a standard base | ||||
header that includes sequence number information and other data, with | ||||
the possibility to negotiate additional headers at connection setup, | ||||
identified by an option number in the transport header. UDP-based | ||||
protocols can use, but sometimes do not use, well-known port numbers. | ||||
Some can instead be identified by signalling protocols or through the | ||||
use of magic numbers placed in the first byte(s) of the datagram | ||||
payload. | ||||
Transport protocol header information can identify a flow and the | Flow identification is more complex and less easily achieved when | |||
connection state of the flow, together with the protocol options | multiplexing is used at or above the transport layer. | |||
being used. In some usages, a low-numbered (well-known ) port can | ||||
identify a protocol (although port information alone is not | ||||
sufficient to guarantee identification of a protocol). Transport | ||||
protocols, such as TCP and Stream Control Transport Protocol (SCTP) | ||||
specify a standard base header that includes sequence number | ||||
information and other data, with the possibility to negotiate | ||||
additional headers at connection setup, identified by an option | ||||
number in the transport header. UDP-based protocols can use, but | ||||
sometimes do not use, well-known ports. Some can instead be | ||||
identified by signalling protocols or through the use of magic | ||||
numbers placed in the first byte(s) of the datagram payload. | ||||
1.1.1.2. Metrics derived from Transport Layer Headers | 2.1.2. Metrics derived from Transport Layer Headers | |||
Some actors have a need to characterise the performance of link/ | Some actors have a need to characterise the performance of link/ | |||
network segments. Passive monitoring uses observed traffic to makes | network segments. Passive monitoring uses observed traffic to makes | |||
inferences from transport headers to derive these measurements. A | inferences from transport headers to derive these measurements. A | |||
variety of open source and commercial tools have been deployed that | variety of open source and commercial tools have been deployed that | |||
utilise this information. The following metrics can be derived from | utilise this information. The following metrics can be derived from | |||
transport header information: | transport header information: | |||
Traffic Rate and Volume: Header infromation may allow derivation of | Traffic Rate and Volume: Header information may allow derivation of | |||
volume measures per-application, to characterise the traffic that | volume measures per-application, to characterise the traffic that | |||
uses a network segment or the pattern of network usage. This may | uses a network segment or the pattern of network usage. This may | |||
be measured per endpoint or aggregate of endpoint (e.g., by an | be measured per endpoint or for an aggregate of endpoints (e.g., | |||
operator to assess subscriber usage). It can also be used to | by an operator to assess subscriber usage). It can also be used to | |||
trigger measurement-based traffic shaping and to implement QoS | trigger measurement-based traffic shaping and to implement QoS | |||
support within the network and lower layers. Volume measures can | support within the network and lower layers. Volume measures can | |||
be valuable for capacity planning (providing detail of trends | be valuable for capacity planning (providing detail of trends | |||
rather than the volume per subscriber). | rather than the volume per subscriber). | |||
Loss Rate and Loss Pattern: Flow loss rate may be derived and is | Loss Rate and Loss Pattern: Flow loss rate may be derived and is | |||
often used as a metric for performance assessment and to | often used as a metric for performance assessment and to | |||
characterise transport behaviour. Understanding the root cause of | characterise transport behaviour. Understanding the root cause of | |||
loss can help an operator determine whether this requires | loss can help an operator determine whether this requires | |||
corrective action. | corrective action. Network operators may also use the variation | |||
in patterns of loss as a key performance metric, utilising this to | ||||
detect changes in the offered service. | ||||
There are various cause of loss, including: corruption on a link | There are various cause of loss, including: corruption on a link | |||
(e.g., interference on a radio link), buffer overflow (e.g., due | (e.g., interference on a radio link), buffer overflow (e.g., due | |||
to congestion), policing (traffic management), buffer management | to congestion), policing (traffic management), buffer management | |||
(e.g., Active Queue Management, AQM). Understanding flow loss | (e.g., Active Queue Management, AQM), inadequate provision of | |||
rate requires either maintaining per flow packet counters or by | traffic preemption. Understanding flow loss rate requires either | |||
observing sequence numbers in transport headers. Loss can be | maintaining per flow packet counters or by observing sequence | |||
monitored at the interface level by devices in the network. It is | numbers in transport headers. Loss can be monitored at the | |||
often important to understand the conditions under which packet | interface level by devices in the network. It is often important | |||
loss occurs. This usually requires relating loss to the traffic | to understand the conditions under which packet loss occurs. This | |||
flowing on the network segment at the time of loss. | usually requires relating loss to the traffic flowing on the | |||
network node/segment at the time of loss. | ||||
Observation of transport feedback information (observing loss | Observation of transport feedback information (observing loss | |||
reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase | reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase | |||
understanding of the impact of loss and help identify cases where | understanding of the impact of loss and help identify cases where | |||
loss may have been wrongly identified, or the transport did not | loss may have been wrongly identified, or the transport did not | |||
require the lost packet. It is sometimes more important to | require the lost packet. It is sometimes more important to | |||
understand the pattern of loss, than the loss rate - since losses | understand the pattern of loss, than the loss rate - since losses | |||
can often occur as bursts, rather than randomly-timed events. | can often occur as bursts, rather than randomly-timed events. | |||
Throughput and Goodput: The throughput observed by a flow can be | Throughput and Goodput: The throughput observed by a flow can be | |||
skipping to change at page 9, line 20 ¶ | skipping to change at page 9, line 47 ¶ | |||
determines the reaction time of the transport protocol itself, | determines the reaction time of the transport protocol itself, | |||
impacting flow setup, congestion control, loss recovery, and other | impacting flow setup, congestion control, loss recovery, and other | |||
transport mechanisms. The observed latency can have many | transport mechanisms. The observed latency can have many | |||
components [Latency]. Of these, unnecessary/unwanted queuing in | components [Latency]. Of these, unnecessary/unwanted queuing in | |||
network buffers has often been observed as a significant factor. | network buffers has often been observed as a significant factor. | |||
Once the cause of unwanted latency has been identified, this can | Once the cause of unwanted latency has been identified, this can | |||
often be eliminated, and determining latency metrics is a key | often be eliminated, and determining latency metrics is a key | |||
driver in the deployment of AQM [RFC7567], DiffServ [RFC2474], and | driver in the deployment of AQM [RFC7567], DiffServ [RFC2474], and | |||
Explicit Congestion Notification (ECN) [RFC3168] [RFC8087]. | Explicit Congestion Notification (ECN) [RFC3168] [RFC8087]. | |||
To measure latency across a part of the 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 may be used to locate a source of latency, e.g., by observing | This may be used to locate a source of latency, e.g., by observing | |||
cases where the ratio of median to minimum RTT is large for a part | cases where the ratio of median to minimum RTT is large for a part | |||
of a path. | of a path. | |||
An example usage of this method could identify excessive buffers | An example usage of this method could identify excessive buffers | |||
skipping to change at page 10, line 4 ¶ | skipping to change at page 10, line 28 ¶ | |||
Jitter: Some network applications are sensitive to changes in packet | Jitter: Some network applications are sensitive to changes in packet | |||
timing. For such applications, it can be necessary to measure the | timing. For such applications, it can be necessary to measure the | |||
jitter observed along a portion of the path. The requirements to | jitter observed along a portion of the path. The requirements to | |||
measure jitter resemble those for the measurement of latency. | measure jitter resemble those for the measurement of latency. | |||
Flow Reordering: Significant flow reordering can impact time-critical | Flow Reordering: Significant flow reordering can impact time-critical | |||
applications and can be interpreted as loss by reliable | 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). | rules). | |||
As in the drive to reduce network latency, there is a need for | As in the drive to reduce network latency, there is a need for | |||
operational tools to detect mis-ordered packet flows and quantify | operational tools to detect mis-ordered packet flows and quantify | |||
the degree or reordering. Techniques for measuring reordering | the degree or reordering. Techniques for measuring reordering | |||
typically observe packet sequence numbers. Metrics have been | typically observe packet sequence numbers. Metrics have been | |||
defined that evaluate whether a network has maintained packet | defined that evaluate whether a network has maintained packet | |||
order on a packet-by-packet basis [RFC4737] and [RFC5236]. | order on a packet-by-packet basis [RFC4737] and [RFC5236]. | |||
There has 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 reduced the requirements for ordering. These have promise to | to reduce the requirements for ordering. These have promise to | |||
simplify network equipment design as well as the potential to | simplify network equipment design as well as the potential to | |||
improve robustness of the transport service. Measurements of | improve robustness of the transport service. Measurements of | |||
reordering can help understand the level of reordering within | reordering can help understand the level of reordering within | |||
deployed infrastructure, and inform decisions about how to | deployed infrastructure, and inform decisions about how to | |||
progress such mechanisms. | progress such mechanisms. | |||
Some protocols provide in-built monitoring and reporting functions. | Some protocols provide in-built monitoring and reporting functions. | |||
Transport fields in the RTP header [RFC3550] [RFC4585] can be | Transport fields in the RTP header [RFC3550] [RFC4585] can be | |||
observed to derive traffic volume measurements and provide | observed to derive traffic volume measurements and provide | |||
information on the progress and quality of a session using RTP. Key | information on the progress and quality of a session using RTP. Key | |||
performance indicators are retransmission rate, packet drop rate, | performance indicators are retransmission rate, packet drop rate, | |||
sector utilization level, a measure of reordering, peak rate, the CE- | sector utilisation level, a measure of reordering, peak rate, the CE- | |||
marking rate, etc. Metadata is often important to understand the | marking rate, etc. 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. | |||
When encryption conceals information in packet headers, measurements | When encryption conceals information in packet headers, measurements | |||
need to rely on pattern inferences and other heuristics grows, and | need to rely on pattern inferences and other heuristics grows, and | |||
accuracy suffers [I-D.mm-wg-effect-encrypt]. | accuracy suffers [I-D.mm-wg-effect-encrypt]. | |||
1.1.1.3. Metrics derived from Network Layer Headers | 2.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 can be | protocol header. These header fields are not encrypted and can be | |||
used to make flow observations. | used 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 expose | |||
flow information in the IPv6 Flow Label field of the network-layer | flow information in the IPv6 Flow Label field of the network-layer | |||
header (e..g. [RFC8085]). This can be used to inform network- | header (e.g., [RFC8085]). This can be used to inform network-layer | |||
layer queuing, forwarding (e.g., for equal cost multi-path (ECMP) | queuing, forwarding (e.g., for equal cost multi-path (ECMP) | |||
routing, and Link Aggregation, LAG). This can provide useful | routing, and Link Aggregation, LAG). This can provide useful | |||
information to assign packets to flows in the data collected by | information to assign packets to flows in the data collected by | |||
measurement campaigns. Although important to characterising a | measurement campaigns. Although important to characterising a | |||
path, it does not directly provide any performance data. | path, it does not directly provide any performance data. | |||
Use Network-Layer Differentiated Services Code Point Point: Applicati | Use Network-Layer Differentiated Services Code Point Point: Applicati | |||
on can expose their delivery expectations to the network by | ons can expose their delivery expectations to the network by | |||
setting the Differentiated Services Code Point (DSCP) field of | 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 any performance data. | campaigns, but does not directly provide any 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 | |||
skipping to change at page 11, line 44 ¶ | skipping to change at page 12, line 28 ¶ | |||
ECN marks carried in the IP protocol header, it is much easier to | ECN marks carried in the IP protocol header, it is much easier to | |||
measure ECN than metering packet loss. However, interpreting the | measure ECN than metering packet loss. However, interpreting the | |||
marking behaviour (i.e., assessing congestion and diagnosing | 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., | |||
Data Center TCP, DCTP [I-D.ietf-tcpm-dctcp], and Low Latency Low | Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable | |||
Loss Scalable throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. | throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. | |||
Use of ECN requires feedback a transport to feed back reception | Use of ECN requires a transport to feed back reception information | |||
information on the path towards the data sender. Exposure of this | on the path towards the data sender. Exposure of this Transport | |||
Transport ECN feedback provides an additional powerful tool to | ECN feedback provides an additional powerful tool to understand | |||
understand 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]. | |||
1.1.2. Transport Measurement | 2.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 | |||
VPNs and IPsec. When encryption conceals more layers in a packet, | VPNs and IPsec. When encryption conceals more layers in a packet, | |||
people seeking understanding of the network operation need to rely | people seeking understanding of the network operation need to rely | |||
more on pattern inferences and other heuristics. The accuracy of | more on pattern inferences and other heuristics. The accuracy of | |||
measurements therefore suffers, as does the ability to investigate | measurements therefore suffers, as does the ability to investigate | |||
and troubleshoot interactions between different anomalies. For | and troubleshoot interactions between different anomalies. For | |||
example, the traffic patterns between a web server and a browser are | example, the traffic patterns between a web server and a browser are | |||
skipping to change at page 13, line 5 ¶ | skipping to change at page 13, line 34 ¶ | |||
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. | |||
1.1.2.1. Point of Measurement | 2.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 [I-D.ietf-aqm-fq-codel], combines sub | |||
queues (statistically assigned per flow), management of the queue | queues (statistically assigned per flow), management of the queue | |||
length (CODEL), flow-scheduling, and a starvation prevention | length (CODEL), flow-scheduling, and a starvation prevention | |||
mechanism. Usually such algorithms are designed to be self-tuning, | mechanism. Usually such algorithms are designed to be self-tuning, | |||
but current methods typically employ heuristics that can result in | but current methods typically employ heuristics that can result in | |||
more loss under certain path conditions (e.g., large RTT, effects of | more loss under certain path conditions (e.g., large RTT, effects of | |||
multiple bottlenecks [RFC7567]). | multiple bottlenecks [RFC7567]). | |||
In-network measurements can distinguish between upstream and | In-network measurements can distinguish between upstream and | |||
downstream metrics with respect to the 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. | configuration. | |||
By correlating observations at multiple points along the path (e.g., | By correlating observations at multiple points along the path (e.g., | |||
at the ingress and egress of a network segment), an observer can | at the ingress and egress of a network segment), an observer can | |||
determine the contribution of a portion of the path to an observed | determine the contribution of a portion of the path to an observed | |||
metric (to locate a source of delay, jitter, loss, reordering, | metric (to locate a source of delay, jitter, loss, reordering, | |||
congestion marking, etc.). | congestion marking, etc.). | |||
1.1.2.2. Use by Operators to Plan and Provision Networks | 2.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 traffic and patterns of usage as | need to understand traffic trends and patterns of usage as inputs to | |||
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 this to the | in aggregate traffic can be observed and can be related this 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. | |||
1.1.2.3. Service Performance Measurement | 2.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 available to | used by various actors to help analyse the performance available to | |||
users of a network segment, and inform operational practice. While | users of a network segment, and inform operational practice. While | |||
active measurements may be used in-network passive measurements can | active measurements may be used in-network passive measurements can | |||
have advantages in terms of eliminating unproductive traffic, | have advantages in terms of eliminating unproductive traffic, | |||
reducing the influence of test traffic on the overall traffic mix, | reducing the influence of test traffic on the overall traffic mix, | |||
and the ability to choose the point of measurement Section 1.1.2.1. | and the ability to choose the point of measurement Section 2.2.1. | |||
2.2.4. Measuring Transport to Support Network Operations | ||||
1.1.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 key | |||
transport function. Many network operators implicitly accept that | transport function. Many network operators implicitly accept that | |||
skipping to change at page 14, line 28 ¶ | skipping to change at page 15, line 13 ¶ | |||
struggle to easily duplicate [RFC8085]. | 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 | |||
behaviour for TCP and SCTP. | behaviour for TCP and SCTP. | |||
However when anomolies are detected, tools can interpret the | However when anomalies are detected, tools can interpret the | |||
transport protocol header information to help understand the | transport protocol header information to help understand the | |||
impact of specific transport protocols (or protocol mechanisms) on | impact of specific transport protocols (or protocol mechanisms) on | |||
the other traffic that shares a network. An observation in the | the other traffic that shares a network. An observation in the | |||
network can gain understanding of the dynamics of a flow and its | network can gain understanding of the dynamics of a flow and its | |||
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 transport that has no inherent congestion control | message-passing transport that has no inherent congestion control | |||
mechanisms. Because congestion control is critical to the stable | mechanisms. Because congestion control is critical to the stable | |||
operation of the Internet, applications and other protocols that | operation of the Internet, applications and other protocols that | |||
choose to use UDP as an Internet transport are required to employ | choose to use UDP as a transport are required to employ mechanisms | |||
mechanisms to prevent congestion collapse, avoid unacceptable | to prevent congestion collapse, avoid unacceptable contributions | |||
contributions to jitter/latency, and to establish an acceptable | to jitter/latency, and to establish an acceptable share of | |||
share of capacity with concurrent traffic [RFC8085]. | capacity with concurrent traffic [RFC8085]. | |||
A network operator needs tools to understand if UDP flows comply | A network operator needs tools to understand if UDP flows comply | |||
with congestion control expectations and therefore whether there | with congestion control expectations and therefore whether there | |||
is a need to deploy methods such as rate-limiters, transport | 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 1.1.1.2. | Section 2.1.2. | |||
1.1.3. Use for Network Diagnostics and Troubleshooting | 2.3. Use for Network Diagnostics and Troubleshooting | |||
Transport header information is useful for a variety of operational | Transport header information is useful for a variety of operational | |||
tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, | tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, | |||
assess performance, capacity planning, management of denial of | assess performance, capacity planning, management of denial of | |||
service threats, and responding to user performance questions. These | service threats, and responding to user performance questions. These | |||
tasks seldom involve the need to determine the contents of the | tasks seldom involve the need to determine the contents of the | |||
transport payload, or other application details. | transport payload, or other 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 | |||
skipping to change at page 15, line 39 ¶ | skipping to change at page 16, line 23 ¶ | |||
response to tracing issues, making appropriate Quality of Service, | response to tracing issues, making appropriate Quality of Service, | |||
QoS, decisions). For some this will be blessing, for others it may be | QoS, decisions). For some this will be blessing, for others it may be | |||
a curse. For example, operational performance data about encrypted | a curse. For example, operational performance data about encrypted | |||
flows needs to be determined by traffic pattern analysis, rather than | flows needs to be determined by traffic pattern analysis, rather than | |||
relying on traditional tools. This can impact the ability of the | relying on traditional tools. This can impact the ability of the | |||
operator to respond to faults, it could require reliance on endpoint | operator to respond to faults, it could require reliance on endpoint | |||
diagnostic tools or user involvement in diagnosing and | diagnostic tools or user involvement in diagnosing and | |||
troubleshooting unusual use cases or non-trivial problems. A key | troubleshooting unusual use cases or non-trivial problems. A key | |||
need here is that tools need to provide useful information during | need here is that tools need to provide useful information during | |||
network anomalies (e.g., significant reordering, high or intermittent | network anomalies (e.g., significant reordering, high or intermittent | |||
loss). Although many network operators utilise transport information | loss). Although many network operators utilise transport information | |||
as a part of their operational practice, the network will not break | as a part of their operational practice, the network will not break | |||
because transport headers are encrypted. | because transport headers are encrypted. | |||
1.1.4. Observing Headers to Implement Network Policy | 2.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 QoS management for resource-constrained networks and by firewalls | for QoS management for resource-constrained networks and by firewalls | |||
that use the information to implement access rules. Traffic that | that use the information to implement access rules. Traffic that | |||
cannot be classified, will typically receive a default treatment. | cannot be classified, will typically receive a default treatment. | |||
2. Encryption and Authentication of Transport Headers | 3. 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 16, line 30 ¶ | skipping to change at page 17, line 21 ¶ | |||
this, a method that authenticates transport headers may help improve | this, a method that authenticates transport headers may help improve | |||
the pace of transport development, by eliminating the need to always | the pace of transport development, by eliminating the need to always | |||
consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or | consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or | |||
potentially to only explicitly enable middlebox use for particular | potentially to only explicitly enable middlebox use for particular | |||
paths with particular middleboxes that are deliberately deployed to | paths with particular middleboxes that are deliberately deployed to | |||
realise a useful function for the network and/or users[RFC3135]. | realise a useful function for the network and/or users[RFC3135]. | |||
Another motivation stems from increased concerns about privacy and | Another motivation stems from increased concerns about privacy and | |||
surveillance. Some Internet users have valued the ability to protect | surveillance. Some Internet users have valued the ability to protect | |||
identity, user location, and defend against traffic analysis, and | identity, user location, and defend against traffic analysis, and | |||
have used methods such as IPsec ESP and Tor [Tor]. Revelations about | have used methods such as IPsec ESP. Revelations about the use of | |||
the use of pervasive surveillance [RFC7624] have, to some extent, | pervasive surveillance [RFC7624] have, to some extent, eroded trust | |||
eroded trust in the service offered by network operators, and | in the service offered by network operators, and following the | |||
following the Snowden revelation in the USA in 2013 has led to an | Snowden revelation in the USA in 2013 has led to an increased desire | |||
increased desire for people to employ encryption to avoid unwanted | for people to employ encryption to avoid unwanted "eavesdropping" on | |||
"eavesdropping" on their communications. Whatever the reasons, there | their communications. Whatever the reasons, there are now activities | |||
are now activities in the IETF to design new protocols that may | in the IETF to design new protocols that may include some form of | |||
include some form of transport header encryption (e.g., QUIC [I-D | transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]). | |||
.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 the IPv6 Flow | decisions reflect the need of transport protocols, such the IPv6 Flow | |||
Label [RFC6437], the Differentiated Services Code Point (DSCP) | Label [RFC6437], the DSCP and ECN. | |||
[RFC2474] and Explicit Congestion Notification (ECN) [RFC3168]. | ||||
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 | |||
and users. | and users. | |||
o On the one hand, future Internet protocols that enable large-scale | o On the one hand, future Internet protocols that enable large-scale | |||
encryption assist in the restoration of the end-to-end nature of | encryption assist in the restoration of the end-to-end nature of | |||
the Internet by returning complex processing to the endpoints, | the Internet by returning complex processing to the endpoints, | |||
since middleboxes cannot modify what they cannot see. | since middleboxes cannot modify what they cannot see. | |||
skipping to change at page 17, line 18 ¶ | skipping to change at page 18, line 16 ¶ | |||
understand the dynamics of protocols and traffic patterns. | understand the dynamics of protocols and traffic patterns. | |||
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. | of evolution of the TCP/IP stack. | |||
The next subsections briefly review some security design options for | The next subsections briefly review some security design options for | |||
transport protocols. | transport protocols. | |||
2.1. Authenticating the Transport Protocol Header | 3.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 17, line 40 ¶ | skipping to change at page 18, line 38 ¶ | |||
including the IP pseudo header, TCP header, and TCP data. TCP-AO | including the IP pseudo header, TCP header, and TCP data. TCP-AO | |||
protects the transport layer, preventing attacks from disabling the | protects the transport layer, preventing attacks from disabling the | |||
TCP connection itself. TCP-AO may interact with middleboxes, | TCP connection itself. TCP-AO may interact with middleboxes, | |||
depending on their behaviour [RFC3234]. | depending on their behaviour [RFC3234]. | |||
The IPsec Authentication Header (AH) [RFC4302] works at the network | The IPsec Authentication Header (AH) [RFC4302] works at the network | |||
layer and authenticates the IP payload. This therefore also | layer and authenticates the IP payload. This therefore also | |||
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. | |||
2.2. Encrypting the Transport Payload | 3.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 2.1). | check (Section 3.1). | |||
Examples of encrypting the payload include Transport Layer Security | Examples of encrypting the payload include Transport Layer Security | |||
(TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP | (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP | |||
[RFC6347] [RFC7525]. | [RFC6347] [RFC7525]. | |||
2.3. Encrypting the Transport Header | 3.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 payload). This method does not expose any | transport header and payload). This method does not expose any | |||
transport information to devices in the network, which also prevents | transport information to devices in the network, which also prevents | |||
modification along the network path. | modification along a network path. | |||
The IPsec Encapsulating Security Payload (ESP) [RFC4303] is an | The IPsec Encapsulating Security Payload (ESP) [RFC4303] is an | |||
example of encryption at the network layer, it encrypts and | example of encryption at the network layer, it encrypts and | |||
authenticates all transport headers, preventing visibility of the | authenticates all transport headers, preventing visibility of the | |||
headers by in-network devices. Some Virtual Private Network (VPN) | headers by in-network devices. Some Virtual Private Network (VPN) | |||
methods also encrypt these headers. | methods also encrypt these headers. | |||
2.4. Authenticating Transport Information and Selectively Encrypting | 3.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. | |||
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 | |||
skipping to change at page 18, line 46 ¶ | skipping to change at page 19, line 33 ¶ | |||
designer to decide which header fields to encrypt. On the one hand, | designer to decide which header fields to encrypt. On the one hand, | |||
security work typically employs a design technique that seeks to | security work typically employs a design technique that seeks to | |||
expose only what is needed. On the other hand, there may be | expose only what is needed. On the other hand, there may be | |||
performance and operational benefits in exposing selected information | performance and operational benefits in exposing selected information | |||
to network tools. | to network tools. | |||
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. | |||
2.5. Adding Transport Information to Network-Layer Protocol Headers | 3.5. Adding Transport Information to Network-Layer Protocol Headers | |||
The transport information can be made visible in a network-layer | The transport 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 | |||
to packets at the ingress to a maintenance domain (e.g., an Ethernet | to packets at the ingress to a maintenance domain (e.g., an Ethernet | |||
protocol header with timestamps and sequence number information using | protocol header with timestamps and sequence number information using | |||
a method such as 802.11ag) and removing the additional header at the | a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) | |||
egress of the maintenance domain. This approach enables some types | and removing the additional header at the egress of the maintenance | |||
of measurements, but does not cover the entire range of measurements | domain. This approach enables some types of measurements, but does | |||
described in this document. | not cover the entire range of measurements described in this | |||
document. In some cases, it can be difficult to position measurement | ||||
tools at the required segments/nodes and there can be challenges in | ||||
correlating the downsream/upstream information when in-band OAM data | ||||
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 [I-D.ietf-ippm-6man- | |||
pdm-option]. This allows a sender to optionally include a | pdm-option]. This allows a sender to optionally include a | |||
destination option that caries header fields that can be used to | destination option that caries header fields that can be used to | |||
observe timestamps and packet sequence numbers. This information | observe timestamps and packet sequence numbers. This information | |||
could be authenticated by receiving transport endpoints when the | could be authenticated by receiving transport endpoints when the | |||
information is added at the sender and visible at the receiving | information is added at the sender and visible at the receiving | |||
endpoint, although methods to do this have not currently been | endpoint, although methods to do this have not currently been | |||
proposed. This method needs to be explicitly enabled at the sender. | proposed. This method needs to be explicitly enabled at the sender. | |||
A drawback of using extension headers is that IPv4 network options | It can be undesirable to rely on methods requiring options or | |||
are often not supported (or are carried on a slower processing path) | extension headers. IPv4 network options are often not supported (or | |||
and some IPv6 networks are also known to drop packets that set an | are carried on a slower processing path) and some IPv6 networks are | |||
IPv6 header extension. Another disadvantage is that protocols that | also known to drop packets that set an IPv6 header extension (e.g., | |||
separately expose header information do not necessarily have an | [RFC7872]). Another disadvantage is that protocols that separately | |||
advantage to expose the information that is utilised by the protocol | expose header information do not necessarily have an advantage to | |||
itself, and could manipulate this header information to gain an | expose the information that is utilised by the protocol itself, and | |||
advantage from the network. | could manipulate this header information to gain an advantage from | |||
the network. | ||||
3. Implications of Protecting the Transport Headers | 4. Implications of Protecting the Transport Headers | |||
This section explores key implications of working with encrypted | This section explores key implications of working with encrypted | |||
transport protocols. | transport protocols. | |||
3.1. Independent Measurement | 4.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 | |||
could be possible for an applications to provide summary data on | could be possible for an applications to provide summary data on | |||
performance and usage of the network. This data could be made | performance and usage of the network. This data could be made | |||
available to other actors. However, this data needs to contain | available to other actors. However, this data needs to contain | |||
sufficient detail to understand (and possibly reconstruct the network | sufficient detail to understand (and possibly reconstruct the network | |||
traffic pattern for further testing) and to be correlated with the | traffic pattern for further testing) and to be correlated with the | |||
configuration of the network paths being measured. Sharing | configuration of the network paths being measured. Sharing | |||
information between actors needs also to consider the privacy of the | information between actors needs also to consider the privacy of the | |||
skipping to change at page 20, line 28 ¶ | skipping to change at page 21, line 24 ¶ | |||
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. | |||
3.2. Characterising "Unknown" Network Traffic | 4.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 20, line 50 ¶ | skipping to change at page 21, line 46 ¶ | |||
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. | |||
3.3. Accountability and Internet Transport Protocols | 4.3. Accountability and Internet Transport Protocols | |||
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, and where needed to | flows from acquiring excessive network capacity, and where needed to | |||
deploy appropriate tools Section 1.1.2.4. Obfuscating or hiding this | deploy appropriate tools Section 2.2.4. Obfuscating or hiding this | |||
information using encryption is expected to lead operators and | information using encryption is expected to lead operators and | |||
maintainers of middleboxes (firewalls, etc.) to seek other methods to | maintainers of middleboxes (firewalls, etc.) to seek other methods to | |||
classify and mechanisms to condition network traffic. A lack of data | classify and mechanisms to condition network traffic. | |||
seems likely to reduce the level of precision with which these | ||||
mechanisms are applied, and this needs to be considered when | ||||
evaluating the impact of designs for transport encryption. | ||||
3.4. Impact on Research, Development and Deployment | A lack of data seems likely to reduce the level of precision with | |||
which these mechanisms are applied, and this needs to be considered | ||||
when evaluating the impact of designs for transport encryption. This | ||||
could lead to increased use of rate limiting, circuit breaker | ||||
techniques [RFC8084], or even blocking of uncharacterised traffic. | ||||
This would hinder deployment of new mechanisms and/or protocols. | ||||
4.4. Impact on Research, Development and Deployment | ||||
Measurement data is increasingly being used to inform design | Measurement data is increasingly being used to inform design | |||
decisions in networking research, during development of new | 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. | |||
skipping to change at page 21, line 41 ¶ | skipping to change at page 22, line 38 ¶ | |||
therefore typically evolve as a protocol matures, or in response to | therefore typically evolve as a protocol matures, or in response to | |||
changes in network conditions, changes in network traffic or changes | changes in network conditions, changes in network traffic or changes | |||
to application usage. | to application usage. | |||
The growth and diversity of applications and protocols using the | The growth and diversity of applications and protocols using the | |||
Internet continues to expand - and there has been recent interest in | Internet continues to expand - and there has been recent interest in | |||
a wide range of new transport methods, e.g., Larger Initial Window, | a wide range of new transport methods, e.g., Larger Initial Window, | |||
Proportional Rate Reduction (PRR), congestion control methods based | Proportional Rate Reduction (PRR), congestion control methods based | |||
on measuring bottleneck bandwidth and round-trip propagation time, | on measuring bottleneck bandwidth and round-trip propagation time, | |||
the introduction of AQM techniques and new forms of ECN response | the introduction of AQM techniques and new forms of ECN response | |||
(e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods | (e.g., DCTP, and methods proposed for L4S). For each new method it is | |||
proposed for Low Latency Low Loss Scalable throughput, L4S). For | desirable to build a body of data reflecting its behaviour under a | |||
each new method it is desirable to build a body of data reflecting | wide range of deployment scenarios, traffic load, and interactions | |||
its behaviour under a wide range of deployment scenarios, traffic | with other deployed/candidate methods. | |||
load, and interactions with other 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. | |||
4. Acknowledgements | 5. Acknowledgements | |||
The author would like to thank all who have talked to him face-to- | The author would like to thank all who have talked to him face-to- | |||
face or via email. ... | face or via email. ... | |||
This work has received funding from the European Union's Horizon 2020 | This work has received funding from the European Union's Horizon 2020 | |||
research and innovation programme under grant agreement No 688421.The | research and innovation programme under grant agreement No 688421.The | |||
opinions expressed and arguments employed reflect only the authors' | opinions expressed and arguments employed reflect only the authors' | |||
view. The European Commission is not responsible for any use that | view. The European Commission is not responsible for any use that | |||
may be made of that information. | may be made of that information. | |||
5. Security Considerations | 6. Security Considerations | |||
This document is about design and deployment considerations for | This document is about design and deployment considerations for | |||
transport protocols. Authentication, confidentiality protection, and | transport protocols. Authentication, confidentiality protection, and | |||
integrity protection are identified as Transport Features by | integrity protection are identified as Transport Features by | |||
RFC8095". As currently deployed in the Internet, these features are | RFC8095". As currently deployed in the Internet, these features are | |||
generally provided by a protocol or layer on top of the transport | generally provided by a protocol or layer on top of the transport | |||
protocol; no current full-featured standards-track transport protocol | protocol; no current full-featured standards-track transport protocol | |||
provides these features on its own. Therefore, these features are | provides these features on its own. Therefore, these features are | |||
not considered in this document, with the exception of native | not considered in this document, with the exception of native | |||
authentication capabilities of TCP and SCTP for which the security | authentication capabilities of TCP and SCTP for which the security | |||
skipping to change at page 22, line 34 ¶ | skipping to change at page 23, line 34 ¶ | |||
Open data, and accessibility to tools that can help understand trends | Open data, and accessibility to tools that can help understand trends | |||
in application deployment, network traffic and usage patterns can all | in application deployment, network traffic and usage patterns can all | |||
contribute to understanding security challenges. Standard protocols | contribute to understanding security challenges. Standard protocols | |||
and understanding of the interactions between mechanisms and traffic | and understanding of the interactions between mechanisms and traffic | |||
patterns can also provide valuable insight into appropriate security | patterns can also provide valuable insight into appropriate security | |||
design. Like congestion control mechanisms, security mechanisms are | design. Like congestion control mechanisms, security mechanisms are | |||
difficult to design and implement correctly. It is hence recommended | difficult to design and implement correctly. It is hence recommended | |||
that applications employ well-known standard security mechanisms such | that applications employ well-known standard security mechanisms such | |||
as DTLS, TLS or IPsec, rather than inventing their own. | as DTLS, TLS or IPsec, rather than inventing their own. | |||
6. IANA Considerations | 7. 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. | |||
7. References | 8. References | |||
7.1. Normative References | 8.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | |||
RFC2119, March 1997, <http://www.rfc-editor.org/info/ | RFC2119, March 1997, <http://www.rfc-editor.org/info/ | |||
rfc2119>. | rfc2119>. | |||
7.2. Informative References | 8.2. Informative References | |||
[I-D.dolson-plus-middlebox-benefits] | [I-D.dolson-plus-middlebox-benefits] | |||
Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, | Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, | |||
"Beneficial Functions of Middleboxes", Internet-Draft | "Beneficial Functions of Middleboxes", Internet-Draft | |||
draft-dolson-plus-middlebox-benefits-03, March 2017. | draft-dolson-plus-middlebox-benefits-03, March 2017. | |||
[I-D.ietf-aqm-codel] | [I-D.ietf-aqm-codel] | |||
Nichols, K., Jacobson, V., McGregor, A. and J. Jana, | Nichols, K., Jacobson, V., McGregor, A. and J. Jana, | |||
"Controlled Delay Active Queue Management", Internet-Draft | "Controlled Delay Active Queue Management", Internet-Draft | |||
draft-ietf-aqm-codel-00, October 2014. | draft-ietf-aqm-codel-00, October 2014. | |||
skipping to change at page 23, line 25 ¶ | skipping to change at page 24, line 25 ¶ | |||
Lightweight Control Scheme To Address the Bufferbloat | Lightweight Control Scheme To Address the Bufferbloat | |||
Problem", Internet-Draft draft-ietf-aqm-pie-00, October | Problem", Internet-Draft draft-ietf-aqm-pie-00, October | |||
2014. | 2014. | |||
[I-D.ietf-ippm-6man-pdm-option] | [I-D.ietf-ippm-6man-pdm-option] | |||
Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, | Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, | |||
"IPv6 Performance and Diagnostic Metrics (PDM) Destination | "IPv6 Performance and Diagnostic Metrics (PDM) Destination | |||
Option", Internet-Draft draft-ietf-ippm-6man-pdm- | Option", Internet-Draft draft-ietf-ippm-6man-pdm- | |||
option-10, May 2017. | option-10, May 2017. | |||
[I-D.ietf-ippm-ioam-data] | ||||
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | ||||
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | ||||
P., Chang, R. and d. daniel.bernier@bell.ca, "Data Fields | ||||
for In-situ OAM", Internet-Draft draft-ietf-ippm-ioam- | ||||
data-01, October 2017. | ||||
[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", Internet-Draft draft-ietf-quic- | |||
transport-03, May 2017. | transport-03, May 2017. | |||
[I-D.ietf-tcpm-accurate-ecn] | [I-D.ietf-tcpm-accurate-ecn] | |||
Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More | Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More | |||
Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- | Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- | |||
tcpm-accurate-ecn-00, December 2015. | tcpm-accurate-ecn-00, December 2015. | |||
[I-D.ietf-tcpm-dctcp] | ||||
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. | ||||
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion | ||||
Control for Datacenters", Internet-Draft draft-ietf-tcpm- | ||||
dctcp-06, May 2017. | ||||
[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", Internet-Draft draft-ietf-tsvwg-l4s- | |||
arch-00, May 2017. | arch-00, May 2017. | |||
[I-D.mm-wg-effect-encrypt] | [I-D.mm-wg-effect-encrypt] | |||
Moriarty, K. and A. Morton, "Effect of Pervasive | Moriarty, K. and A. Morton, "Effect of Pervasive | |||
Encryption on Operators", Internet-Draft draft-mm-wg- | Encryption on Operators", Internet-Draft draft-mm-wg- | |||
effect-encrypt-11, April 2017. | effect-encrypt-11, April 2017. | |||
skipping to change at page 24, line 15 ¶ | skipping to change at page 25, line 17 ¶ | |||
"Transport-Independent Path Layer State Management", | "Transport-Independent Path Layer State Management", | |||
Internet-Draft draft-trammell-plus-statefulness-02, | Internet-Draft draft-trammell-plus-statefulness-02, | |||
December 2016. | 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- | ||||
Level Reachability in the Global TCP/IP Internet: Goals, | ||||
Experimental Design, Implementation, and Policy | ||||
Considerations", RFC 1273, DOI 10.17487/RFC1273, November | ||||
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, DOI | |||
10.17487/RFC2474, December 1998, <http://www.rfc- | 10.17487/RFC2474, December 1998, <http://www.rfc- | |||
editor.org/info/rfc2474>. | editor.org/info/rfc2474>. | |||
[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, DOI | |||
10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/ | 10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/ | |||
skipping to change at page 25, line 42 ¶ | skipping to change at page 26, line 52 ¶ | |||
rfc5246>. | rfc5246>. | |||
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) | [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) | |||
Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, | Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, | |||
<http://www.rfc-editor.org/info/rfc5559>. | <http://www.rfc-editor.org/info/rfc5559>. | |||
[RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | |||
June 2010, <http://www.rfc-editor.org/info/rfc5925>. | June 2010, <http://www.rfc-editor.org/info/rfc5925>. | |||
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. | ||||
Roberts, "Issues with IP Address Sharing", RFC 6269, DOI | ||||
10.17487/RFC6269, June 2011, <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, <http://www.rfc-editor.org/info/rfc6347>. | |||
[RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, | [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, | |||
"IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ | "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ | |||
RFC6437, November 2011, <http://www.rfc-editor.org/info/ | RFC6437, November 2011, <http://www.rfc-editor.org/info/ | |||
rfc6437>. | rfc6437>. | |||
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. | [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. | |||
skipping to change at page 26, line 32 ¶ | skipping to change at page 27, line 46 ¶ | |||
"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, DOI | |||
10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/ | 10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/ | |||
info/rfc7624>. | info/rfc7624>. | |||
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) | [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) | |||
Concepts, Abstract Mechanism, and Requirements", RFC 7713, | Concepts, Abstract Mechanism, and Requirements", RFC 7713, | |||
DOI 10.17487/RFC7713, December 2015, <http://www.rfc- | DOI 10.17487/RFC7713, December 2015, <http://www.rfc- | |||
editor.org/info/rfc7713>. | editor.org/info/rfc7713>. | |||
[RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations | ||||
on the Dropping of Packets with IPv6 Extension Headers in | ||||
the Real World", RFC 7872, 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 D. | |||
Ros, "Characterization Guidelines for Active Queue | 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, <http://www.rfc-editor.org/info/rfc7928>. | |||
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP | [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP | |||
208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http:// | 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http:// | |||
www.rfc-editor.org/info/rfc8084>. | www.rfc-editor.org/info/rfc8084>. | |||
[RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage | [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage | |||
skipping to change at page 26, line 54 ¶ | skipping to change at page 28, line 22 ¶ | |||
[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-in- | |||
UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March | UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March | |||
2017, <http://www.rfc-editor.org/info/rfc8086>. | 2017, <http://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, DOI | |||
10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/ | 10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/ | |||
info/rfc8087>. | info/rfc8087>. | |||
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. | ||||
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion | ||||
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, | ||||
October 2017, <https://www.rfc-editor.org/info/rfc8257>. | ||||
[Tor] The Tor Project, ., "https://www.torproject.org", June | [Tor] The Tor Project, ., "https://www.torproject.org", June | |||
2017. | 2017. | |||
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. | |||
-03 This draft follows feedback from people reading this draft. | -03 This draft follows feedback from people reading this draft. | |||
-04 This adds an additional contributore and includes significant | -04 This adds an additional contributor and includes significant | |||
reworking to ready this for review by the wider IETF community Colin | reworking to ready this for review by the wider IETF community Colin | |||
Perkins joined the author list. | Perkins joined the author list. | |||
Comments from the community are welcome on the text and | Comments from the community are welcome on the text and | |||
recommendations. | recommendations. | |||
Authors' Addresses | -05 Corrections received and helpful inputs from Mohamed Boucadair. | |||
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/ | |||
End of changes. 99 change blocks. | ||||
266 lines changed or deleted | 327 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |