draft-ietf-tsvwg-transport-encrypt-04.txt | draft-ietf-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. Perkins | Intended status: Informational C. Perkins | |||
Expires: August 22, 2019 University of Glasgow | Expires: September 10, 2019 University of Glasgow | |||
February 18, 2019 | March 9, 2019 | |||
The Impact of Transport Header Confidentiality on Network Operation and | The Impact of Transport Header Confidentiality on Network Operation and | |||
Evolution of the Internet | Evolution of the Internet | |||
draft-ietf-tsvwg-transport-encrypt-04 | draft-ietf-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 in-network uses of | encryption at the transport layer. It identifies in-network uses of | |||
transport layer header information. It then reviews the implications | transport layer header information. It then reviews the implications | |||
of developing end-to-end transport protocols that use authentication | of developing end-to-end transport protocols that use authentication | |||
to protect the integrity of transport information or encryption to | to protect the integrity of transport information or encryption to | |||
provide confidentiality of the transport protocol header and expected | provide confidentiality of the transport protocol header and expected | |||
implications of transport protocol design and network operation. | implications of transport protocol design and network operation. | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 22, 2019. | This Internet-Draft will expire on September 10, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 30 ¶ | skipping to change at page 2, line 30 ¶ | |||
3.1. Observing Transport Information in the Network . . . . . 10 | 3.1. Observing Transport Information in the Network . . . . . 10 | |||
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 16 | 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 16 | |||
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 20 | 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 20 | |||
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 21 | 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 21 | |||
4. Encryption and Authentication of Transport Headers . . . . . 21 | 4. Encryption and Authentication of Transport Headers . . . . . 21 | |||
5. Addition of Transport Information to Network-Layer Protocol | 5. Addition of Transport Information to Network-Layer Protocol | |||
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
6. Implications of Protecting the Transport Headers . . . . . . 26 | 6. Implications of Protecting the Transport Headers . . . . . . 26 | |||
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 26 | 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 26 | |||
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 28 | 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 28 | |||
6.3. Accountability and Internet Transport Protocols . . . . . 28 | 6.3. Accountability and Internet Transport Protocols . . . . . 29 | |||
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 29 | 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 29 | |||
6.5. Impact on Research, Development and Deployment . . . . . 30 | 6.5. Impact on Research, Development and Deployment . . . . . 30 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 35 | 11. Informative References . . . . . . . . . . . . . . . . . . . 35 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . 42 | Appendix A. Revision information . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
skipping to change at page 3, line 17 ¶ | skipping to change at page 3, line 17 ¶ | |||
This document discusses some consequences of applying end-to-end | This document discusses some consequences of applying end-to-end | |||
encryption at the transport layer. It reviews the implications of | encryption at the transport layer. It reviews the implications of | |||
developing end-to-end transport protocols that use encryption to | developing end-to-end transport protocols that use encryption to | |||
provide confidentiality of the transport protocol header, and | provide confidentiality of the transport protocol header, and | |||
considers the effect of such changes on transport protocol design and | considers the effect of such changes on transport protocol design and | |||
network operations. It also considers anticipated implications on | network operations. It also considers anticipated implications on | |||
transport and application evolution. | transport and application evolution. | |||
Transports are increasingly encrypting and authenticating the payload | Transports are increasingly encrypting and authenticating the payload | |||
(i.e., the application data carried within the transport connection) | (i.e., the application data carried within the transport connection) | |||
end-to-end. Such protection is encouraged, and the implications are | end-to-end. Such protection is encouraged, and the implications of | |||
not further discussed in this memo. | protecting the payload are not further discussed in this memo. | |||
2. Context and Rationale | 2. Context and Rationale | |||
The transport layer provides end-to-end interactions between | The transport layer provides end-to-end interactions between | |||
endpoints (processes) using an Internet path. Transport protocols | endpoints (processes) using an Internet path. Transport protocols | |||
layer directly over the network-layer service and are sent in the | layer directly over the network-layer service and are sent in the | |||
payload of network-layer packets. They support end-to-end | payload of network-layer packets. They support end-to-end | |||
communication between applications, supported by higher-layer | communication between applications, supported by higher-layer | |||
protocols, running on the end systems (or transport endpoints). This | protocols, running on the end systems (or transport endpoints). This | |||
simple architectural view hides one of the core functions of the | simple architectural view hides one of the core functions of the | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, line 7 ¶ | |||
and at the flow level. | and at the flow level. | |||
There are many motivations for deploying encrypted transports | There are many motivations for deploying encrypted transports | |||
[RFC7624] (i.e., transport protocols that use encryption to provide | [RFC7624] (i.e., transport protocols that use encryption to provide | |||
confidentiality of some or all of the transport-layer header | confidentiality of some or all of the transport-layer header | |||
information), and encryption of transport payloads (i.e. | information), and encryption of transport payloads (i.e. | |||
Confidentiality of the payload data). The increasing public concerns | Confidentiality of the payload data). The increasing public concerns | |||
about interference with Internet traffic have led to a rapidly | about interference with Internet traffic have led to a rapidly | |||
expanding deployment of encryption to protect end-user privacy, e.g., | expanding deployment of encryption to protect end-user privacy, e.g., | |||
QUIC [I-D.ietf-quic-transport]. Encryption is also expected to form | QUIC [I-D.ietf-quic-transport]. Encryption is also expected to form | |||
a basis of future transport protocol designs. | a basis for future transport protocol designs. | |||
Some network operators and access providers have come to rely on the | Some network operators and access providers have come to rely on the | |||
in-network measurement of transport properties and the functionality | in-network measurement of transport properties and the functionality | |||
provided by middleboxes to both support network operations and | provided by middleboxes to both support network operations and | |||
enhance performance. There can therefore be implications when | enhance performance. There can therefore be implications when | |||
working with encrypted transport protocols that hide transport header | working with encrypted transport protocols that hide transport header | |||
information from the network. These present architectural challenges | information from the network. These present architectural challenges | |||
and considerations in the way transport protocols are designed, and | and considerations in the way transport protocols are designed, and | |||
ability to characterise and compare different transport solutions | ability to characterise and compare different transport solutions | |||
[Measure]. Implementations of network devices are encouraged to | [Measure]. Implementations of network devices are encouraged to | |||
avoid side-effects when protocols are updated. Introducing | avoid side-effects when protocols are updated. Introducing | |||
cryptographic integrity checks to header fields can also prevent | cryptographic integrity checks to header fields can also prevent | |||
undetected manipulation of the field by network devices, or | undetected manipulation of the field by network devices, or | |||
undetected addition of information to a packet. However, this does | undetected addition of information to a packet. However, this does | |||
not prevent inspection of the information by a device on path, and it | not prevent inspection of the information by a device on path, and it | |||
is possible that such devices could develop mechanisms that rely on | is possible that such devices could develop mechanisms that rely on | |||
the presence of such a field, or a known value in the field. | the presence of such a field or a known value in the field. | |||
Reliance on the presence and semantics of specific header information | Reliance on the presence and semantics of specific header information | |||
leads to ossification. An endpoint could be required to supply a | leads to ossification. An endpoint could be required to supply a | |||
specific header to receive the network service that it desires. In | specific header to receive the network service that it desires. In | |||
some cases, this could be benign or advantageous to the protocol | some cases, this could be benign or advantageous to the protocol | |||
(e.g., recognising the start of a connection, or explicitly exposing | (e.g., recognising the start of a connection, or explicitly exposing | |||
protocol information can be expected to provide more consistent | protocol information can be expected to provide more consistent | |||
decisions by on-path devices than the use of diverse methods to infer | decisions by on-path devices than the use of diverse methods to infer | |||
semantics from other flow properties); in other cases this is not | semantics from other flow properties); in other cases this is not | |||
beneficial (e.g., a mechanism implemented in a network device, such | beneficial (e.g., a mechanism implemented in a network device, such | |||
as a firewall, that required a header field to have only a specific | as a firewall, that required a header field to have only a specific | |||
known set of values could prevent the device from forwarding packets | known set of values could prevent the device from forwarding packets | |||
using a different version of a protocol that introduces a new feature | using a different version of a protocol that introduces a new feature | |||
that changes the value present in this field, preventing evolution of | that changes the value present in this field, preventing the | |||
the protocol). Experience developing Transport Layer Security | evolution of the protocol). Experience developing Transport Layer | |||
[RFC8446], required a design that recognised that deployed | Security [RFC8446], required a design that recognised that deployed | |||
middleboxes relied on the exposed information in TLS 1.2 | middleboxes relied on the exposed information in TLS 1.2 | |||
Examples of the impact of ossification on transport protocol design | Examples of the impact of ossification on transport protocol design | |||
and ease of deployment can be seen in the case of Multipath TCP | and ease of deployment can be seen in the case of Multipath TCP | |||
(MPTCP) and the TCP Fast Open option. The design of MPTCP had to be | (MPTCP) and the TCP Fast Open option. The design of MPTCP had to be | |||
revised to account for middleboxes, so called "TCP Normalizers", that | revised to account for middleboxes, so called "TCP Normalizers", that | |||
monitor the evolution of the window advertised in the TCP headers and | monitor the evolution of the window advertised in the TCP headers and | |||
that reset connections if the window does not grow as expected. | that reset connections if the window does not grow as expected. | |||
Similarly, TCP Fast Open has had issues with middleboxes that remove | Similarly, TCP Fast Open has had issues with middleboxes that remove | |||
unknown TCP options, that drop segments with unknown TCP options, | unknown TCP options, that drop segments with unknown TCP options, | |||
skipping to change at page 5, line 17 ¶ | skipping to change at page 5, line 17 ¶ | |||
coded understanding of transport behaviour, and that interacted | coded understanding of transport behaviour, and that interacted | |||
poorly with transports that tried to change that behaviour. Other | poorly with transports that tried to change that behaviour. Other | |||
examples have included middleboxes that rewrite TCP sequence and | examples have included middleboxes that rewrite TCP sequence and | |||
acknowledgement numbers but are unaware of the (newer) SACK option | acknowledgement numbers but are unaware of the (newer) SACK option | |||
and don't correctly rewrite selective acknowledgements to match the | and don't correctly rewrite selective acknowledgements to match the | |||
changes made to the fixed TCP header. | changes made to the fixed TCP header. | |||
A protocol design that uses header encryption can provide | A protocol design that uses header encryption can provide | |||
confidentiality of some or all of the protocol header information. | confidentiality of some or all of the protocol header information. | |||
Encryption with secure key distribution prevents an on-path device | Encryption with secure key distribution prevents an on-path device | |||
from observing the header field. It therefore prevents mechanisms | from observing the header field. It, therefore, prevents mechanisms | |||
being built that directly rely on the information or seek to infer | being built that directly rely on the information or seek to infer | |||
semantics of an exposed header field. Using encryption to provide | semantics of an exposed header field. Using encryption to provide | |||
confidentiality of the transport layer brings some well-known privacy | confidentiality of the transport layer brings some well-known privacy | |||
and security benefits and can therefore help reduce ossification of | and security benefits and can therefore help reduce ossification of | |||
the transport layer. In particular, it is important that protocols | the transport layer. In particular, it is important that protocols | |||
either do not expose information where the usage could change in | either do not expose information where the usage could change in | |||
future protocols, or that methods that utilise the information are | future protocols or that methods that utilise the information are | |||
robust to potential changes as protocols evolve over time. To avoid | robust to potential changes as protocols evolve over time. To avoid | |||
unwanted inspection, a protocol could also intentionally vary the | unwanted inspection, a protocol could also intentionally vary the | |||
format and/or value of header fields (sometimes known as Greasing | format and/or value of header fields (sometimes known as Greasing | |||
[I-D.thomson-quic-grease]). However, while encryption hides the | [I-D.thomson-quic-grease]). However, while encryption hides the | |||
protocol header information, it does not prevent ossification of the | protocol header information, it does not prevent ossification of the | |||
network service. People seeking understanding of network traffic | network service. People seeking to understand network traffic could | |||
could come to rely on pattern inferences and other heuristics as the | come to rely on pattern inferences and other heuristics as the basis | |||
basis for network decision and to derive measurement data, creating | for network decision and to derive measurement data, creating new | |||
new dependencies on the transport protocol. | dependencies on the transport protocol. | |||
Specification of non-encrypted transport header fields explicitly | Specification of non-encrypted transport header fields explicitly | |||
allows protocol designers to make specific header information | allows protocol designers to make specific header information | |||
observable in the network. This supports other uses of this | observable in the network. This supports other uses of this | |||
information by on-path devices, and at the same time this can be | information by on-path devices, and at the same time this can be | |||
expected to lead to ossification of the transport header, because | expected to lead to ossification of the transport header, because | |||
network forwarding could evolve to depend on the presence and/or | network forwarding could evolve to depend on the presence and/or | |||
value of these fields. The decision about which transport headers | value of these fields. The decision about which transport headers | |||
fields are made observable offers trade-offs around authentication | fields are made observable offers trade-offs around authentication | |||
and confidentiality versus observability, network operations and | and confidentiality versus observability, network operations and | |||
management, and ossification. For example, a design that provides | management, and ossification. For example, a design that provides | |||
confidentiality of protocol header information can impact the | confidentiality of protocol header information can impact the | |||
following activities that rely on measurement and analysis of traffic | following activities that rely on measurement and analysis of traffic | |||
flows: | flows: | |||
Network Operations and Research: Observable transport headers enable | Network Operations and Research: Observable transport headers enable | |||
both operators and the research community to explicitly measure | both operators and the research community to explicitly measure | |||
and analyse protocol performance, network anomalies, and failure | and analyse protocol performance, network anomalies, and failure | |||
pathologies. | pathologies. | |||
This information can help inform capacity planning, and assist in | This information can help inform capacity planning and assist in | |||
determining the need for equipment and/or configuration changes by | determining the need for equipment and/or configuration changes by | |||
network operators. | network operators. | |||
The data can also inform Internet engineering research, and help | The data can also inform Internet engineering research, and help | |||
in the development of new protocols, methodologies, and | in the development of new protocols, methodologies, and | |||
procedures. Concealing the transport protocol header information | procedures. Concealing the transport protocol header information | |||
makes the stream performance unavailable to passive observers | makes the stream performance unavailable to passive observers | |||
along the path, and likely leads to the development of alternative | along the path, and likely leads to the development of alternative | |||
methods to collect or infer that data (for example heuristics | methods to collect or infer that data (for example heuristics | |||
based on analysis of traffic patterns). | based on the analysis of traffic patterns). | |||
Providing confidentiality of the transport payload, but leaving | Providing confidentiality of the transport payload, but leaving | |||
some, or all, of the transport headers unencrypted, possibly with | some, or all, of the transport headers unencrypted, possibly with | |||
authentication, can provide many of the privacy and security | authentication, can provide many of the privacy and security | |||
benefits while supporting operations and research, but at the cost | benefits while supporting operations and research, but at the cost | |||
of ossifying the transport headers. | of ossifying the transport headers. | |||
Protection from Denial of Service: Observable transport headers | Protection from Denial of Service: Observable transport headers | |||
currently provide useful input to classify traffic and detect | currently provide useful input to classify traffic and detect | |||
anomalous events (e.g., changes in application behaviour, | anomalous events (e.g., changes in application behaviour, | |||
skipping to change at page 7, line 13 ¶ | skipping to change at page 7, line 13 ¶ | |||
functions in equipment or adding traffic overhead). | functions in equipment or adding traffic overhead). | |||
Network Traffic Analysis: Hiding transport protocol header | Network Traffic Analysis: Hiding transport protocol header | |||
information can make it harder to determine which transport | information can make it harder to determine which transport | |||
protocols and features are being used across a network segment and | protocols and features are being used across a network segment and | |||
to measure trends in the pattern of usage. This could impact the | to measure trends in the pattern of usage. This could impact the | |||
ability for an operator to anticipate the need for network | ability for an operator to anticipate the need for network | |||
upgrades and roll-out. It can also impact the on-going traffic | upgrades and roll-out. It can also impact the on-going traffic | |||
engineering activities performed by operators (such as determining | engineering activities performed by operators (such as determining | |||
which parts of the path contribute delay, jitter or loss). While | which parts of the path contribute delay, jitter or loss). While | |||
the impact could, in many cases, be small there are scenarios | this impact could, in many cases, be small, there are scenarios | |||
where operators directly support particular services (e.g., to | where operators directly support particular services (e.g., to | |||
troubleshoot issues relating to Quality of Service, QoS; the | troubleshoot issues relating to Quality of Service, QoS; the | |||
ability to perform fast re-routing of critical traffic, or support | ability to perform fast re-routing of critical traffic, or support | |||
to mitigate the characteristics of specific radio links). The | to mitigate the characteristics of specific radio links). The | |||
more complex the underlying infrastructure the more important this | more complex the underlying infrastructure the more important this | |||
impact. | impact. | |||
Open and Verifiable Network Data: Hiding transport protocol header | Open and Verifiable Network Data: Hiding transport protocol header | |||
information can reduce the range of actors that can capture useful | information can reduce the range of actors that can capture useful | |||
measurement data. This limits the information sources available | measurement data. This limits the information sources available | |||
skipping to change at page 7, line 35 ¶ | skipping to change at page 7, line 35 ¶ | |||
transport protocols, so preventing access to the information | transport protocols, so preventing access to the information | |||
necessary to inform design decisions and standardisation of the | necessary to inform design decisions and standardisation of the | |||
new protocols and related operational practices. | new protocols and related operational practices. | |||
The cooperating dependence of network, application, and host to | The cooperating dependence of network, application, and host to | |||
provide communication performance on the Internet is uncertain | provide communication performance on the Internet is uncertain | |||
when only endpoints (i.e., at user devices and within service | when only endpoints (i.e., at user devices and within service | |||
platforms) can observe performance, and when performance cannot be | platforms) can observe performance, and when performance cannot be | |||
independently verified by all parties. The ability of other | independently verified by all parties. The ability of other | |||
stakeholders to review transport header traces can help develop | stakeholders to review transport header traces can help develop | |||
deeper insight into performance. In the heterogeneous Internet, | deeper insight into performance and traffic contribution of | |||
specific varients of a protocol. In the heterogeneous Internet, | ||||
this helps extend the range of topologies, vendor equipment, and | this helps extend the range of topologies, vendor equipment, and | |||
traffic patterns that are evaluated. | traffic patterns that are evaluated. | |||
Independently captured data is important to help ensure the health | Independently captured data is important to help ensure the health | |||
of the research and development communities. It can provide input | of the research and development communities. It can provide input | |||
and test scenarios to support development of new transport | and test scenarios to support the development of new transport | |||
protocol mechanisms, especially when this analysis can be based on | protocol mechanisms, especially when this analysis can be based on | |||
the behaviour experienced in a diversity of deployed networks. | the behaviour experienced in a diversity of deployed networks. | |||
Independently verifiable performance metrics might also be | Independently verifiable performance metrics might also be | |||
utilised to demonstrate regulatory compliance in some | utilised to demonstrate regulatory compliance in some | |||
jurisdictions, and to provide a basis for informing design | jurisdictions, and to provide a basis for informing design | |||
decisions. | decisions. | |||
The last point leads us to consider the impact of hiding transport | The last point leads us to consider the impact of hiding transport | |||
headers in the specification and development of protocols and | headers in the specification and development of protocols and | |||
standards. This has potential impact on: | standards. This has a 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, functions, and/or | valuable tool for benchmarking equipment, functions, and/or | |||
configurations, and to understand complex feature interactions. | configurations, and to understand complex feature interactions. | |||
An inability to observe transport protocol information can limit | An inability to observe transport protocol information can limit | |||
the ability to diagnose and explore interactions between features | the ability to diagnose and explore interactions between features | |||
at different protocol layers, a side-effect of not allowing a | at different protocol layers, a side-effect of not allowing a | |||
choice of vantage point from which this information is observed. | choice of vantage point from which this information is observed. | |||
skipping to change at page 9, line 8 ¶ | skipping to change at page 9, line 10 ¶ | |||
operator might use heuristics to guess that short UDP packets with | operator might use heuristics to guess that short UDP packets with | |||
regular spacing are carrying audio traffic. Operational practices | regular spacing are carrying audio traffic. Operational practices | |||
aimed at guessing transport parameters are out of scope for this | aimed at guessing transport parameters are out of scope for this | |||
document, and are only mentioned here to recognize that encryption | document, and are only mentioned here to recognize that encryption | |||
may not prevent operators from attempting to apply the same | may not prevent operators from attempting to apply the same | |||
practices they used with unencrypted transport headers. | practices they used with unencrypted transport headers. | |||
o Compliance: Published transport specifications allow operators and | o Compliance: Published transport specifications allow operators and | |||
regulators to check compliance. This can bring assurance to those | regulators 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 Internet traffic | |||
(e.g., avoiding the capital and operational costs of deploying | flows (e.g., avoiding the capital and operational costs of | |||
flow rate-limiting and network circuit-breaker methods [RFC8084]). | deploying flow rate-limiting and network circuit-breaker methods | |||
When it is not possible to observe transport header information, | [RFC8084]). When it is not possible to observe transport header | |||
methods are still needed to confirm that the traffic produced | information, methods are still needed to confirm that the traffic | |||
conforms to the expectations of the operator or developer. | produced conforms to the expectations of the operator or | |||
developer. | ||||
o Restricting research and development: Hiding transport information | o Restricting research and development: Hiding transport information | |||
can impede independent research into new mechanisms, measurement | can impede independent research into new mechanisms, measurement | |||
of behaviour, and development initiatives. Experience shows that | of 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 mechanisms, 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. If this results in reduced availability of open data, | capacity. If this results in reduced availability of open data, | |||
it could eliminate the independent self-checks to the | it could eliminate the independent self-checks to the | |||
skipping to change at page 10, line 16 ¶ | skipping to change at page 10, line 20 ¶ | |||
information concealed ought to be carefully considered when | information concealed ought to be carefully considered when | |||
specifying new transport protocols. | specifying new transport protocols. | |||
3. Current uses of Transport Headers within the Network | 3. Current uses of Transport Headers within the Network | |||
Despite transport headers having end-to-end meaning, some of these | Despite transport headers having end-to-end meaning, some of these | |||
transport headers have come to be used in various ways within the | transport headers have come to be used in various ways within the | |||
Internet. In response to pervasive monitoring [RFC7624] revelations | Internet. In response to pervasive monitoring [RFC7624] revelations | |||
and the IETF consensus that "Pervasive Monitoring is an Attack" | and the IETF consensus that "Pervasive Monitoring is an Attack" | |||
[RFC7258], efforts are underway to increase encryption of Internet | [RFC7258], efforts are underway to increase encryption of Internet | |||
traffic,. Applying confidentiality to transport header fields would | traffic. Applying confidentiality to transport header fields would | |||
affect how protocol information is used [RFC8404]. To understand | affect how protocol information is used [RFC8404]. To understand | |||
these implications, it is first necessary to understand how transport | these implications, it is first necessary to understand how transport | |||
layer headers are currently observed and/or modified by middleboxes | layer headers are currently observed and/or modified by middleboxes | |||
within the network. | within the network. | |||
Transport protocols can be designed to encrypt or authenticate | Transport protocols can be designed to encrypt or authenticate | |||
transport header fields. Authentication at the transport layer can | transport header fields. Authentication at the transport layer can | |||
be used to detect any changes to an immutable header field that were | be used to detect any changes to an immutable header field that were | |||
made by a network device along a path. The intentional modification | made by a network device along a path. The intentional modification | |||
of transport headers by middleboxes (such as Network Address | of transport headers by middleboxes (such as Network Address | |||
skipping to change at page 10, line 44 ¶ | skipping to change at page 10, line 48 ¶ | |||
o Flows need to be identified at the level required to perform the | o Flows need to be identified at the level required to perform the | |||
observation; | observation; | |||
o The protocol and version of the header need to be visible, e.g., | o The protocol and version of the header need to be visible, e.g., | |||
by defining the wire image [I-D.trammell-wire-image]. As | by defining the wire image [I-D.trammell-wire-image]. As | |||
protocols evolve over time and there could be a need to introduce | protocols evolve over time and there could be a need to introduce | |||
new transport headers. This could require interpretation of | new transport headers. This could require interpretation of | |||
protocol version information or connection setup information; | protocol version information or connection setup information; | |||
o The location and syntax of any observed transport headers needs to | o The location and syntax of any observed transport headers need to | |||
be known. IETF transport protocols can specify this information. | be known. IETF transport protocols can specify this information. | |||
The following subsections describe various ways that observable | The following subsections describe various ways that observable | |||
transport information has been utilised. | transport information has been utilised. | |||
3.1.1. Flow Identification | 3.1.1. Flow Identification | |||
Transport protocol header information (together with information in | Transport protocol header information (together with information in | |||
the network header), has been used to identify a flow and the | the network header), has been used to identify a flow and the | |||
connection state of the flow, together with the protocol options | connection state of the flow, together with the protocol options | |||
skipping to change at page 13, line 32 ¶ | skipping to change at page 13, line 34 ¶ | |||
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements | |||
could identify excessively large buffers, indicating where to | could identify excessively large buffers, indicating where to | |||
deploy or configure AQM. An AQM method is often deployed in | deploy or configure AQM. An AQM method is often deployed in | |||
combination with other techniques, such as scheduling [RFC7567] | combination with other techniques, such as scheduling [RFC7567] | |||
[RFC8290] and although parameter-less methods are desired | [RFC8290] and although parameter-less methods are desired | |||
[RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often | [RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often | |||
cannot scale across all possible deployment scenarios. | cannot scale across all possible deployment scenarios. | |||
Variation in delay: Some network applications are sensitive to small | Variation in delay: Some network applications are sensitive to small | |||
changes in packet timing (jitter). Short and long-term delay | changes in packet timing (jitter). Short and long-term delay | |||
variation can impact on the latency of a flow and the hence the | variation can impact on the latency of a flow and hence the | |||
perceived quality of applications using the network (e.g., jitter | perceived quality of applications using the network (e.g., jitter | |||
metrics are often cited when characterising paths supporting real- | metrics are often cited when characterising paths supporting real- | |||
time traffic). To assess the performance of such applications, it | time traffic). To assess the performance of such applications, it | |||
can be necessary to measure the variation in delay observed along | can be necessary to measure the variation in delay observed along | |||
a portion of the path [RFC3393] [RFC5481]. The requirements | a portion of the path [RFC3393] [RFC5481]. The requirements | |||
resemble those for the measurement of latency. | resemble those for the measurement of latency. | |||
Flow Reordering: Significant packet reordering within a flow can | Flow Reordering: Significant packet reordering within a flow can | |||
impact time-critical applications and can be interpreted as loss | impact time-critical applications and can be interpreted as loss | |||
by reliable transports. Many transport protocol techniques are | by reliable transports. Many transport protocol techniques are | |||
impacted by reordering (e.g., triggering TCP retransmission, or | impacted by reordering (e.g., triggering TCP retransmission or re- | |||
re-buffering of real-time applications). Packet reordering can | buffering of real-time applications). Packet reordering can occur | |||
occur for many reasons, from equipment design to misconfiguration | for many reasons, from equipment design to misconfiguration of | |||
of forwarding rules. Since this impacts transport performance, | forwarding rules. Since this impacts transport performance, | |||
network tools are needed to detect and measure unwanted/excessive | network tools are needed to detect and measure unwanted/excessive | |||
reordering. | reordering. | |||
There have been initiatives in the IETF transport area to reduce | There have been initiatives in the IETF transport area to reduce | |||
the impact of reordering within a transport flow, possibly leading | the impact of reordering within a transport flow, possibly leading | |||
to a reduction in the requirements for preserving ordering. These | to a reduction in the requirements for preserving ordering. These | |||
have promise to simplify network equipment design as well as the | have potential to simplify network equipment design as well as the | |||
potential to improve robustness of the transport service. | potential to improve robustness of the transport service. | |||
Measurements of reordering can help understand the present level | Measurements of reordering can help understand the present level | |||
of reordering within deployed infrastructure, and inform decisions | of reordering within deployed infrastructure, and inform decisions | |||
about how to progress such mechanisms. Key performance indicators | about how to progress such mechanisms. Key performance indicators | |||
are retransmission rate, packet drop rate, sector utilisation | are retransmission rate, packet drop rate, sector utilisation | |||
level, a measure of reordering, peak rate, the ECN congestion | level, a measure of reordering, peak rate, the ECN congestion | |||
experienced (CE) marking rate, etc. | experienced (CE) marking rate, etc. | |||
Metrics have been defined that evaluate whether a network has | Metrics have been defined that evaluate whether a network has | |||
maintained packet order on a packet-by-packet basis [RFC4737] and | maintained packet order on a packet-by-packet basis [RFC4737] and | |||
skipping to change at page 15, line 34 ¶ | skipping to change at page 15, line 36 ¶ | |||
multiple Flow labels to allow the network to independently forward | multiple Flow labels to allow the network to independently forward | |||
subflows. RFC6437 provides further guidance on choosing a flow | subflows. RFC6437 provides further guidance on choosing a flow | |||
label value, stating these "should be chosen such that their bits | label value, stating these "should be chosen such that their bits | |||
exhibit a high degree of variability", and chosen so that "third | exhibit a high degree of variability", and chosen so that "third | |||
parties should be unlikely to be able to guess the next value that | parties should be unlikely to be able to guess the next value that | |||
a source of flow labels will choose". To promote privacy, the | a source of flow labels will choose". To promote privacy, the | |||
Flow Label assignment needs to avoid introducing linkability that | Flow Label assignment needs to avoid introducing linkability that | |||
a network device may observe. Once set, a label can provide | a network device may observe. Once set, a label can provide | |||
information that can help inform network-layer queuing and | information that can help inform network-layer queuing and | |||
forwarding [RFC6438](e.g. for Equal Cost Multi-Path, ECMP, | forwarding [RFC6438](e.g. for Equal Cost Multi-Path, ECMP, | |||
routing, and Link Aggregation, LAG) [RFC6294]. [RFC6438] includes | routing, and Link Aggregation, LAG) [RFC6294]. [RFC6438] | |||
describes considerations when used with IPsec. | describes considerations when used with IPsec. | |||
Using the Network-Layer Differentiated Services Code Point: | Using the Network-Layer Differentiated Services Code Point: | |||
Applications can expose their delivery expectations to the network | Applications can expose their delivery expectations to the network | |||
by setting the Differentiated Services Code Point (DSCP) field of | by setting the Differentiated Services Code Point (DSCP) field of | |||
IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications | IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications | |||
identify different forwarding treatments for individual sub-flows | identify different forwarding treatments for individual sub-flows | |||
(audio vs. video) based on the value of the DSCP field | (audio vs. video) based on the value of the DSCP field | |||
[I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information | [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information | |||
to inform network-layer queuing and forwarding, rather than an | to inform network-layer queuing and forwarding, rather than an | |||
skipping to change at page 16, line 8 ¶ | skipping to change at page 16, line 10 ¶ | |||
application headers via a multi-field classifier. | application headers via a multi-field classifier. | |||
Since the DSCP value can impact the quality of experience for a | Since the DSCP value can impact the quality of experience for a | |||
flow, observations of service performance need to consider this | 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. | |||
Using Explicit Congestion Marking: ECN [RFC3168] is a transport | Using Explicit Congestion Marking: ECN [RFC3168] is a transport | |||
mechanism that utilises the ECN field in the network-layer header. | mechanism that utilises the ECN field in the network-layer header. | |||
Use of ECN explicitly informs the network-layer that a transport | Use of ECN explicitly informs the network-layer that a transport | |||
is ECN-capable, and requests ECN treatment of the flows packets. | is ECN-capable, and requests ECN treatment of the flow. An ECN- | |||
An ECN-capable transport can offer benefits when used over a path | capable transport can offer benefits when used over a path with | |||
with equipment that implements an AQM method with Congestion | equipment that implements an AQM method with Congestion | |||
Experienced (CE) marking of IP packets [RFC8087], since it can | Experienced (CE) marking of IP packets [RFC8087], since it can | |||
react to congestion without also having to recover from lost | react to congestion without also having to recover from lost | |||
packets. | packets. | |||
ECN exposes the presence of congestion. The reception of CE- | ECN exposes the presence of congestion. The reception of CE- | |||
marked packets can be used to estimate the level of incipient | marked packets can be used to estimate the level of incipient | |||
congestion on the upstream portion of the path from the point of | congestion on the upstream portion of the path from the point of | |||
observation (Section 2.5 of [RFC8087]). Interpreting the marking | observation (Section 2.5 of [RFC8087]). Interpreting the marking | |||
behaviour (i.e., assessing congestion and diagnosing faults) | behaviour (i.e., assessing congestion and diagnosing faults) | |||
requires context from the transport layer (such as path RTT). | requires context from the transport layer (such as path RTT). | |||
AQM and ECN offer a range of algorithms and configuration options. | AQM and ECN offer a range of algorithms and configuration options. | |||
Tools therefore need to be available to network operators and | Tools therefore need to be available to network operators and | |||
researchers to understand the implication of configuration choices | researchers to understand the implication of configuration choices | |||
and transport behaviour as use of ECN increases and new methods | and transport behaviour as the use of ECN increases and new | |||
emerge [RFC7567]. | methods emerge [RFC7567]. | |||
Careful use of the network layer features can therefore help address | Careful use of the network layer features can therefore help address | |||
some of the reasons why the network inspects transport protocol | some of the reasons why the network inspects transport protocol | |||
headers. | headers. | |||
3.2. Transport Measurement | 3.2. Transport Measurement | |||
The common language between network operators and application/content | The common language between network operators and application/content | |||
providers/users is packet transfer performance at a layer that all | providers/users is packet transfer performance at a layer that all | |||
can view and analyse. For most packets, this has been the transport | can view and analyse. For most packets, this has been the transport | |||
skipping to change at page 16, line 52 ¶ | skipping to change at page 17, line 7 ¶ | |||
inferences and other heuristics reliance on pattern inferences and | inferences and other heuristics reliance on pattern inferences and | |||
accuracy suffers. For example, the traffic patterns between server | accuracy suffers. For example, the traffic patterns between server | |||
and browser are dependent on browser supplier and version, even when | and browser are dependent on browser supplier and version, even when | |||
the sessions use the same server application (e.g., web e-mail | the sessions use the same server application (e.g., web e-mail | |||
access). It remains to be seen whether more complex inferences can | access). It remains to be seen whether more complex inferences can | |||
be mastered to produce the same monitoring accuracy (see section | be mastered to produce the same monitoring accuracy (see section | |||
2.1.1 of [RFC8404]). | 2.1.1 of [RFC8404]). | |||
When measurement datasets are made available by servers or client | When measurement datasets are made available by servers or client | |||
endpoints, additional metadata, such as the state of the network, is | endpoints, additional metadata, such as the state of the network, is | |||
often required to interpret this data. Collecting and coordinating | often required to interpret this data to answer questions about | |||
such metadata is more difficult when the observation point is at a | network performance or understand a pathology. Collecting and | |||
different location to the bottleneck/device under evaluation. | coordinating such metadata is more difficult when the observation | |||
point is at a different location to the bottleneck/device under | ||||
evaluation. | ||||
Packet sampling techniques can be used to scale the processing | Packet sampling techniques are used to scale the processing involved | |||
involved in observing packets on high rate links. This exports only | in observing packets on high rate links. This exports only the | |||
the packet header information of (randomly) selected packets. 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. | |||
3.2.1. Point of Observation | 3.2.1. Point of Observation | |||
skipping to change at page 17, line 45 ¶ | skipping to change at page 17, line 51 ¶ | |||
Sometimes multiple on-path observation points are needed. By | Sometimes multiple on-path observation points are needed. By | |||
correlating observations of headers at multiple points along the path | correlating observations of headers at multiple points along the path | |||
(e.g., at the ingress and egress of a network segment), an observer | (e.g., at the ingress and egress of a network segment), an observer | |||
can determine the contribution of a portion of the path to an | can determine the contribution of a portion of the path to an | |||
observed metric, to locate a source of delay, jitter, loss, | observed metric, to locate a source of delay, jitter, loss, | |||
reordering, congestion marking, etc. | reordering, congestion marking, etc. | |||
3.2.2. Use by Operators to Plan and Provision Networks | 3.2.2. Use by Operators to Plan and Provision Networks | |||
Traffic measurements (e.g., traffic volume, loss, latency) is used by | Traffic measurements (e.g., traffic volume, loss, latency) is used by | |||
operators to help plan deployment of new equipment and configurations | operators to help plan deployment of new equipment and configuration | |||
in their networks. Data is also valuable to equipment vendors who | in their networks. Data is also valuable to equipment vendors who | |||
want to understand traffic trends and patterns of usage as inputs to | want to understand traffic trends and patterns of usage as inputs to | |||
decisions about planning products and provisioning for new | decisions about planning products and provisioning for new | |||
deployments. This measurement information can also be correlated | deployments. This measurement information can also be correlated | |||
with billing information when this is also collected by an operator. | with billing information when this is also collected by an operator. | |||
A network operator supporting traffic that uses transport header | A network operator supporting traffic that uses transport header | |||
encryption might not have access to per-flow measurement data. | encryption might not have access to per-flow measurement data. | |||
Trends in aggregate traffic can be observed and can be related to the | Trends in aggregate traffic can be observed and can be related to the | |||
endpoint addresses being used, but it may be impossible to correlate | endpoint addresses being used, but it may be impossible to correlate | |||
skipping to change at page 18, line 42 ¶ | skipping to change at page 18, line 46 ¶ | |||
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 | Congestion Control Compliance of Traffic: Congestion control is a | |||
key transport function [RFC2914]. Many network operators | key transport function [RFC2914]. Many network operators | |||
implicitly accept that TCP traffic complies with a behaviour that | implicitly accept that TCP traffic complies with a behaviour that | |||
is acceptable for use in the shared Internet. TCP algorithms have | is acceptable for use in the shared Internet. TCP algorithms have | |||
been continuously improved over decades, and they have reached a | been continuously improved over decades and they have reached a | |||
level of efficiency and correctness that custom application-layer | level of efficiency and correctness that custom application-layer | |||
mechanisms will struggle to easily duplicate [RFC8085]. | mechanisms will struggle to easily duplicate [RFC8085]. | |||
A standards-compliant TCP stack provides congestion control that | A standards-compliant TCP stack provides congestion control that | |||
may therefore be judged safe for use across the Internet. | may 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 IETF-specified transport (e.g., TCP and SCTP). | behaviour for IETF-specified transport (e.g., TCP and SCTP). | |||
However, when anomalies 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 | |||
skipping to change at page 19, line 9 ¶ | skipping to change at page 19, line 15 ¶ | |||
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 IETF-specified transport (e.g., TCP and SCTP). | behaviour for IETF-specified transport (e.g., TCP and SCTP). | |||
However, when anomalies 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 an understanding of the dynamics of a flow and | |||
congestion control behaviour. Analysing observed flows can help | its congestion control behaviour. Analysing observed flows can | |||
to build confidence that an application flow backs-off its share | help to build confidence that an application flow backs-off its | |||
of the network load in the face of persistent congestion, and | share of the network load in the face of persistent congestion, | |||
hence to understand whether the behaviour is appropriate for | and hence to understand whether the behaviour is appropriate for | |||
sharing limited network capacity. For example, it is common to | sharing limited network capacity. For example, it is common to | |||
visualise plots of TCP sequence numbers versus time for a flow to | visualise plots of TCP sequence numbers versus time for a flow to | |||
understand how a flow shares available capacity, deduce its | understand how a flow shares available capacity, deduce its | |||
dynamics in response to congestion, etc. The ability to identify | dynamics in response to congestion, etc. The ability to identify | |||
sources that contribute excessive congestion is important to safe | sources that contribute to persistent congestion is important to | |||
operation of network infrastructure, and mechanisms can inform | safe operation of network infrastructure, and mechanisms can | |||
configuration of network devices to complement the endpoint | inform configuration of network devices to complement the endpoint | |||
congestion avoidance mechanisms [RFC7567] [RFC8084] to avoid a | congestion avoidance mechanisms [RFC7567] [RFC8084] to avoid a | |||
portion of the network being driven into congestion collapse | portion of the network being driven into congestion collapse | |||
[RFC2914]. | [RFC2914]. | |||
Congestion Control Compliance for UDP traffic: UDP provides a | Congestion Control Compliance for UDP traffic: UDP provides a | |||
minimal message-passing datagram transport that has no inherent | minimal message-passing datagram transport that has no inherent | |||
congestion control mechanisms. Because congestion control is | congestion control mechanisms. Because congestion control is | |||
critical to the stable operation of the Internet, applications and | critical to the stable operation of the Internet, applications and | |||
other protocols that choose to use UDP as a transport are required | other protocols that choose to use UDP as a transport are required | |||
to employ mechanisms to prevent congestion collapse, avoid | to employ mechanisms to prevent congestion collapse, avoid | |||
skipping to change at page 20, line 20 ¶ | skipping to change at page 20, line 22 ¶ | |||
performance, capacity planning, management of security threats | performance, capacity planning, management of security threats | |||
(including denial of service), and responding to user performance | (including denial of service), and responding to user performance | |||
questions. Sections 3.1.2 and 5 of [RFC8404] provide further | questions. Sections 3.1.2 and 5 of [RFC8404] provide further | |||
examples. These tasks seldom involve the need to determine the | examples. These tasks seldom involve the need to determine the | |||
contents of the transport payload, or other application details. | contents of the 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 | |||
deployment of performance measurement tools that rely on transport | deployment of performance measurement tools that rely on transport | |||
protocol information. Choosing to encrypt all the information | protocol information. Choosing to encrypt all the information | |||
reduces the ability of an operator to observe transport performance, | reduces the ability of an operator to observe transport performance | |||
and could limit the ability of network operators to trace problems, | and could limit the ability of network operators to trace problems, | |||
make appropriate QoS decisions, or response to other queries about | make appropriate QoS decisions, or response to other queries about | |||
the network service. For some this will be blessing, for others it | the network service. For some this will be blessing, for others it | |||
may be a curse. For example, operational performance data about | may be a curse. For example, operational performance data about | |||
encrypted flows needs to be determined by traffic pattern analysis, | encrypted flows needs to be determined by traffic pattern analysis, | |||
rather than relying on traditional tools. This can impact the | rather than relying on traditional tools. This can impact the | |||
ability of the operator to respond to faults, it could require | ability of the operator to respond to faults, it could require | |||
reliance on endpoint diagnostic tools or user involvement in | reliance on endpoint diagnostic tools or user involvement in | |||
diagnosing and troubleshooting unusual use cases or non-trivial | diagnosing and troubleshooting unusual use cases or non-trivial | |||
problems. A key need here is for tools to provide useful information | problems. A key need here is for tools to provide useful information | |||
during network anomalies (e.g., significant reordering, high or | during network anomalies (e.g., significant reordering, high or | |||
intermittent loss). | intermittent loss). | |||
Measurements can be used to monitor the health of a portion of the | Measurements can be used to monitor the health of a portion of the | |||
Internet, to provide early warning of the need to take action. They | Internet, to provide early warning of the need to take action. They | |||
can assist in debugging and diagnosing the root causes of faults that | can assist in debugging and diagnosing the root causes of faults that | |||
concern a particular user's traffic. They can also be used to | concern a particular user's traffic. They can also be used to | |||
support post-mortem investigation after an anomaly to determine the | support post-mortem investigation after an anomaly to determine the | |||
root cause of a problem. | root cause of a problem. | |||
In some case, measurements may involve active injection of test | In some case, measurements could involve active injection of test | |||
traffic to perform a measurement. However, most operators do not | traffic to perform a measurement. However, most operators do not | |||
have access to user equipment, therefore the point of test is | have access to user equipment, therefore the point of test is | |||
normally different from the transport endpoint. Injection of test | normally different from the transport endpoint. Injection of test | |||
traffic can incur an additional costs in running such tests (e.g., | traffic can incur an additional cost in running such tests (e.g., the | |||
the implications of capacity tests in a mobile network are obvious). | implications of capacity tests in a mobile network are obvious). | |||
Some active measurements (e.g., response under load or particular | Some active measurements (e.g., response under load or particular | |||
workloads) perturb other traffic, and could require dedicated access | workloads) perturb other traffic, and could require dedicated access | |||
to the network segment. An alternative approach is to use in-network | to the network segment. An alternative approach is to use in-network | |||
techniques that observe transport packet headers added while traffic | techniques that observe transport packet headers added while traffic | |||
traverses an operational networks to make the measurements. These | traverses an operational network to make the measurements. These | |||
measurements do not require the cooperation of an endpoint. | measurements do not require the cooperation of an endpoint. | |||
In other cases, measurement involves dissecting network traffic | In other cases, measurement involves dissecting network traffic | |||
flows. The observed transport layer information can help identify | flows. The observed transport layer information can help identify | |||
whether the link/network tuning is effective and alert to potential | whether the link/network tuning is effective and alert to potential | |||
problems that can be hard to derive from link or device measurements | problems that can be hard to derive from link or device measurements | |||
alone. The design trade-offs for radio networks are often very | alone. The design trade-offs for radio networks are often very | |||
different to those of wired networks. A radio-based network (e.g., | different from those of wired networks. A radio-based network (e.g., | |||
cellular mobile, enterprise WiFi, satellite access/back-haul, point- | cellular mobile, enterprise WiFi, satellite access/back-haul, point- | |||
to-point radio) has the complexity of a subsystem that performs radio | to-point radio) has the complexity of a subsystem that performs radio | |||
resource management,s with direct impact on the available capacity, | resource management,s with direct impact on the available capacity, | |||
and potentially loss/reordering of packets. The impact of the | and potentially loss/reordering of packets. The impact of the | |||
pattern of loss and congestion, differs for different traffic types, | pattern of loss and congestion, differs for different traffic types, | |||
correlation with propagation and interference can all have | correlation with propagation and interference can all have | |||
significant impact on the cost and performance of a provided service. | significant impact on the cost and performance of a provided service. | |||
The need for this type of information is expected to increase as | The need for this type of information is expected to increase as | |||
operators bring together heterogeneous types of network equipment and | operators bring together heterogeneous types of network equipment and | |||
seek to deploy opportunistic methods to access radio spectrum. | seek to deploy opportunistic methods to access radio spectrum. | |||
skipping to change at page 23, line 37 ¶ | skipping to change at page 23, line 39 ¶ | |||
The following briefly reviews some security design options for | The following briefly reviews some security design options for | |||
transport protocols. A Survey of Transport Security Protocols | transport protocols. A Survey of Transport Security Protocols | |||
[I-D.ietf-taps-transport-security] provides more details concerning | [I-D.ietf-taps-transport-security] provides more details concerning | |||
commonly used encryption methods at the transport layer. | commonly used encryption methods at the transport layer. | |||
Authenticating the Transport Protocol Header: Transport layer header | Authenticating the Transport Protocol Header: Transport layer header | |||
information can be authenticated. An integrity check that | information can be authenticated. An integrity check that | |||
protects the immutable transport header fields, but can still | protects the immutable transport header fields, but can still | |||
expose the transport protocol header information in the clear, | expose the transport protocol header information in the clear, | |||
allowing in-network devices to observe these fields. An integrity | allowing in-network devices to observe these fields. An integrity | |||
check can not prevent in-network modification, but can prevent a | check is not able to prevent in-network modification, but can | |||
receiving from accepting changes and avoid impact on the transport | prevent a receiving from accepting changes and avoid impact on the | |||
protocol operation. | transport protocol operation. | |||
An example transport authentication mechanism is TCP- | An example transport authentication mechanism is TCP- | |||
Authentication (TCP-AO) [RFC5925]. This TCP option authenticates | Authentication (TCP-AO) [RFC5925]. This TCP option authenticates | |||
the IP pseudo header, TCP header, and TCP data. TCP-AO protects | the IP pseudo header, TCP header, and TCP data. TCP-AO protects | |||
the transport layer, preventing attacks from disabling the TCP | the transport layer, preventing attacks from disabling the TCP | |||
connection itself and provides replay protection. TCP-AO may | connection itself and provides replay protection. TCP-AO may | |||
interact with middleboxes, depending on their behaviour [RFC3234]. | interact with middleboxes, depending on their behaviour [RFC3234]. | |||
The IPsec Authentication Header (AH) [RFC4302] was designed to | The IPsec Authentication Header (AH) [RFC4302] was designed to | |||
work at the network layer and authenticate the IP payload. This | work at the network layer and authenticate the IP payload. This | |||
skipping to change at page 24, line 24 ¶ | skipping to change at page 24, line 25 ¶ | |||
use a field for another purpose. When the specification is later | use a field for another purpose. When the specification is later | |||
updated, it is impossible to deploy the new use of the field, and | updated, it is impossible to deploy the new use of the field, and | |||
forwarding of the protocol could even become conditional on a | forwarding of the protocol could even become conditional on a | |||
specific header field value. | specific header field value. | |||
A protocol can intentionally vary the value, format, and/or | A protocol can intentionally vary the value, format, and/or | |||
presence of observable transport header fields. This behaviour, | presence of observable transport header fields. This behaviour, | |||
known as GREASE (Generate Random Extensions And Sustain | known as GREASE (Generate Random Extensions And Sustain | |||
Extensibility), is designed to avoid a network device ossifying | Extensibility), is designed to avoid a network device ossifying | |||
the use of a specific observable field. Greasing seeks to ease | the use of a specific observable field. Greasing seeks to ease | |||
deployment of new methods. It can be designed to prevent in- | deployment of new methods. It can also prevent in-network devices | |||
network devices utilising the information in a transport header, | utilising the information in a transport header, or can make an | |||
or can make an observation robust to a set of changing values, | observation robust to a set of changing values, rather than a | |||
rather than a specific set of values. | specific set of values. | |||
Encrypting the Transport Payload: The transport layer payload can be | Encrypting the Transport Payload: The transport layer payload can be | |||
encrypted to protect the content of transport segments. This | encrypted to protect the content of transport segments. This | |||
leaves transport protocol header information in the clear. The | leaves transport protocol header information in the clear. The | |||
integrity of immutable transport header fields could be protected | integrity of immutable transport header fields could be protected | |||
by combining this with an integrity check. | by combining this with an integrity check. | |||
Examples of encrypting the payload include Transport Layer | Examples of encrypting the payload include Transport Layer | |||
Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS) | Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS) | |||
over UDP [RFC6347] [RFC7525], Secure RTP [RFC3711], and TCPcrypt | over UDP [RFC6347] [RFC7525], Secure RTP [RFC3711], and TCPcrypt | |||
skipping to change at page 26, line 21 ¶ | skipping to change at page 26, line 23 ¶ | |||
sender and visible at the receiving endpoint, although methods to do | sender and visible at the receiving endpoint, although methods to do | |||
this have not currently been proposed. This method needs to be | this have not currently been proposed. This method needs to be | |||
explicitly enabled at the sender. | explicitly enabled at the sender. | |||
Current measurements suggest it can be undesirable to rely on methods | Current measurements suggest it can be undesirable to rely on methods | |||
requiring the presence of network options or extension headers. IPv4 | requiring the presence of network options or extension headers. IPv4 | |||
network options are often not supported (or are carried on a slower | network options are often not supported (or are carried on a slower | |||
processing path) and some IPv6 networks are also known to drop | processing path) and some IPv6 networks are also known to drop | |||
packets that set an IPv6 header extension (e.g., [RFC7872]). Another | packets that set an IPv6 header extension (e.g., [RFC7872]). Another | |||
disadvantage is that protocols that separately expose header | disadvantage is that protocols that separately expose header | |||
information do not necessarily have an advantage to expose the | information do not necessarily have an incentive to expose the | |||
information that is utilised by the protocol itself, and could | information that is utilised by the protocol itself, and could | |||
manipulate this header information to gain an advantage from the | manipulate the exposed header information to gain an advantage from | |||
network. | the network. | |||
6. Implications of Protecting the Transport Headers | 6. Implications of Protecting the Transport Headers | |||
The choice of which fields to expose and which to encrypt is a design | The choice of which fields to expose and which to encrypt is a design | |||
choice for the transport protocol. Any selective encryption method | choice for the transport protocol. Any selective encryption method | |||
requires trading two conflicting goals for a transport protocol | requires trading two conflicting goals for a transport protocol | |||
designer to decide which header fields to encrypt. Security work | designer to decide which header fields to encrypt. Security work | |||
typically employs a design technique that seeks to expose only what | typically employs a design technique that seeks to expose only what | |||
is needed. This approach provides incentives to not reveal any | is needed. This approach provides incentives to not reveal any | |||
information that is not necessary for the end-to-end communication. | information that is not necessary for the end-to-end communication. | |||
skipping to change at page 30, line 52 ¶ | skipping to change at page 30, line 52 ¶ | |||
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. | |||
7. Conclusions | 7. Conclusions | |||
Confidentiality and strong integrity checks have properties that are | Confidentiality and strong integrity checks have properties that are | |||
being incorporated into new protocols and that have important | being incorporated into new protocols and that have important | |||
benefits. The pace of development of transports using the WebRTC | benefits. The pace of development of transports using the WebRTC | |||
data channel and the rapid deployment of QUIC transport protocol can | data channel and the rapid deployment of the QUIC transport protocol | |||
both be attributed to using the combination of UDP as a substrate | can both be attributed to using the combination of UDP as a substrate | |||
while providing confidentiality and authentication of the | while providing confidentiality and authentication of the | |||
encapsulated transport headers and payload. | encapsulated transport headers and payload. | |||
The traffic that can be observed by on-path network devices is a | The traffic that can be observed by on-path network devices is a | |||
function of transport protocol design/options, network use, | function of transport protocol design/options, network use, | |||
applications, and user characteristics. In general, when only a | applications, and user characteristics. In general, when only a | |||
small proportion of the traffic has a specific (different) | small proportion of the traffic has a specific (different) | |||
characteristic, such traffic seldom leads to operational concern, | characteristic, such traffic seldom leads to operational concern, | |||
although the ability to measure and monitor it is less. The desire | although the ability to measure and monitor it is less. The desire | |||
to understand the traffic and protocol interactions typically grows | to understand the traffic and protocol interactions typically grows | |||
skipping to change at page 31, line 28 ¶ | skipping to change at page 31, line 28 ¶ | |||
An increased pace of evolution therefore needs to be accompanied by | An increased pace of evolution therefore needs to be accompanied by | |||
methods that can be successfully deployed and used across operational | methods that can be successfully deployed and used across operational | |||
networks. This leads to a need for network operators (at various | networks. This leads to a need for network operators (at various | |||
level (ISPs, enterprises, firewall maintainer, etc) to identify | level (ISPs, enterprises, firewall maintainer, etc) to identify | |||
appropriate operational support functions and procedures. | appropriate operational support functions and procedures. | |||
Protocols that change their transport header format (wire format) or | Protocols that change their transport header format (wire format) or | |||
their behaviour (e.g., algorithms that are needed to classify and | their behaviour (e.g., algorithms that are needed to classify and | |||
characterise the protocol), will require new tooling to be developed | characterise the protocol), will require new tooling to be developed | |||
to catch-up with the changes. If the currently deployed tools and | to catch-up with the change. If the currently deployed tools and | |||
methods are no longer relevant then it may no longer be possible to | methods are no longer relevant then it may no longer be possible to | |||
correctly measure performance. This can increase the response-time | correctly measure performance. This can increase the response-time | |||
after faults, and can impact the ability to manage the network | after faults, and can impact the ability to manage the network | |||
resulting in traffic causing traffic to be treated inappropriately | resulting in traffic causing traffic to be treated inappropriately | |||
(e.g., rate limiting because of being incorrectly classified/ | (e.g., rate limiting because of being incorrectly classified/ | |||
monitored). | monitored). | |||
There are benefits in exposing consistent information to the network | There are benefits in exposing consistent information to the network | |||
that avoids traffic being mis-classified and then receiving a default | that avoids traffic being inappropriately classified and then | |||
treatment by the network. The flow label and DSCP fields provide | receiving a default treatment by the network. The flow label and | |||
examples of how transport information can be made available for | DSCP fields provide examples of how transport information can be made | |||
network-layer decisions. Extension headers could also be used to | available for network-layer decisions. Extension headers could also | |||
carry transport information that can inform network-layer decisions. | be used to carry transport information that can inform network-layer | |||
decisions. | ||||
As a part of its design a new protocol specification therefore needs | As a part of its design, a new protocol specification therefore needs | |||
to weigh the benefits of ossifying common headers, versus the | to weigh the benefits of ossifying common headers, versus the | |||
potential demerits of exposing specific information that could be | potential demerits of exposing specific information that could be | |||
observed along the network path, to provide tools to manage new | observed along the network path, to provide tools to manage new | |||
variants of protocols. This can be done for the entire transport | variants of protocols. This can be done for the entire transport | |||
header, or by dividing header fields between those that are | header, or by dividing header fields between those that are | |||
observable and mutable; those that are observable, but immutable; and | observable and mutable; those that are observable, but immutable; and | |||
those that are hidden/obfusticated. | those that are hidden/obfusticated. | |||
Several scenarios to illustrate different ways this could evolve are | Several scenarios to illustrate different ways this could evolve are | |||
provided below: | provided below: | |||
skipping to change at page 32, line 33 ¶ | skipping to change at page 32, line 33 ¶ | |||
measurement and any necessary functions appropriate to the class | measurement and any necessary functions appropriate to the class | |||
of traffic (priority, retransmission, reordering, circuit | of traffic (priority, retransmission, reordering, circuit | |||
breakers, etc). | breakers, etc). | |||
o An alternative scenario adopts different design goals, with a | o An alternative scenario adopts different design goals, with a | |||
different outcome. A protocol that encrypts all header | different outcome. A protocol that encrypts all header | |||
information forces network operators to act independently from | information forces network operators to act independently from | |||
apps/transport developments to extract the information they need | apps/transport developments to extract the information they need | |||
to manage their network. A range of approaches could proliferate, | to manage their network. A range of approaches could proliferate, | |||
as in current networks. Some operators can add a shim header to | as in current networks. Some operators can add a shim header to | |||
each packet as a flow as it crosses the network; other operators/ | each packet in a flow as the flow crosses a network segment; other | |||
managers could develop heuristics and pattern recognition to | operators/managers could develop heuristics and pattern | |||
derive information that classifies flows and estimates quality | recognition to derive information that classifies flows and | |||
metrics for the service being used; some could decide to rate- | estimates quality metrics for the service being used; some could | |||
limit or block traffic until new tooling is in place. In many | decide to rate-limit or block traffic until new tooling is in | |||
cases, the derived information can be used by operators to provide | place. In many cases, the derived information can be used by | |||
necessary functions appropriate to the class of traffic (priority, | operators to provide necessary functions appropriate to the class | |||
retransmission, reordering, circuit breakers, etc). | of traffic (priority, retransmission, reordering, circuit | |||
Troubleshooting, and measurement becomes more difficult, and more | breakers, etc). Troubleshooting, and measurement becomes more | |||
diverse. This could require additional information beyond that | difficult, and more diverse. This could require additional | |||
visible in the packet header and when this information is used to | information beyond that visible in the packet header and when this | |||
inform decisions by on-path devices it can lead to dependency on | information is used to inform decisions by on-path devices it can | |||
other characteristics of the flow. In some cases, operators might | lead to dependency on other characteristics of the flow. In some | |||
need access to keying information to interpret encrypted data that | cases, operators might need access to keying information to | |||
they observe. Some use cases could demand use of transports that | interpret encrypted data that they observe. Some use cases could | |||
do not use encryption. | demand use of transports that do not use encryption. | |||
The direction in which this evolves could have significant | The direction in which this evolves could have significant | |||
implications on the way the Internet architecture develops. It | implications on the way the Internet architecture develops. It | |||
exposes a risk that significant actors (e.g., developers and | exposes a risk that significant actors (e.g., developers and | |||
transport designers) achieve more control of the way in which the | transport designers) achieve more control of the way in which the | |||
Internet architecture develops.In particular, there is a possibility | Internet architecture develops.In particular, there is a possibility | |||
that designs could evolve to significantly benefit of customers for a | that designs could evolve to significantly benefit of customers for a | |||
specific vendor, and that communities with very different network, | specific vendor, and that communities with very different network, | |||
applications or platforms could then suffer at the expense of | applications or platforms could then suffer at the expense of | |||
benefits to their vendors own customer base. In such a scenario, | benefits to their vendors own customer base. In such a scenario, | |||
skipping to change at page 34, line 32 ¶ | skipping to change at page 34, line 32 ¶ | |||
decryption of packets that cannot be successfully decrypted (forcing | decryption of packets that cannot be successfully decrypted (forcing | |||
a receiver to commit decryption resources, or to update and then | a receiver to commit decryption resources, or to update and then | |||
restore protocol state). | restore protocol state). | |||
One mitigation to off-path attack is to deny knowledge of what header | One mitigation to off-path attack is to deny knowledge of what header | |||
information is accepted by a receiver or obfuscate the accepted | information is accepted by a receiver or obfuscate the accepted | |||
header information, e.g., setting a non-predictable initial value for | header information, e.g., setting a non-predictable initial value for | |||
a sequence number during a protocol handshake, as in [RFC3550] and | a sequence number during a protocol handshake, as in [RFC3550] and | |||
[RFC6056], or a port value that can not be predicted (see section 5.1 | [RFC6056], or a port value that can not be predicted (see section 5.1 | |||
of [RFC8085]). A receiver could also require additional information | of [RFC8085]). A receiver could also require additional information | |||
to be used as a part of check before accepting packets at the | to be used as a part of a validation check before accepting packets | |||
transport layer (e.g., utilising a part of the sequence number space | at the transport layer (e.g., utilising a part of the sequence number | |||
that is encrypted; or by verifying an encrypted token not visible to | space that is encrypted; or by verifying an encrypted token not | |||
an attacker). This would also mitigate on-path attacks. An | visible to an attacker). This would also mitigate on-path attacks. | |||
additional processing cost can be incurred when decryption needs to | An additional processing cost can be incurred when decryption needs | |||
be attempted before a receiver is able to discard injected packets. | to be attempted before a receiver is able to discard injected | |||
packets. | ||||
Open standards motivate a desire for this evaluation to include | Open standards motivate a desire for this evaluation to include | |||
independent observation and evaluation of performance data, which in | independent observation and evaluation of performance data, which in | |||
turn suggests control over where and when measurement samples are | turn suggests control over where and when measurement samples are | |||
collected. This requires consideration of the appropriate balance | collected. This requires consideration of the appropriate balance | |||
between encrypting all and no transport information. Open data, and | between encrypting all and no transport information. Open data, and | |||
accessibility to tools that can help understand trends in application | accessibility to tools that can help understand trends in application | |||
deployment, network traffic and usage patterns can all contribute to | deployment, network traffic and usage patterns can all contribute to | |||
understanding security challenges. | understanding security challenges. | |||
skipping to change at page 43, line 10 ¶ | skipping to change at page 43, line 10 ¶ | |||
referring to RTP transport. This version contains author editorial | referring to RTP transport. This version contains author editorial | |||
work and removed duplicate section. | work and removed duplicate section. | |||
-04 Revised following SecDir Review | -04 Revised following SecDir Review | |||
o Added some text on TLS story (additional input sought on relevant | o Added some text on TLS story (additional input sought on relevant | |||
considerations). | considerations). | |||
o Section 2, paragraph 8 - changed to be clearer, in particular, | o Section 2, paragraph 8 - changed to be clearer, in particular, | |||
added "Encryption with secure key distribution prevents" | added "Encryption with secure key distribution prevents" | |||
o Flow label description rewritten based on PDS/BCP RFCs. | o Flow label description rewritten based on PS/BCP RFCs. | |||
o Clarify requirements from RFCs concerning the IPv6 flow label and | o Clarify requirements from RFCs concerning the IPv6 flow label and | |||
highlight ways it can be used with encryption. (section 3.1.3) | highlight ways it can be used with encryption. (section 3.1.3) | |||
o Add text on the explicit spin-bit work in the QUIC DT. Added | o Add text on the explicit spin-bit work in the QUIC DT. Added | |||
greasing of spin-bit. (Section 6.1) | greasing of spin-bit. (Section 6.1) | |||
o Updated section 6 and added more explanation of impact on | o Updated section 6 and added more explanation of impact on | |||
operators. | operators. | |||
o Other comments addressed. | o Other comments addressed. | |||
-05 Editorial pass and minor corrections noted on TSVWG list. | ||||
Authors' Addresses | Authors' Addresses | |||
Godred Fairhurst | Godred Fairhurst | |||
University of Aberdeen | University of Aberdeen | |||
Department of Engineering | Department of Engineering | |||
Fraser Noble Building | Fraser Noble Building | |||
Aberdeen AB24 3UE | Aberdeen AB24 3UE | |||
Scotland | Scotland | |||
EMail: gorry@erg.abdn.ac.uk | EMail: gorry@erg.abdn.ac.uk | |||
End of changes. 50 change blocks. | ||||
108 lines changed or deleted | 117 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |