draft-ietf-tsvwg-transport-encrypt-10.txt | draft-ietf-tsvwg-transport-encrypt-11.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: July 12, 2020 University of Glasgow | Expires: August 3, 2020 University of Glasgow | |||
January 9, 2020 | January 31, 2020 | |||
Considerations around Transport Header Confidentiality, Network | Considerations around Transport Header Confidentiality, Network | |||
Operations, and the Evolution of Internet Transport Protocols | Operations, and the Evolution of Internet Transport Protocols | |||
draft-ietf-tsvwg-transport-encrypt-10 | draft-ietf-tsvwg-transport-encrypt-11 | |||
Abstract | Abstract | |||
To protect user data and privacy, Internet transport protocols have | To protect user data and privacy, Internet transport protocols have | |||
supported payload encryption and authentication for some time. Such | supported payload encryption and authentication for some time. Such | |||
encryption and authentication is now also starting to be applied to | encryption and authentication is now also starting to be applied to | |||
the transport protocol headers. This helps avoid transport protocol | the transport protocol headers. This helps avoid transport protocol | |||
ossification by middleboxes, while also protecting metadata about the | ossification by middleboxes, while also protecting metadata about the | |||
communication. Current operational practice in some networks inspect | communication. Current operational practice in some networks inspect | |||
transport header information within the network, but this is no | transport header information within the network, but this is no | |||
longer possible when those transport headers are encrypted. This | longer possible when those transport headers are encrypted. This | |||
document discusses the possible impact when network traffic uses a | document discusses the possible impact when network traffic uses a | |||
protocol with an encrypted transport header. It suggests issues to | protocol with an encrypted transport header. It suggests issues to | |||
consider when designing new transport protocols, to account for | consider when designing new transport protocols, to account for | |||
network operations, prevent network ossification, and enable | network operations, prevent network ossification, enable transport | |||
transport evolution, while still respecting user privacy. | evolution, and respect user privacy. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at 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 July 12, 2020. | This Internet-Draft will expire on August 3, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 | 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Use of Transport Header Information in the Network . . . 5 | 2.1. Use of Transport Header Information in the Network . . . 6 | |||
2.2. Authentication of Transport Header Information . . . . . 7 | 2.2. Authentication of Transport Header Information . . . . . 7 | |||
2.3. Observable Transport Header Fields . . . . . . . . . . . 7 | 2.3. Perspectives on Observable Transport Header Fields . . . 8 | |||
3. Current uses of Transport Headers within the Network . . . . 10 | 3. Current uses of Transport Headers within the Network . . . . 11 | |||
3.1. Observing Transport Information in the Network . . . . . 11 | 3.1. Observing Transport Information in the Network . . . . . 12 | |||
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 18 | 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 19 | |||
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 21 | 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 22 | |||
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 23 | 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 24 | |||
4. Encryption and Authentication of Transport Headers . . . . . 23 | 4. Encryption and Authentication of Transport Headers . . . . . 24 | |||
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 23 | 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.2. Approaches to Transport Header Protection . . . . . . . . 24 | 4.2. Approaches to Transport Header Protection . . . . . . . . 25 | |||
5. Addition of Transport Information to Network-Layer Headers . 26 | 5. Addition of Transport Information to Network-Layer Headers . 27 | |||
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 26 | 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27 | |||
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 26 | 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 27 | |||
6. Implications of Protecting the Transport Headers . . . . . . 27 | 6. Implications of Protecting the Transport Headers . . . . . . 28 | |||
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 28 | 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 29 | |||
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 30 | 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 31 | |||
6.3. Accountability and Internet Transport Protocols . . . . . 30 | 6.3. Accountability and Internet Transport Protocols . . . . . 31 | |||
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 31 | 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 32 | |||
6.5. Impact on Research, Development and Deployment . . . . . 31 | 6.5. Impact on Research, Development and Deployment . . . . . 32 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 38 | 11. Informative References . . . . . . . . . . . . . . . . . . . 39 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . 45 | Appendix A. Revision information . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
1. Introduction | 1. Introduction | |||
Transport protocols have supported end-to-end encryption of payload | Transport protocols have supported end-to-end encryption of payload | |||
data for many years. Examples include Transport Layer Security (TLS) | data for many years. Examples include Transport Layer Security (TLS) | |||
over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure | over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure | |||
RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic | RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic | |||
encryption of the TCP transport payload. Some of these also provide | encryption of the TCP transport payload. Some of these also provide | |||
integrity protection of all or part of the transport header. | integrity protection of all or part of the transport header. | |||
skipping to change at page 3, line 38 ¶ | skipping to change at page 3, line 38 ¶ | |||
mode. Virtual Private Networks (VPNs) typically also operate in this | mode. Virtual Private Networks (VPNs) typically also operate in this | |||
way. This form of encryption is not further discussed in this | way. This form of encryption is not further discussed in this | |||
document. | document. | |||
There is also a middle ground, comprising transport protocols that | There is also a middle ground, comprising transport protocols that | |||
encrypt some, or all, of the transport layer header information, in | encrypt some, or all, of the transport layer header information, in | |||
addition to encrypting the payload. An example of such a protocol, | addition to encrypting the payload. An example of such a protocol, | |||
that is now seeing widespread interest and deployment, is the QUIC | that is now seeing widespread interest and deployment, is the QUIC | |||
transport protocol [I-D.ietf-quic-transport]. The encryption and | transport protocol [I-D.ietf-quic-transport]. The encryption and | |||
authentication of transport header information can prevent unwanted | authentication of transport header information can prevent unwanted | |||
modification of transport headers by middleboxes, reducing the risk | modification of transport header information by middleboxes, reducing | |||
of protocol ossification. It also reduces the amount of metadata | the risk of protocol ossification. It also reduces the amount of | |||
about the progress of the transport connection that is visible to the | metadata about the progress of the transport connection that is | |||
network. | visible to the network [RFC8558]. | |||
There are also, however, some costs, in that the widespread use of | ||||
transport encryption requires changes to network operations and other | ||||
practises. Operators could choose to do nothing special with | ||||
encrypted traffic. In some cases, encryption could drive changes to | ||||
the design of network measurement for research, operational, and | ||||
standardisation purposes. | ||||
The direction in which the use of transport header confidentiality | ||||
evolves could have significant implications on the way the Internet | ||||
architecture develops, and therefore needs to be considered as a part | ||||
of protocol design. This include considering whether the endpoints | ||||
permit network devices to observe a specific field of the transport | ||||
header; whether the devices could modify that field; and whether any | ||||
modification can be detected by the receiving endpoint. | ||||
As discussed in [RFC7258], Pervasive Monitoring (PM) is a technical | As discussed in [RFC7258], Pervasive Monitoring (PM) is a technical | |||
attack that needs to be mitigated in the design of IETF protocols. | attack that needs to be mitigated in the design of IETF protocols. | |||
This document supports that conclusion and the use of transport | This document supports that conclusion and the use of transport | |||
header encryption to protect against pervasive monitoring. RFC 7258 | header encryption to protect against pervasive monitoring. RFC 7258 | |||
also notes, though, that "Making networks unmanageable to mitigate PM | also notes, though, that "Making networks unmanageable to mitigate PM | |||
is not an acceptable outcome, but ignoring PM would go against the | is not an acceptable outcome, but ignoring PM would go against the | |||
consensus documented here. An appropriate balance will emerge over | consensus documented here. An appropriate balance will emerge over | |||
time as real instances of this tension are considered". | time as real instances of this tension are considered". | |||
skipping to change at page 5, line 26 ¶ | skipping to change at page 5, line 41 ¶ | |||
The increased use of transport header encryption has benefits, but | The increased use of transport header encryption has benefits, but | |||
also has implications for the broader ecosystem. The transport | also has implications for the broader ecosystem. The transport | |||
community has, to date, relied heavily on measurements and insights | community has, to date, relied heavily on measurements and insights | |||
from the network operations community to understand protocol | from the network operations community to understand protocol | |||
behaviour, and to inform the selection of appropriate mechanisms to | behaviour, and to inform the selection of appropriate mechanisms to | |||
ensure a safe, reliable, and robust Internet. In turn, network | ensure a safe, reliable, and robust Internet. In turn, network | |||
operators and access providers have relied upon being able to observe | operators and access providers have relied upon being able to observe | |||
traffic patterns and requirements, both in aggregate and at the flow | traffic patterns and requirements, both in aggregate and at the flow | |||
level, to help understand and optimise the behaviour of their | level, to help understand and optimise the behaviour of their | |||
networks. Widespread use of transport header encryption could limit | networks. Transport header encryption can be used to intentionally | |||
such observations in future. It is important to understand how | limit the information available to network observers. The widespread | |||
transport header information is used in the network, to allow future | use of transport header encryption would therefore limit such | |||
protocol designs to make an informed choice on what, if any, headers | observations in future. It is important to understand how transport | |||
to expose to the network. | header information is used in the network, to allow future protocol | |||
designs to make an informed choice on what, if any, headers to expose | ||||
to the network. | ||||
2.1. Use of Transport Header Information in the Network | 2.1. Use of Transport Header Information in the Network | |||
In-network measurement of transport flow characteristics can be used | In-network measurement of transport flow characteristics can be used | |||
to enhance performance, and control cost and service reliability. To | to enhance performance, and control cost and service reliability. To | |||
support network operations and enhance performance, some operators | support network operations and enhance performance, some operators | |||
have deployed functionality that utilises on-path observations of the | have deployed functionality that utilises on-path observations of the | |||
transport headers of packets passing through their network. | transport headers of packets passing through their network. | |||
When network devices rely on the presence of a header field or the | When network devices rely on the presence of a header field or the | |||
semantics of specific header information, this can lead to | semantics of specific header information, this can lead to | |||
ossification where an endpoint has to supply a specific header to | ossification where an endpoint has to supply a specific header to | |||
receive the network service that it desires. | receive the network service that it desires. | |||
In some cases, network-layer use of transport header information can | In some cases, network-layer use of transport header information can | |||
be benign or advantageous to the protocol (e.g., recognising the | be benign or advantageous to the protocol (e.g., recognising the | |||
start of a TCP connection, providing header compression for a Secure | start of a TCP connection, providing header compression for a Secure | |||
RTP flow, or explicitly using exposed protocol information to provide | RTP flow, or explicitly using exposed protocol information to provide | |||
consistent decisions by on-path devices). However, in other cases, | consistent decisions by on-path devices). Header compression (e.g., | |||
this can have unwanted outcomes, e.g., privacy impacts and | [RFC5795]) depends understanding of transport header and the way | |||
ossification. | fields change packet-by-packet; as also do techniques to improve TCP | |||
performance by transparent modification of acknowledgement traffic | ||||
[RFC3449]. Introducing a new transport protocol or changes to | ||||
existing transport header information prevent these methods being | ||||
used or require the network devices to be updated. | ||||
However, in other cases, ossification can have unwanted outcomes. | ||||
Ossification can frustrate the evolution of a transport protocol. A | Ossification can frustrate the evolution of a transport protocol. A | |||
mechanism implemented in a network device, such as a firewall, that | mechanism implemented in a network device, such as a firewall, that | |||
requires a header field to have only a specific known set of values | requires a header field to have only a specific known set of values | |||
can prevent the device from forwarding packets using a different | can prevent the device from forwarding packets using a different | |||
version of the protocol that introduces a feature that changes to a | version of the protocol that introduces a feature that changes to a | |||
new value for the observed field. | new value for the observed field. | |||
An example of ossification was observed in the development of | An example of this type ossification was observed in the development | |||
Transport Layer Security (TLS) 1.3 [RFC8446], where the design needed | of Transport Layer Security (TLS) 1.3 [RFC8446], where the design | |||
to function in the presence of deployed middleboxes that relied on | needed to function in the presence of deployed middleboxes that | |||
the presence of certain header fields exposed in TLS 1.2. | relied on the presence of certain header fields exposed in TLS 1.2. | |||
The design of MPTCP also had to be revised to account for middleboxes | The design of MPTCP also had to be revised to account for middleboxes | |||
(known as "TCP Normalizers") that monitor the evolution of the window | (known as "TCP Normalizers") that monitor the evolution of the window | |||
advertised in the TCP header and then reset connections when the | advertised in the TCP header and then reset connections when the | |||
window did not grow as expected. Similarly, issues have been | window did not grow as expected. Similarly, issues have been | |||
reported using TCP. For example, TCP Fast Open can experience | reported using TCP. For example, TCP Fast Open can experience | |||
middleboxes that modify the transport header of packets by removing | middleboxes that modify the transport header of packets by removing | |||
"unknown" TCP options, segments with unrecognised TCP options can be | "unknown" TCP options, segments with unrecognised TCP options can be | |||
dropped, segments that contain data and set the SYN bit can be | dropped, segments that contain data and set the SYN bit can be | |||
dropped, or middleboxes that disrupt connections which send data | dropped, or middleboxes that disrupt connections that send data | |||
before completion of the three-way handshake. Other examples of | before completion of the three-way handshake. | |||
ossification have included middleboxes that rewrite TCP sequence and | ||||
acknowledgement numbers, but are unaware of the (newer) TCP selective | ||||
acknowledgement (SACK) Option and therefore fail to correctly rewrite | ||||
the selective acknowledgement header information to match the changes | ||||
that were made to the fixed TCP header, preventing SACK from | ||||
operating correctly. | ||||
In all these cases, middleboxes with a hard-coded understanding of | Other examples of ossification have included middleboxes that modify | |||
transport behaviour, interacted poorly with transport protocols after | transport headers by rewriting TCP sequence and acknowledgement | |||
the transport behaviour was changed. | numbers, but are unaware of the (newer) TCP selective acknowledgement | |||
(SACK) Option and therefore fail to correctly rewrite the selective | ||||
acknowledgement header information to match the changes that were | ||||
made to the fixed TCP header, preventing SACK from operating | ||||
correctly. | ||||
In all these cases, middleboxes with a hard-coded, but incomplete, | ||||
understanding of transport behaviour, interacted poorly with | ||||
transport protocols after the transport behaviour was changed. | ||||
In contrast, transport header encryption prevents an on-path device | In contrast, transport header encryption prevents an on-path device | |||
from observing the transport headers, and therefore stops mechanisms | from observing the transport headers, and therefore stops mechanisms | |||
being built that directly rely on or infer semantics of the transport | being built that directly rely on or infer semantics of the transport | |||
header information. Encryption is normally combined with | header information. Encryption is normally combined with | |||
authentication of the protected information. RFC 8546 summarises | authentication of the protected information. RFC 8546 summarises | |||
this approach, stating that it is "The wire image, not the protocol's | this approach, stating that it is "The wire image, not the protocol's | |||
specification, determines how third parties on the network paths | specification, determines how third parties on the network paths | |||
among protocol participants will interact with that protocol" | among protocol participants will interact with that protocol" | |||
[RFC8546]. | [RFC8546], and it can be expected that header information that is not | |||
encrypted will become ossified. | ||||
While encryption can reduce ossification of the transport protocol, | While encryption can reduce ossification of the transport protocol, | |||
it does not itself prevent ossification of the network service. | it does not itself prevent ossification of the network service. | |||
People seeking to understand network traffic could still come to rely | People seeking to understand network traffic could still come to rely | |||
on pattern inferences and other heuristics or machine learning to | on pattern inferences and other heuristics or machine learning to | |||
derive measurement data and as the basis for network forwarding | derive measurement data and as the basis for network forwarding | |||
decisions. This can also create dependencies on the transport | decisions [RFC8546]. This can also create dependencies on the | |||
protocol, or the patterns of traffic it can generate. | transport protocol, or the patterns of traffic it can generate, also | |||
in time resulting in ossification of the service. | ||||
2.2. Authentication of Transport Header Information | 2.2. Authentication of Transport Header Information | |||
The designers of a transport protocol decide whether to encrypt all, | The designers of a transport protocol decide whether to encrypt all, | |||
or a part of, the transport header information. Section 4 of RFC8558 | or a part of, the transport header information. Section 4 of RFC8558 | |||
states: "Anything exposed to the path should be done with the intent | states: "Anything exposed to the path should be done with the intent | |||
that it be used by the network elements on the path" [RFC8558]. New | that it be used by the network elements on the path" [RFC8558]. New | |||
protocol designs can decide not to encrypt certain transport header | protocol designs can decide not to encrypt certain transport header | |||
fields, making those fields observable in the network. Where fields | fields, making those fields observable in the network. Where fields | |||
are intended to immutable (i.e., observable but not modifiable by the | are intended to immutable (i.e., observable but not modifiable by the | |||
skipping to change at page 7, line 27 ¶ | skipping to change at page 8, line 8 ¶ | |||
provide a cryptographic integrity check that includes these immutable | provide a cryptographic integrity check that includes these immutable | |||
fields to detect any manipulation by network devices. | fields to detect any manipulation by network devices. | |||
Making part of a transport header observable can lead to ossification | Making part of a transport header observable can lead to ossification | |||
of that part of a header, as middleboxes come to rely on observations | of that part of a header, as middleboxes come to rely on observations | |||
of the exposed fields. A protocol design that provides an observable | of the exposed fields. A protocol design that provides an observable | |||
field might want to avoid inspection restricting the choice of usable | field might want to avoid inspection restricting the choice of usable | |||
values in the field by intentionally varying the format and/or value | values in the field by intentionally varying the format and/or value | |||
of the field to reduce the chance of ossification (see Section 4). | of the field to reduce the chance of ossification (see Section 4). | |||
2.3. Observable Transport Header Fields | 2.3. Perspectives on Observable Transport Header Fields | |||
Transport headers fields have been observed within the network for a | Transport headers fields have been observed within the network for a | |||
variety of purposes. Some of these are related to network management | variety of purposes. Some of these are related to network management | |||
and operations. The lists below, and in the following section, seek | and operations. The lists below, and in the following section, seek | |||
to identify some of these uses and the implications of the increased | to identify some of these uses and the implications of the increased | |||
use of transport header encryption. This analysis does not judge | use of transport header encryption. This analysis does not judge | |||
whether specific practises are necessary, or endorse the use of any | whether specific practises are necessary, or endorse the use of any | |||
specific approach. | specific approach. | |||
Network Operations: Observable transport headers enable explicit | Network Operations: Observable transport headers enable explicit | |||
measurement and analysis of protocol performance, | measurement and analysis of protocol performance, | |||
network anomalies, and failure pathologies at any | network anomalies, and failure pathologies at any | |||
point along the Internet path. In many cases, it | point along the Internet path. In many cases, it | |||
is important to relate observations to specific | is important to relate observations to specific | |||
equipment/configurations, to a specific network | equipment/configurations, to a specific network | |||
segment, or sometimes to a specific protocol or | segment, or sometimes to a specific protocol or | |||
application. | application. | |||
When transport header information is not | When transport header information is not | |||
observable, it cannot be used by network | observable, it cannot be used by network | |||
operators. Operators might work without that | operators. Some operators might work without | |||
information, or they might turn to more ambitious | that information, or some might turn to more | |||
ways to collect, estimate, or infer this data. | ambitious ways to collect, estimate, or infer | |||
(Operational practises aimed at guessing | this data. (Operational practises aimed at | |||
transport parameters are out of scope for this | guessing transport parameters are out of scope | |||
document, and are only mentioned here to | for this document, and are only mentioned here to | |||
recognize that encryption does not stop operators | recognize that encryption does not stop operators | |||
from attempting to apply practises that have been | from attempting to apply practises that have been | |||
used with unencrypted transport headers.) | used with unencrypted transport headers.) | |||
See also Sections 3, 5, and 6.4. | See also Section 3, Section 5, Section 6.4 and s | |||
(Section 6.5). | ||||
Traffic Analysis: Observable transport headers have been used to | Analysis of Aggregate Traffic: Observable transport headers have | |||
determine which transport protocols and features | been used to determine which transport protocols | |||
are being used across a network segment, and to | and features are being used across a network | |||
measure trends in the pattern of usage. For some | segment, and to measure trends in the pattern of | |||
use cases, end-to-end measurements/traces are | usage. For some use cases, end-to-end | |||
sufficient and can assist in developing and | measurements/traces are sufficient and can assist | |||
debugging new transports and analysing their | in developing and debugging new transports and | |||
deployment. In other uses, it is important to | analysing their deployment. In other uses, it is | |||
relate observations to specific equipment/ | important to relate observations to specific | |||
configurations or particular network segments. | equipment/configurations or particular network | |||
segments. | ||||
This information can help anticipate the demand | This information can help anticipate the demand | |||
for network upgrades and roll-out, or affect on- | for network upgrades and roll-out, or affect on- | |||
going traffic engineering activities performed by | going traffic engineering activities performed by | |||
operators such as determining which parts of the | operators such as determining which parts of the | |||
path contribute delay, jitter, or loss. | path contribute delay, jitter, or loss. | |||
Tools that rely upon observing headers, could | Tools that rely upon observing headers, could | |||
fail to produce useful data when those headers | fail to produce useful data when those headers | |||
are encrypted. While this impact could, in many | are encrypted. While this impact could, in many | |||
cases, be small, there are scenarios where | cases, be small, there are scenarios where | |||
operators have actively monitored and supported | operators have actively monitored and supported | |||
particular services, e.g., to explore issues | particular services, e.g., to explore issues | |||
relating to Quality of Service (QoS), to perform | relating to Quality of Service (QoS), to perform | |||
fast re-routing of critical traffic, to mitigate | fast re-routing of critical traffic, to mitigate | |||
the characteristics of specific radio links, and | the characteristics of specific radio links, and | |||
so on. | so on. | |||
See also Sections 3.1-3.2, and 5. | See also Section 3.1 to Section 3.2 and | |||
Section 5. | ||||
Troubleshooting: Observable transport headers have been utilised | Troubleshooting: Observable transport headers have been utilised | |||
by operators as a part of network troubleshooting | by operators as a part of network troubleshooting | |||
and diagnostics. Metrics can help localise the | and diagnostics. Metrics can help localise the | |||
network segment introducing the loss or latency. | network segment introducing the loss or latency. | |||
Effective troubleshooting often requires | Effective troubleshooting often requires | |||
understanding of transport behaviour. Flows | understanding of transport behaviour. Flows | |||
experiencing packet loss or jitter are hard to | experiencing packet loss or jitter are hard to | |||
distinguish from unaffected flows when only | distinguish from unaffected flows when only | |||
observing network layer headers. | observing network layer headers. | |||
Observable transport feedback information (e.g., | Observable transport feedback information (e.g., | |||
RTP Control Protocol (RTCP) reception reports | RTP Control Protocol (RTCP) reception reports | |||
[RFC3550]) can explicitly make loss metrics | [RFC3550]) can explicitly make loss metrics | |||
visible to operators. Loss metrics can also be | visible to operators. Loss metrics can also be | |||
deduced with more complexity from other header | deduced with more complexity from other header | |||
information (e.g., by observing TCP SACK blocks). | information (e.g., by observing TCP SACK blocks). | |||
When the transport header information is | When the transport header information is | |||
encrypted, explicit observable fields could also | encrypted, explicit observable fields could also | |||
be made available at the network or transport | be made available at the network or transport | |||
layers to provide these functions. | layers to provide these functions. [RFC8558] | |||
motivates the design of signals to focus on their | ||||
usage, decoupled from the internal design of the | ||||
protocol state machine. This could avoid | ||||
ossifying the protocol around the design of a | ||||
specific protocol mechanism. | ||||
See also Section 3.3 and 5. | See also Section 3.3 and Section 5. | |||
Network Protection: Observable transport headers currently provide | Network Protection: Observable transport headers currently provide | |||
useful input to classify and detect anomalous | useful input to classify and detect anomalous | |||
events, such as changes in application behaviour | events, such as changes in application behaviour | |||
or distributed denial of service attacks. | or distributed denial of service attacks. | |||
Operators often seek to uniquely disambiguate | Operators often seek to uniquely disambiguate | |||
unwanted traffic. | unwanted traffic. | |||
Where flows cannot be disambiguated based on | Where flows cannot be disambiguated based on | |||
transport information, this could result in less- | transport information, this could result in less- | |||
efficient identification of unwanted traffic, the | efficient identification of unwanted traffic, the | |||
introduction of rate limits for uncharacterised | introduction of rate limits for uncharacterised | |||
traffic, or the use of heuristics to identify | traffic, or the use of heuristics to identify | |||
anomalous flows. | anomalous flows. | |||
See also Sections 6.2 and 6.3. | See also Section 6.2 and Section 6.3. | |||
Verifiable Data: Observable transport headers can provide open and | Verifiable Data: Observable transport headers can provide open and | |||
verifiable measurements to support operations, | verifiable measurements to support operations, | |||
research, and protocol development. The ability | research, and protocol development. The ability | |||
of multiple stake holders to review transport | of multiple stake holders to review transport | |||
header traces helps develop insight into | header traces helps develop insight into | |||
performance and traffic contribution of specific | performance and traffic contribution of specific | |||
variants of a protocol. Independently observed | variants of a protocol. Independently observed | |||
data is important to help ensure the health of | data is important to help ensure the health of | |||
the research and development communities. | the research and development communities. | |||
skipping to change at page 10, line 27 ¶ | skipping to change at page 11, line 18 ¶ | |||
be utilised to demonstrate regulatory compliance | be utilised to demonstrate regulatory compliance | |||
in some jurisdictions, and as a basis for | in some jurisdictions, and as a basis for | |||
informing design decisions. This can bring | informing design decisions. This can bring | |||
assurance to those operating networks, often | assurance to those operating networks, often | |||
avoiding deployment of complex techniques that | avoiding deployment of complex techniques that | |||
routinely monitor and manage Internet traffic | routinely monitor and manage Internet traffic | |||
flows (e.g., avoiding the capital and operational | flows (e.g., avoiding the capital and operational | |||
costs of deploying flow rate-limiting and network | costs of deploying flow rate-limiting and network | |||
circuit-breaker methods [RFC8084]). | circuit-breaker methods [RFC8084]). | |||
See also Sections 5 and 6.1-6.3. | See also Section 5 and Section 6.1 to | |||
Section 6.4. | ||||
Note, again, that this lists uses that have been made of transport | Note, again, that this is a list of example uses that have been made | |||
header information, and does not necessarily endorse any particular | of transport header information. It is not an endorsement of any | |||
approach. | particular practice. | |||
3. Current uses of Transport Headers within the Network | 3. Current uses of Transport Headers within the Network | |||
In response to pervasive monitoring [RFC7624] revelations and the | In response to pervasive monitoring [RFC7624] revelations and the | |||
IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], | IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], | |||
efforts are underway to increase encryption of Internet traffic. | efforts are underway to increase encryption of Internet traffic. | |||
Applying confidentiality to transport header fields affects how | Applying confidentiality to transport header fields affects how | |||
protocol information is used [RFC8404], requiring consideration of | protocol information is used [RFC8404], requiring consideration of | |||
the trade-offs discussed in Section 2.3. | the trade-offs discussed in Section 2.3. | |||
There are architectural challenges and considerations in the way | There are architectural challenges and considerations in the way | |||
transport protocols are designed, and the ability to characterise and | transport protocols are designed, and the ability to characterise and | |||
compare different transport solutions [Measure]. The decision about | compare different transport solutions [Measurement]. The decision | |||
which transport headers fields are made observable offers trade-offs | about which transport headers fields are made observable offers | |||
around header confidentiality versus header observability (including | trade-offs around header confidentiality versus header observability | |||
non-encrypted but authenticated header fields) for network operations | (including non-encrypted but authenticated header fields) for network | |||
and management, and the implications for ossification and user | operations and management, and the implications for ossification and | |||
privacy. Different parties will view the relative importance of | user privacy. Different parties will view the relative importance of | |||
these differently. For some, the benefits of encrypting all | these differently. For some, the benefits of encrypting all | |||
transport headers outweigh the impact of doing so; others might | transport headers outweigh the impact of doing so; others might | |||
analyse the security, privacy and ossification impacts and arrive at | analyse the security, privacy and ossification impacts and arrive at | |||
a different trade-off. | a different trade-off. | |||
To understand the implications, it is necessary to understand how | To understand the implications, it is necessary to understand how | |||
transport layer headers are currently observed and/or modified by | transport layer headers are currently observed and/or modified by | |||
middleboxes within the network. This section therefore reviews | middleboxes within the network. This section therefore reviews | |||
examples of current usage. It does not consider the intentional | examples of current usage. It does not consider the intentional | |||
modification of transport headers by middleboxes (such as in Network | modification of transport headers by middleboxes (such as in Network | |||
skipping to change at page 12, line 12 ¶ | skipping to change at page 13, line 6 ¶ | |||
identify the protocol. However, port information alone is not | identify the protocol. However, port information alone is not | |||
sufficient to guarantee identification. Applications can use | sufficient to guarantee identification. Applications can use | |||
arbitrary ports, multiple sessions can be multiplexed on a single | arbitrary ports, multiple sessions can be multiplexed on a single | |||
port, and ports can be re-used by subsequent sessions. UDP-based | port, and ports can be re-used by subsequent sessions. UDP-based | |||
protocols often do not use well-known port numbers. Some flows can | protocols often do not use well-known port numbers. Some flows can | |||
be identified by observing signalling protocol data (e.g., [RFC3261], | be identified by observing signalling protocol data (e.g., [RFC3261], | |||
[I-D.ietf-rtcweb-overview]) or through the use of magic numbers | [I-D.ietf-rtcweb-overview]) or through the use of magic numbers | |||
placed in the first byte(s) of the datagram payload [RFC7983]. | placed in the first byte(s) of the datagram payload [RFC7983]. | |||
When transport header information can not be observed, this removes | When transport header information can not be observed, this removes | |||
information that could be used to classify flows by passive observers | information that could have been used to classify flows by passive | |||
along the path. More ambitious ways could be used to collect, | observers along the path. More ambitious ways could be used to | |||
estimate, or infer flow information, including heuristics based on | collect, estimate, or infer flow information, including heuristics | |||
the analysis of traffic patterns. For example, an operator that | based on the analysis of traffic patterns. For example, an operator | |||
cannot access the Session Description Protocol (SDP) session | that cannot access the Session Description Protocol (SDP) session | |||
descriptions to classify a flow as audio traffic, might instead use | descriptions to classify a flow as audio traffic, might instead use | |||
(possibly less-reliable) heuristics to infer that short UDP packets | (possibly less-reliable) heuristics to infer that short UDP packets | |||
with regular spacing carry audio traffic. Operational practises | with regular spacing carry audio traffic. Operational practises | |||
aimed at inferring transport parameters are out of scope for this | aimed at inferring 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 | |||
does not prevent operators from attempting to apply practises that | does not prevent operators from attempting to apply practises that | |||
were used with unencrypted transport headers. | were used with unencrypted transport headers. The IAB have provided | |||
a summary of expected implications of increased encryption on network | ||||
functions that use the observable headers [RFC8546] and describe the | ||||
expected benefits of designs that explicitly declare protocol | ||||
invarient header information that can be used for this purpose. | ||||
3.1.2. Metrics derived from Transport Layer Headers | 3.1.2. Metrics derived from Transport Layer Headers | |||
Observable transport headers enable explicit measurement and analysis | Observable transport headers enable explicit measurement and analysis | |||
of protocol performance, network anomalies, and failure pathologies | of protocol performance, network anomalies, and failure pathologies | |||
at any point along the Internet path. Some operators use passive | at any point along the Internet path. Some operators use passive | |||
monitoring to manage their portion of the Internet by characterizing | monitoring to manage their portion of the Internet by characterizing | |||
the performance of link/network segments. Inferences from transport | the performance of link/network segments. Inferences from transport | |||
headers are used to derive performance metrics. A variety of open | headers are used to derive performance metrics. A variety of open | |||
source and commercial tools have been deployed that utilise transport | source and commercial tools have been deployed that utilise transport | |||
header information in this way to derive the following metrics: | header information in this way to derive the following metrics: | |||
Traffic Rate and Volume: Protocol sequence number and packet size | Traffic Rate and Volume: Volume measures per-application can be used | |||
could be used to derive volume measures per-application, to | to characterise the traffic that uses a network segment or the | |||
characterise the traffic that uses a network segment or the | pattern of network usage. Observing the protocol sequence number | |||
pattern of network usage. Measurements can be per endpoint or for | and packet size offers one way to meausre this (e.g., measurements | |||
an endpoint aggregate (e.g., to assess subscriber usage). | observing counters in periodic reports such as RTCP; or | |||
Measurements can also be used to trigger traffic shaping, and to | measurements observing protocol sequence numbers in statistical | |||
associate QoS support within the network and lower layers. Volume | samples of packet flows, or specific control packets, such as | |||
measures can also be valuable for capacity planning and providing | those observed at the start and end of a flow). Measurements can | |||
detail of trends in usage. The traffic rate and volume can be | be per endpoint or for an endpoint aggregate (e.g., to assess | |||
determined providing that the packets belonging to individual | subscriber usage). Measurements can also be used to trigger | |||
flows can be identified, but there might be no additional | traffic shaping, and to associate QoS support within the network | |||
information about a flow when the transport headers cannot be | and lower layers. Volume measures can also be valuable for | |||
observed. | capacity planning and providing detail of trends in usage. The | |||
traffic rate and volume can be determined providing that the | ||||
packets belonging to individual flows can be identified, but there | ||||
might be no additional information about a flow when the transport | ||||
headers cannot be observed. | ||||
Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., | Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., | |||
from transport sequence numbers or inferred from observing | from transport sequence numbers or inferred from observing | |||
transport protocol interactions) and has been used as a metric for | transport protocol interactions) and has been used as a metric for | |||
performance assessment and to characterise transport behaviour. | performance assessment and to characterise transport behaviour. | |||
Understanding the location and root cause of loss can help an | Understanding the location and root cause of loss can help an | |||
operator determine whether this requires corrective action. | operator determine whether this requires corrective action. | |||
Network operators have used the variation in patterns of loss as a | Network operators have used the variation in patterns of loss as a | |||
key performance metric, utilising this to detect changes in the | key performance metric, utilising this to detect changes in the | |||
offered service. | offered service. | |||
skipping to change at page 15, line 38 ¶ | skipping to change at page 16, line 39 ¶ | |||
source of this data and the method used to generate the summary | source of this data and the method used to generate the summary | |||
information. | information. | |||
These metrics can support network operations, inform capacity | These metrics can support network operations, inform capacity | |||
planning, and assist in determining the demand for equipment and/or | planning, and assist in determining the demand for equipment and/or | |||
configuration changes by network operators. They can also inform | configuration changes by network operators. They can also inform | |||
Internet engineering activities by informing the development of new | Internet engineering activities by informing the development of new | |||
protocols, methodologies, and procedures. | protocols, methodologies, and procedures. | |||
In some cases, measurements could involve active injection of test | In some cases, measurements could involve active injection of test | |||
traffic to perform a measurement (see section 3.4 of [RFC7799]). | traffic to perform a measurement (see Section 3.4 of [RFC7799]). | |||
However, most operators do not have access to user equipment, | However, most operators do not have access to user equipment, | |||
therefore the point of test is normally different from the transport | therefore the point of test is normally different from the transport | |||
endpoint. Injection of test traffic can incur an additional cost in | endpoint. Injection of test traffic can incur an additional cost in | |||
running such tests (e.g., the implications of capacity tests in a | running such tests (e.g., the implications of capacity tests in a | |||
mobile network are obvious). Some active measurements [RFC7799] | mobile network are obvious). Some active measurements [RFC7799] | |||
(e.g., response under load or particular workloads) perturb other | (e.g., response under load or particular workloads) perturb other | |||
traffic, and could require dedicated access to the network segment. | traffic, and could require dedicated access to the network segment. | |||
Passive measurements (see section 3.6 of [RFC7799]) can have | Passive measurements (see Section 3.6 of [RFC7799]) can have | |||
advantages in terms of eliminating unproductive test traffic, | advantages in terms of eliminating unproductive test traffic, | |||
reducing the influence of test traffic on the overall traffic mix, | reducing the influence of test traffic on the overall traffic mix, | |||
and the ability to choose the point of observation (see | and the ability to choose the point of observation (see | |||
Section 3.2.1). Measurements can rely on observing packet headers, | Section 3.2.1). Measurements can rely on observing packet headers, | |||
which is not possible if those headers are encrypted, but could | which is not possible if those headers are encrypted, but could | |||
utilise information about traffic volumes or patterns of interaction | utilise information about traffic volumes or patterns of interaction | |||
to deduce metrics. | to deduce metrics. | |||
An alternative approach is to use in-network techniques add and | An alternative approach is to use in-network techniques to add and | |||
observe packet headers to facilitate measurements while traffic | observe packet headers to facilitate measurements while traffic | |||
traverses an operational network. This approach does not require the | traverses an operational network. This approach does not require the | |||
cooperation of an endpoint. | cooperation of an endpoint. | |||
3.1.3. Transport use of Network Layer Header Fields | 3.1.3. Transport use of Network Layer Header Fields | |||
Information from the transport protocol is used by a multi-field | Information from the transport protocol is used by a multi-field | |||
classifier as a part of policy framework. Policies are commonly used | classifier as a part of policy framework. Policies are commonly used | |||
for management of the QoS or Quality of Experience (QoE) in resource- | for management of the QoS or Quality of Experience (QoE) in resource- | |||
constrained networks, and by firewalls to implement access rules (see | constrained networks, and by firewalls to implement access rules (see | |||
also section 2.2.2 of [RFC8404]). Network-layer classification | also Section 2.2.2 of [RFC8404]). Network-layer classification | |||
methods that rely on a multi-field classifier (e.g., inferring QoS | methods that rely on a multi-field classifier (e.g., inferring QoS | |||
from the 5-tuple or choice of application protocol) are incompatible | from the 5-tuple or choice of application protocol) are incompatible | |||
with transport protocols that encrypt the transport information. | with transport protocols that encrypt the transport information. | |||
Traffic that cannot be classified typically receives a default | Traffic that cannot be classified typically receives a default | |||
treatment. | treatment. | |||
Transport information can also be explicitly set in network-layer | Transport information can also be explicitly set in network-layer | |||
header fields that are not encrypted, serving as a replacement/ | header fields that are not encrypted, serving as a replacement/ | |||
addition to the exposed transport information [RFC8558]. This | addition to the exposed transport information [RFC8558]. This | |||
information can enable a different forwarding treatment by the | information can enable a different forwarding treatment by the | |||
skipping to change at page 17, line 47 ¶ | skipping to change at page 18, line 48 ¶ | |||
to be classified the same). The field is mutable, i.e., some | to be classified the same). The field is mutable, i.e., some | |||
network devices can be expected to change this field (use of each | network devices can be expected to change this field (use of each | |||
DSCP value is defined by an RFC). | DSCP value is defined by an RFC). | |||
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 has to consider this | flow, observations of service performance has to consider this | |||
field when a network path supports differentiated service | field when a network path supports 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 uses the ECN field in the network-layer header. | |||
Use of ECN explicitly informs the network-layer that a transport | Use of ECN explicitly informs the network-layer that a transport | |||
is ECN-capable, and requests ECN treatment of the flow. An ECN- | is ECN-capable, and requests ECN treatment of the flow. An ECN- | |||
capable transport can offer benefits when used over a path with | capable transport can offer benefits when used over a path with | |||
equipment that implements an AQM method with CE marking of IP | equipment that implements an AQM method with CE marking of IP | |||
packets [RFC8087], since it can react to congestion without also | packets [RFC8087], since it can react to congestion without also | |||
having to recover from lost packets. | having to recover from lost packets. | |||
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 | |||
skipping to change at page 18, line 23 ¶ | skipping to change at page 19, line 24 ¶ | |||
AQM and ECN offer a range of algorithms and configuration options. | AQM and ECN offer a range of algorithms and configuration options. | |||
Tools therefore have to be available to network operators and | Tools therefore have to be available to network operators and | |||
researchers to understand the implication of configuration choices | researchers to understand the implication of configuration choices | |||
and transport behaviour as the use of ECN increases and new | and transport behaviour as the use of ECN increases and new | |||
methods emerge [RFC7567]. | methods emerge [RFC7567]. | |||
When transport headers cannot be observed, operators are unable to | When transport headers cannot be observed, operators are unable to | |||
use this information directly. Careful use of the network layer | use this information directly. Careful use of the network layer | |||
features can help provide similar information in the case where the | features can help provide similar information in the case where the | |||
network is unable to inspect transport protocol headers. | network is unable to inspect transport protocol headers. Section 5 | |||
Section Section 5 describes use of network extension headers. | describes use of network extension 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 | |||
layer, until the emergence of transport protocols performing header | layer, until the emergence of transport protocols performing header | |||
encryption, with the obvious exception of VPNs and IPsec. | encryption, with the obvious exception of VPNs and IPsec. | |||
When encryption hides more layers in each packet, people seeking | When encryption hides more layers in each packet, people seeking | |||
understanding of the network operation rely more on pattern inference | understanding of the network operation rely more on pattern inference | |||
and other heuristics. It remains to be seen whether more complex | and other heuristics. It remains to be seen whether more complex | |||
inferences can be mastered to produce the same monitoring accuracy | inferences can be mastered to produce the same monitoring accuracy | |||
(see section 2.1.1 of [RFC8404]). | (see Section 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 necessary to interpret this data to answer questions about | often necessary to interpret this data to answer questions about | |||
network performance or understand a pathology. Collecting and | network performance or understand a pathology. Collecting and | |||
coordinating such metadata is more difficult when the observation | coordinating such metadata is more difficult when the observation | |||
point is at a different location to the bottleneck/device under | point is at a different location to the bottleneck/device under | |||
evaluation [RFC7799]. | evaluation [RFC7799]. | |||
Packet sampling techniques are used to scale the processing involved | Packet sampling techniques are used to scale the processing involved | |||
skipping to change at page 23, line 41 ¶ | skipping to change at page 24, line 41 ¶ | |||
the network. It can also help protect the privacy of a user, by | the network. It can also help protect the privacy of a user, by | |||
hiding data relating to user/device identity or location. | hiding data relating to user/device identity or location. | |||
4.1. Motivation | 4.1. Motivation | |||
There are several motivations for encryption: | There are several motivations for encryption: | |||
o One motive to encrypt transport headers is in response to | o One motive to encrypt transport headers is in response to | |||
perceptions that the network has become ossified, since traffic | perceptions that the network has become ossified, since traffic | |||
inspecting middleboxes prevent new protocols and mechanisms from | inspecting middleboxes prevent new protocols and mechanisms from | |||
being deployed. This has lead to a perception that there is too | being deployed. One benefit of encrypting transport headers is | |||
much "manipulation" of protocol headers within the network, and | that it can help improve the pace of transport development by | |||
that designing to deploy in such networks is preventing transport | eliminating interference by deployed middleboxes. | |||
evolution. One benefit of encrypting transport headers is that it | ||||
can help improve the pace of transport development by eliminating | ||||
interference by deployed middleboxes. | ||||
o Another motivation stems from increased concerns about privacy and | o Another motivation stems from increased concerns about privacy and | |||
surveillance. Users value the ability to protect their identity | surveillance. Users value the ability to protect their identity | |||
and location, and defend against traffic analysis. Revelations | and location, and defend against analysis of the traffic. | |||
about the use of pervasive surveillance [RFC7624] have, to some | Revelations about the use of pervasive surveillance [RFC7624] | |||
extent, eroded trust in the service offered by network operators | have, to some extent, eroded trust in the service offered by | |||
and have led to an increased use of encryption to avoid unwanted | network operators and have led to an increased use of encryption | |||
eavesdropping on communications. Concerns have also been voiced | to avoid unwanted eavesdropping on communications. Concerns have | |||
about the addition of information to packets by third parties to | also been voiced about the addition of information to packets by | |||
provide analytics, customization, advertising, cross-site tracking | third parties to provide analytics, customization, advertising, | |||
of users, to bill the customer, or to selectively allow or block | cross-site tracking of users, to bill the customer, or to | |||
content. Whatever the reasons, the IETF is designing protocols | selectively allow or block content. Whatever the reasons, the | |||
that include transport header encryption (e.g., QUIC | IETF is designing protocols that include transport header | |||
[I-D.ietf-quic-transport]) to supplement the already widespread | encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement | |||
payload encryption, and to further limit exposure of transport | the already widespread payload encryption, and to further limit | |||
metadata to the network. | exposure of transport metadata to the network. | |||
The use of transport header authentication and encryption exposes a | The use of transport header authentication and encryption exposes a | |||
tussle between middlebox vendors, operators, applications developers | tussle between middlebox vendors, operators, applications developers | |||
and users: | and users: | |||
o On the one hand, future Internet protocols that support transport | o On the one hand, future Internet protocols that support transport | |||
header encryption assist in the restoration of the end-to-end | header encryption assist in the restoration of the end-to-end | |||
nature of the Internet by returning complex processing to the | nature of the Internet by returning complex processing to the | |||
endpoints, since middleboxes cannot modify what they cannot see, | endpoints, since middleboxes cannot modify what they cannot see, | |||
and can improve privacy by reducing leakage of transport metadata. | and can improve privacy by reducing leakage of transport metadata. | |||
skipping to change at page 27, line 30 ¶ | skipping to change at page 28, line 27 ¶ | |||
packets that set an IPv6 header extension (e.g., results from 2016 in | packets that set an IPv6 header extension (e.g., results from 2016 in | |||
[RFC7872]). | [RFC7872]). | |||
Protocols can be designed to expose header information separately to | Protocols can be designed to expose header information separately to | |||
the (hidden) fields used by the protocol state machine. On the one | the (hidden) fields used by the protocol state machine. On the one | |||
hand, such approaches can simplify tools by exposing the relevant | hand, such approaches can simplify tools by exposing the relevant | |||
metrics (loss, latency, etc), rather having to derive this from other | metrics (loss, latency, etc), rather having to derive this from other | |||
fields. This also permits the protocol to evolve independently of | fields. This also permits the protocol to evolve independently of | |||
the ossified observable header [RFC8558]. On the other hand, | the ossified observable header [RFC8558]. On the other hand, | |||
protocols do not necessarily have an incentive to expose the actual | protocols do not necessarily have an incentive to expose the actual | |||
information that is utilised by the protocol itself and could | information that is used by the protocol itself and could therefore | |||
therefore manipulate the exposed header information to gain an | manipulate the exposed header information to gain an advantage from | |||
advantage from the network. Where the information is provided by an | the network. Where the information is provided by an endpoint, the | |||
endpoint, the incentive to reflect actual transport information has | incentive to reflect actual transport information has to be | |||
to be considered when proposing a method. | considered when proposing a method. | |||
6. Implications of Protecting the Transport Headers | 6. Implications of Protecting the Transport Headers | |||
The choice of which transport header fields to expose and which to | The choice of which transport header fields to expose and which to | |||
encrypt is a design decision for the transport protocol. Selective | encrypt is a design decision for the transport protocol. Selective | |||
encryption requires trading conflicting goals of observability and | encryption requires trading conflicting goals of observability and | |||
network support, privacy, and risk of ossification, to decide what | network support, privacy, and risk of ossification, to decide what | |||
header fields to protect and which to make visible. | header fields to protect and which to make visible. | |||
Security work typically employs a design technique that seeks to | Security work typically employs a design technique that seeks to | |||
skipping to change at page 28, line 19 ¶ | skipping to change at page 29, line 19 ¶ | |||
network. Encrypting transport header encryption changes the ability | network. Encrypting transport header encryption changes the ability | |||
to collect and independently analyse data. Internet transport | to collect and independently analyse data. Internet transport | |||
protocols employ a set of mechanisms. Some of these have to work in | protocols employ a set of mechanisms. Some of these have to work in | |||
cooperation with the network layer for loss detection and recovery, | cooperation with the network layer for loss detection and recovery, | |||
congestion detection and control. Others have to work only end-to- | congestion detection and control. Others have to work only end-to- | |||
end (e.g., parameter negotiation, flow-control). | end (e.g., parameter negotiation, flow-control). | |||
The majority of present Internet applications use two well-known | The majority of present Internet applications use two well-known | |||
transport protocols, TCP and UDP. Although TCP represents the | transport protocols, TCP and UDP. Although TCP represents the | |||
majority of current traffic, many real-time applications use UDP, and | majority of current traffic, many real-time applications use UDP, and | |||
much of this traffic utilises RTP format headers in the payload of | much of this traffic uses RTP format headers in the payload of the | |||
the UDP datagram. Since these protocol headers have been fixed for | UDP datagram. Since these protocol headers have been fixed for | |||
decades, a range of tools and analysis methods have became common and | decades, a range of tools and analysis methods have became common and | |||
well-understood. | well-understood. | |||
Protocols that expose the state information used by the transport | Protocols that expose the state information used by the transport | |||
protocol in their header information (e.g., timestamps used to | protocol in their header information (e.g., timestamps used to | |||
calculate the RTT, packet numbers used to asses congestion and | calculate the RTT, packet numbers used to asses congestion and | |||
requests for retransmission) provide an incentive for the sending | requests for retransmission) provide an incentive for the sending | |||
endpoint to provide correct information, since the protocol will not | endpoint to provide correct information, since the protocol will not | |||
work otherwise. This increases confidence that the observer | work otherwise. This increases confidence that the observer | |||
understands the transport interaction with the network. For example, | understands the transport interaction with the network. For example, | |||
skipping to change at page 36, line 50 ¶ | skipping to change at page 37, line 50 ¶ | |||
management functions monitor packets or flows and anti-spam | management functions monitor packets or flows and anti-spam | |||
mechanisms need to see mail message content." [RFC7258]. This can | mechanisms need to see mail message content." [RFC7258]. This can | |||
be used as the first line of defence to identify potential threats | be used as the first line of defence to identify potential threats | |||
from DOS or malware and redirect suspect traffic to dedicated nodes | from DOS or malware and redirect suspect traffic to dedicated nodes | |||
responsible for DOS analysis, malware detection, or to perform packet | responsible for DOS analysis, malware detection, or to perform packet | |||
"scrubbing" (the normalization of packets so that there are no | "scrubbing" (the normalization of packets so that there are no | |||
ambiguities in interpretation by the ultimate destination of the | ambiguities in interpretation by the ultimate destination of the | |||
packet). These techniques are currently used by some operators to | packet). These techniques are currently used by some operators to | |||
also defend from distributed DOS attacks. | also defend from distributed DOS attacks. | |||
Exposed transport header fields are sometimes also utilised as a part | Exposed transport header fields can also form a part of the | |||
of the information used by the receiver of a transport protocol to | information used by the receiver of a transport protocol to protect | |||
protect the transport layer from data injection by an attacker. In | the transport layer from data injection by an attacker. In | |||
evaluating this use of exposed header information, it is important to | evaluating this use of exposed header information, it is important to | |||
consider whether it introduces a significant DOS threat. For | consider whether it introduces a significant DOS threat. For | |||
example, an attacker could construct a DOS attack by sending packets | example, an attacker could construct a DOS attack by sending packets | |||
with a sequence number that falls within the currently accepted range | with a sequence number that falls within the currently accepted range | |||
of sequence numbers at the receiving endpoint, this would then | of sequence numbers at the receiving endpoint, this would then | |||
introduce additional work at the receiving endpoint, even though the | introduce additional work at the receiving endpoint, even though the | |||
data in the attacking packet might not finally be delivered by the | data in the attacking packet might not finally be delivered by the | |||
transport layer. This is sometimes known as a "shadowing attack". | transport layer. This is sometimes known as a "shadowing attack". | |||
An attack can, for example, disrupt receiver processing, trigger loss | An attack can, for example, disrupt receiver processing, trigger loss | |||
and retransmission, or make a receiving endpoint perform unproductive | and retransmission, or make a receiving endpoint perform unproductive | |||
decryption of packets that cannot be successfully decrypted (forcing | decryption of packets that cannot be successfully decrypted (forcing | |||
a receiver to commit decryption resources, or to update and then | a receiver to commit decryption resources, or to update and then | |||
restore protocol state). | restore protocol state). | |||
One mitigation to off-path attack is to deny knowledge of what header | One mitigation to off-path attack is to deny knowledge of what header | |||
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 a validation check before accepting packets | to be used as a part of a validation check before accepting packets | |||
at the transport layer (e.g., utilising a part of the sequence number | at the transport layer (e.g., utilising a part of the sequence number | |||
space that is encrypted; or by verifying an encrypted token not | space that is encrypted; or by verifying an encrypted token not | |||
visible to an attacker). This would also mitigate against on-path | visible to an attacker). This would also mitigate against on-path | |||
attacks. An additional processing cost can be incurred when | attacks. An additional processing cost can be incurred when | |||
decryption has to be attempted before a receiver is able to discard | decryption has to be attempted before a receiver is able to discard | |||
injected packets. | injected packets. | |||
Open standards motivate a desire for this evaluation to include | Open standards motivate a desire for this evaluation to include | |||
skipping to change at page 38, line 10 ¶ | skipping to change at page 39, line 10 ¶ | |||
XX RFC ED - PLEASE REMOVE THIS SECTION XXX | XX RFC ED - PLEASE REMOVE THIS SECTION XXX | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
10. Acknowledgements | 10. Acknowledgements | |||
The authors would like to thank Mohamed Boucadair, Spencer Dawkins, | The authors would like to thank Mohamed Boucadair, Spencer Dawkins, | |||
Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen | Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen | |||
Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris | Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris | |||
Wood, Thomas Fossati, and other members of the TSVWG for their | Wood, Thomas Fossati, Martin Thomson, and other members of the TSVWG | |||
comments and feedback. | for their comments and feedback. | |||
This work has received funding from the European Union's Horizon 2020 | This work has received funding from the European Union's Horizon 2020 | |||
research and innovation programme under grant agreement No 688421, | research and innovation programme under grant agreement No 688421, | |||
and the EU Stand ICT Call 4. The opinions expressed and arguments | and the EU Stand ICT Call 4. The opinions expressed and arguments | |||
employed reflect only the authors' view. The European Commission is | employed reflect only the authors' view. The European Commission is | |||
not responsible for any use that might be made of that information. | not responsible for any use that might be made of that information. | |||
This work has received funding from the UK Engineering and Physical | This work has received funding from the UK Engineering and Physical | |||
Sciences Research Council under grant EP/R04144X/1. | Sciences Research Council under grant EP/R04144X/1. | |||
skipping to change at page 39, line 19 ¶ | skipping to change at page 40, line 19 ¶ | |||
[I-D.trammell-plus-abstract-mech] | [I-D.trammell-plus-abstract-mech] | |||
Trammell, B., "Abstract Mechanisms for a Cooperative Path | Trammell, B., "Abstract Mechanisms for a Cooperative Path | |||
Layer under Endpoint Control", draft-trammell-plus- | Layer under Endpoint Control", draft-trammell-plus- | |||
abstract-mech-00 (work in progress), September 2016. | abstract-mech-00 (work in progress), September 2016. | |||
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of | |||
Techniques and Their Merits, IEEE Comm. Surveys & | Techniques and Their Merits, IEEE Comm. Surveys & | |||
Tutorials. 26;18(3) p2149-2196", November 2014. | Tutorials. 26;18(3) p2149-2196", November 2014. | |||
[Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- | [Measurement] | |||
Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- | ||||
based Protocol Design, Eur. Conf. on Networks and | based Protocol Design, Eur. Conf. on Networks and | |||
Communications, Oulu, Finland.", June 2017. | Communications, Oulu, Finland.", June 2017. | |||
[Quic-Trace] | [Quic-Trace] | |||
"https:QUIC trace utilities //github.com/google/quic- | "https:QUIC trace utilities //github.com/google/quic- | |||
trace". | trace". | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
skipping to change at page 40, line 25 ¶ | skipping to change at page 41, line 25 ¶ | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | Schooler, "SIP: Session Initiation Protocol", RFC 3261, | |||
DOI 10.17487/RFC3261, June 2002, | DOI 10.17487/RFC3261, June 2002, | |||
<https://www.rfc-editor.org/info/rfc3261>. | <https://www.rfc-editor.org/info/rfc3261>. | |||
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||
Metric for IP Performance Metrics (IPPM)", RFC 3393, | Metric for IP Performance Metrics (IPPM)", RFC 3393, | |||
DOI 10.17487/RFC3393, November 2002, | DOI 10.17487/RFC3393, November 2002, | |||
<https://www.rfc-editor.org/info/rfc3393>. | <https://www.rfc-editor.org/info/rfc3393>. | |||
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. | ||||
Sooriyabandara, "TCP Performance Implications of Network | ||||
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, | ||||
December 2002, <https://www.rfc-editor.org/info/rfc3449>. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <https://www.rfc-editor.org/info/rfc3550>. | July 2003, <https://www.rfc-editor.org/info/rfc3550>. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<https://www.rfc-editor.org/info/rfc3711>. | <https://www.rfc-editor.org/info/rfc3711>. | |||
skipping to change at page 41, line 23 ¶ | skipping to change at page 42, line 28 ¶ | |||
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. | [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. | |||
Whitner, "Improved Packet Reordering Metrics", RFC 5236, | Whitner, "Improved Packet Reordering Metrics", RFC 5236, | |||
DOI 10.17487/RFC5236, June 2008, | DOI 10.17487/RFC5236, June 2008, | |||
<https://www.rfc-editor.org/info/rfc5236>. | <https://www.rfc-editor.org/info/rfc5236>. | |||
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | |||
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, | Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, | |||
March 2009, <https://www.rfc-editor.org/info/rfc5481>. | March 2009, <https://www.rfc-editor.org/info/rfc5481>. | |||
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust | ||||
Header Compression (ROHC) Framework", RFC 5795, | ||||
DOI 10.17487/RFC5795, March 2010, | ||||
<https://www.rfc-editor.org/info/rfc5795>. | ||||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | |||
June 2010, <https://www.rfc-editor.org/info/rfc5925>. | June 2010, <https://www.rfc-editor.org/info/rfc5925>. | |||
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- | |||
Protocol Port Randomization", BCP 156, RFC 6056, | Protocol Port Randomization", BCP 156, RFC 6056, | |||
DOI 10.17487/RFC6056, January 2011, | DOI 10.17487/RFC6056, January 2011, | |||
<https://www.rfc-editor.org/info/rfc6056>. | <https://www.rfc-editor.org/info/rfc6056>. | |||
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and | [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and | |||
skipping to change at page 47, line 7 ¶ | skipping to change at page 48, line 7 ¶ | |||
Added summary text and refs to key sections. Note to editors: The | Added summary text and refs to key sections. Note to editors: The | |||
section numbers are hard-linked. | section numbers are hard-linked. | |||
-10 Updated following additional feedback from 1st WGLC. Comments | -10 Updated following additional feedback from 1st WGLC. Comments | |||
from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter | from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter | |||
Gutmann; Ekr; and many others via the TSVWG list. Some people | Gutmann; Ekr; and many others via the TSVWG list. Some people | |||
thought that "needed" and "need" could represent requirements in the | thought that "needed" and "need" could represent requirements in the | |||
document, etc. this has been clarified. | document, etc. this has been clarified. | |||
-11 Updated following additional feedback from Martin Thomson, and | ||||
corrections from other reviewers. | ||||
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. 47 change blocks. | ||||
155 lines changed or deleted | 208 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/ |