draft-ietf-tsvwg-transport-encrypt-09.txt | draft-ietf-tsvwg-transport-encrypt-10.txt | |||
---|---|---|---|---|
TSVWG G. Fairhurst | TSVWG G. Fairhurst | |||
Internet-Draft University of Aberdeen | Internet-Draft University of Aberdeen | |||
Intended status: Informational C. Perkins | Intended status: Informational C. Perkins | |||
Expires: May 6, 2020 University of Glasgow | Expires: July 12, 2020 University of Glasgow | |||
November 3, 2019 | January 9, 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-09 | draft-ietf-tsvwg-transport-encrypt-10 | |||
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 | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 6, 2020. | This Internet-Draft will expire on July 12, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 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 . . . 5 | |||
2.2. Authentication of Transport Header Information . . . . . 6 | 2.2. Authentication of Transport Header Information . . . . . 7 | |||
2.3. Observable Transport Header Fields . . . . . . . . . . . 7 | 2.3. Observable Transport Header Fields . . . . . . . . . . . 7 | |||
3. Current uses of Transport Headers within the Network . . . . 10 | 3. Current uses of Transport Headers within the Network . . . . 10 | |||
3.1. Observing Transport Information in the Network . . . . . 11 | 3.1. Observing Transport Information in the Network . . . . . 11 | |||
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 17 | 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 18 | |||
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 21 | 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 21 | |||
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 22 | 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 23 | |||
4. Encryption and Authentication of Transport Headers . . . . . 23 | 4. Encryption and Authentication of Transport Headers . . . . . 23 | |||
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
4.2. Approaches to Transport Header Protection . . . . . . . . 24 | ||||
5. Addition of Transport Information to Network-Layer Headers . 26 | 5. Addition of Transport Information to Network-Layer Headers . 26 | |||
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 26 | 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 26 | |||
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 26 | 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 26 | |||
6. Implications of Protecting the Transport Headers . . . . . . 27 | 6. Implications of Protecting the Transport Headers . . . . . . 27 | |||
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 27 | 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 28 | |||
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 29 | 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 30 | |||
6.3. Accountability and Internet Transport Protocols . . . . . 30 | 6.3. Accountability and Internet Transport Protocols . . . . . 30 | |||
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 30 | 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 31 | |||
6.5. Impact on Research, Development and Deployment . . . . . 31 | 6.5. Impact on Research, Development and Deployment . . . . . 31 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 38 | 11. Informative References . . . . . . . . . . . . . . . . . . . 38 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . 45 | Appendix A. Revision information . . . . . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
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], and their | over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure | |||
corresponding usage guidelines [RFC7525], Secure RTP [RFC3711], and | RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic | |||
TCPcrypt [RFC8548] which permits opportunistic encryption of the TCP | encryption of the TCP transport payload. Some of these also provide | |||
transport payload. Some of these also provide integrity protection | integrity protection of all or part of the transport header. | |||
of all or part of the transport header. | ||||
This end-to-end transport payload encryption brings many benefits in | This end-to-end transport payload encryption brings many benefits in | |||
terms of providing confidentiality and protecting user privacy. Such | terms of providing confidentiality and protecting user privacy. The | |||
benefits have been widely discussed [RFC7258] [RFC7624]. This | benefits have been widely discussed, for example in [RFC7258] and | |||
document strongly supports and encourages increased use of end-to-end | [RFC7624]. This document strongly supports and encourages increased | |||
payload encryption in transport protocols. The implications of | use of end-to-end payload encryption in transport protocols. The | |||
protecting the transport payload data are therefore not further | implications of protecting the transport payload data are therefore | |||
discussed in this document. | not further discussed in this document. | |||
A further level of protection can be achieved by encrypting the | A further level of protection can be achieved by encrypting the | |||
entire network layer payload, including both the transport layer | entire network layer payload, including both the transport headers | |||
headers and the payload. This method provides confidentiality for | and the payload. This does not expose any transport information to | |||
the entire transport packet. It therefore does not expose any | devices in the network, and therefore also prevents modification | |||
transport information to devices in the network, and prevents | along a network path. An example of encryption at the network layer | |||
modification along a network path. An example of encryption at the | is the IPsec Encapsulating Security Payload (ESP) [RFC4303] in tunnel | |||
network layer is the IPsec Encapsulating Security Payload (ESP) | mode. Virtual Private Networks (VPNs) typically also operate in this | |||
[RFC4303] in tunnel mode. Some Virtual Private Network (VPN) methods | way. This form of encryption is not further discussed in this | |||
also encrypt these headers. This form of encryption is not further | document. | |||
discussed in this 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 their transport layer header information, in | encrypt some, or all, of the transport layer header information, in | |||
addition to the payload. An example of such a protocol, that is | addition to encrypting the payload. An example of such a protocol, | |||
seeing widespread interest and deployment, is the QUIC transport | that is now seeing widespread interest and deployment, is the QUIC | |||
protocol [I-D.ietf-quic-transport]. Encryption and authentication of | transport protocol [I-D.ietf-quic-transport]. The encryption and | |||
the transport header information can prevent unwanted modification of | authentication of transport header information can prevent unwanted | |||
transport headers by middleboxes. It also reduces the amount of | modification of transport headers by middleboxes, reducing the risk | |||
metadata about the progress of the transport connection that is | of protocol ossification. It also reduces the amount of metadata | |||
visible to the network. | about the progress of the transport connection that is visible to the | |||
network. | ||||
As discussed in [RFC7258], Pervasive Monitoring (PM) nis 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". | |||
The following sections further considers some of the costs and | The transport protocols developed for the Internet are used across a | |||
changes to network management and research that are implied by | wide range of paths across network segments with many different | |||
widespread use of transport protocols that encrypt the transport | regulatory, commercial, and engineering considerations. This | |||
header information. It reviews the implications of developing | document considers some of the costs and changes to network | |||
transport protocols that use end-to-end encryption to provide | management and research that are implied by widespread use of | |||
confidentiality of their transport layer headers, and considers the | transport protocols that encrypt their transport header information. | |||
effect of such changes on transport protocol design and network | It reviews the implications of developing transport protocols that | |||
operations. It also considers some anticipated implications on | use end-to-end encryption to provide confidentiality of their | |||
transport and application evolution. That is, it considers the | transport layer headers, and considers the effect of such changes on | |||
issues in designing transport protocols that both protect their | transport protocol design and network operations. It also considers | |||
header information and respect user privacy. | some anticipated implications on transport and application evolution. | |||
This provides considerations relating to the design of transport | ||||
protocols that protect their header information and respect user | ||||
privacy. | ||||
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 over the network-layer service, and are usually 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, using higher-layer protocols | communication between applications, using higher-layer protocols | |||
running on the end systems (transport endpoints). | running on the end systems (transport endpoints). | |||
This simple architectural view hides one of the core functions of the | This simple architectural view does not present one of the core | |||
transport: to discover and adapt to the Internet path that is | functions of an Internet transport: to discover and adapt to the | |||
currently being used. The design of Internet transport protocols is | network path that is currently being used. The design of Internet | |||
as much about trying to avoid the unwanted side effects of congestion | transport protocols is as much about trying to avoid the unwanted | |||
on a flow and other capacity-sharing flows, avoiding congestion | side effects of congestion on a flow and other capacity-sharing | |||
collapse, adapting to changes in the path characteristics, etc., as | flows, avoiding congestion collapse, adapting to changes in the path | |||
it is about end-to-end feature negotiation, flow control, and | characteristics, etc., as it is about end-to-end feature negotiation, | |||
optimising for performance of a specific application. | flow control, and optimising for performance of a specific | |||
application. | ||||
To achieve stable Internet operations, the IETF transport community | Transport headers have end-to-end meaning, but have often been | |||
has to date relied heavily on the results of measurements and the | observed by equipment within the network. Transport protocol | |||
insights of the network operations community to understand the trade- | specifications have not tended to consider this, and have failed to | |||
offs, and to inform selection of appropriate mechanisms to ensure a | indicate what parts of the transport header are intended to be | |||
safe, reliable, and robust Internet (e.g., [RFC1273]). In turn, the | invariant across protocol versions and visible to the network; what | |||
network operator and access provider communities have relied on being | parts of the header can be modified by the network to signal to the | |||
able to understand the pattern and requirements of traffic passing | transport, and in what way; and what parts of the header are private | |||
over the Internet, both in aggregate and at the flow level. The | and/or expected to change in future, and need to be protected for | |||
widespread use of transport header encryption could change this. | privacy or to prevent protocol ossification. | |||
Encryption is expected to form a core part of future transport | Increasing concern about pervasive network monitoring | |||
protocol designs. This can be in the form of encrypted transport | [RFC7258][RFC7624], and growing awareness of the problem of protocol | |||
protocols (i.e., transport protocols that use encryption to provide | ossification caused by middlebox interference with Internet traffic, | |||
confidentiality of some or all of the transport-layer header | has motivated a shift in transport protocol design. Recent transport | |||
information), and/or the encryption of transport payloads (i.e., | protocols, such as QUIC [I-D.ietf-quic-transport], encrypt the | |||
confidentiality of the payload data). There are many motivations for | majority of their transport headers to prevent observation and | |||
deploying such transports. Increasing public concerns about | protect against modification by the network, and to make explicit | |||
interference with Internet traffic [RFC7624] have led to a rapidly | their invariants and what is intended to be visible to the network. | |||
expanding deployment of encrypted transport protocols such as QUIC | ||||
[I-D.ietf-quic-transport]. | ||||
Using encryption to provide confidentiality of the transport layer | Transport header encryption is expected to form a core part of future | |||
therefore brings some well-known privacy and security benefits. | transport protocol designs. It can help to protect against pervasive | |||
monitoring, improve privacy, and reduce protocol ossification. | ||||
Transport protocols that use header encryption with secure key | ||||
distribution can provide confidentiality and protection for some, or | ||||
all, of the transport header information, controlling what is visible | ||||
to, and can be modified by, the network. | ||||
The increased use of transport header encryption has benefits, but | ||||
also has implications for the broader ecosystem. The transport | ||||
community has, to date, relied heavily on measurements and insights | ||||
from the network operations community to understand protocol | ||||
behaviour, and to inform the selection of appropriate mechanisms to | ||||
ensure a safe, reliable, and robust Internet. In turn, network | ||||
operators and access providers have relied upon being able to observe | ||||
traffic patterns and requirements, both in aggregate and at the flow | ||||
level, to help understand and optimise the behaviour of their | ||||
networks. Widespread use of transport header encryption could limit | ||||
such observations in future. It is important to understand how | ||||
transport 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. These | transport headers of packets passing through their network. | |||
devices can rely on the presence and semantics of specific header | ||||
information, which leads to ossification where an endpoint has to | When network devices rely on the presence of a header field or the | |||
supply a specific header to receive the network service that it | semantics of specific header information, this can lead to | |||
desires. | ossification where an endpoint has to supply a specific header to | |||
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). However, in other cases, | |||
ossification can frustrate the evolution of the transport protocol. | this can have unwanted outcomes, e.g., privacy impacts and | |||
A mechanism implemented in a network device, such as a firewall, that | ossification. | |||
Ossification can frustrate the evolution of a transport protocol. A | ||||
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 | |||
(i.e., that regards the field as invariant) can prevent the device | can prevent the device from forwarding packets using a different | |||
from forwarding packets using a different version of a protocol that | version of the protocol that introduces a feature that changes to a | |||
introduces a feature that changes the value of the observed field. | new value for the observed field. | |||
An example of such ossification was observed in the development of | An example of ossification was observed in the development of | |||
Transport Layer Security (TLS) 1.3 [RFC8446]. This necessitated a | Transport Layer Security (TLS) 1.3 [RFC8446], where the design needed | |||
design that recognised that deployed middleboxes relied on the | to function in the presence of deployed middleboxes that relied on | |||
presence of certain header fields exposed in TLS 1.2, and failed if | the presence of certain header fields exposed in TLS 1.2. | |||
those headers were changed. | ||||
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 reset connections when the window | advertised in the TCP header and then reset connections when the | |||
does not grow as expected. Similarly, Issues have been reported with | window did not grow as expected. Similarly, issues have been | |||
TCP Fast Open using middleboxes that modify the transport header of | reported using TCP. For example, TCP Fast Open can experience | |||
packets by removing unknown TCP options, that drop segments with | middleboxes that modify the transport header of packets by removing | |||
unknown TCP options, drop segments that contain data and have the SYN | "unknown" TCP options, segments with unrecognised TCP options can be | |||
bit set, drop packets with SYN/ACK that acknowledge data, or that | dropped, segments that contain data and set the SYN bit can be | |||
disrupt connections that send data before the three-way handshake | dropped, or middleboxes that disrupt connections which send data | |||
completes. Other examples of ossification have included middleboxes | before completion of the three-way handshake. Other examples of | |||
that rewrite TCP sequence and acknowledgement numbers, but are | ossification have included middleboxes that rewrite TCP sequence and | |||
unaware of the (newer) TCP selective acknowledgement (SACK) Option | acknowledgement numbers, but are unaware of the (newer) TCP selective | |||
and therefore fail to correctly rewrite the selective acknowledgement | acknowledgement (SACK) Option and therefore fail to correctly rewrite | |||
header information to match the changes that were made to the fixed | the selective acknowledgement header information to match the changes | |||
TCP header. | that were made to the fixed TCP header, preventing SACK from | |||
operating correctly. | ||||
In all these cases, the issue was caused by middleboxes that had a | In all these cases, middleboxes with a hard-coded understanding of | |||
hard-coded understanding of transport behaviour, and that interacted | transport behaviour, interacted poorly with transport protocols after | |||
poorly with transport protocols when the transport behaviour changed. | the transport behaviour was changed. | |||
Many protocol specifications had also failed to clearly indicate the | ||||
invariant parts of the transport header and were designed without | ||||
thought for how header information could be used within the network. | ||||
Transport header encryption can help reduce such ossification of the | In contrast, transport header encryption prevents an on-path device | |||
transport layer. A protocol design that uses header encryption with | from observing the transport headers, and therefore stops mechanisms | |||
secure key distribution can provide confidentiality for some, or all, | being built that directly rely on or infer semantics of the transport | |||
of the protocol header information. This prevents an on-path device | header information. Encryption is normally combined with | |||
from observing the transport headers, and stops mechanisms being | authentication of the protected information. RFC 8546 summarises | |||
built that directly rely on transport header information, or that | this approach, stating that it is "The wire image, not the protocol's | |||
seek to infer semantics of exposed header fields. This encryption is | specification, determines how third parties on the network paths | |||
normally combined with authentication of the protected information. | among protocol participants will interact with that protocol" | |||
RFC 8546 summarises this, stating that it is "The wire image, not the | ||||
protocol's specification, determines how third parties on the network | ||||
paths among protocol participants will interact with that protocol" | ||||
[RFC8546]. | [RFC8546]. | |||
While encryption can hide transport header information and therefore | While encryption can reduce ossification of the transport protocol, | |||
help to reduce ossification of the transport protocol, it does not | it does not itself prevent ossification of the network service. | |||
prevent ossification of the network service. People seeking to | People seeking to understand network traffic could still come to rely | |||
understand network traffic could come to rely on pattern inferences | on pattern inferences and other heuristics or machine learning to | |||
and other heuristics as the basis for network decision and to derive | derive measurement data and as the basis for network forwarding | |||
measurement data. This can create new dependencies on the transport | decisions. This can also create dependencies on the transport | |||
protocol, or the patterns of traffic it can generate. This use of | protocol, or the patterns of traffic it can generate. | |||
machine-learning methods usually demands large data sets, presenting | ||||
it own requirements for collecting and distributing the data. | ||||
2.2. Authentication of Transport Header Information | 2.2. Authentication of Transport Header Information | |||
The design of a transport protocol needs to determine whether to | The designers of a transport protocol decide whether to encrypt all, | |||
encrypt all or a part of the transport information. It is possible | or a part of, the transport header information. Section 4 of RFC8558 | |||
that on-path devices could develop mechanisms that rely on the | states: "Anything exposed to the path should be done with the intent | |||
presence of any non-encrypted field, or a known value in the field. | that it be used by the network elements on the path" [RFC8558]. New | |||
Section 4 of RFC8558 goes further, to state: "Anything exposed to the | protocol designs can decide not to encrypt certain transport header | |||
path should be done with the intent that it be used by the network | fields, making those fields observable in the network. Where fields | |||
elements on the path" [RFC8558]. In this context, specification of a | are intended to immutable (i.e., observable but not modifiable by the | |||
non-encrypted transport header field explicitly allows protocol | network), the endpoints are encouraged to use authentication to | |||
designers to make the certain header information observable by the | provide a cryptographic integrity check that includes these immutable | |||
network. This supports use of this information by on-path devices, | fields to detect any manipulation by network devices. | |||
but at the same time this can lead to ossification of the exposed | ||||
part of a transport header. That is, network forwarding could evolve | ||||
to depend on the presence and/or value of these fields (even if the | ||||
header is not modified by the in-network device). | ||||
New protocol designs will make use of authentication to provide a | ||||
cryptographic integrity check for the transport header fields. | ||||
Transport header information that is authenticated, but not | ||||
encrypted, permits inspection of the non-encrypted header fields by | ||||
devices on the path, but does prevent undetected manipulation by | ||||
network devices. | ||||
Sometimes a protocol design employs a header field that is not | Making part of a transport header observable can lead to ossification | |||
encrypted, but it is desired to avoid unwanted inspection restricting | of that part of a header, as middleboxes come to rely on observations | |||
the choice of usable values in the field (and the resulting potential | of the exposed fields. A protocol design that provides an observable | |||
for undesirable ossification). In this case, the protocol designers | field might want to avoid inspection restricting the choice of usable | |||
can choose to intentionally vary the format and/or value of exposed | values in the field by intentionally varying the format and/or value | |||
header fields to reduce the chance of ossification (see Section 4 and | of the field to reduce the chance of ossification (see Section 4). | |||
[I-D.ietf-tls-grease]). | ||||
2.3. Observable Transport Header Fields | 2.3. Observable Transport Header Fields | |||
Transport headers have end-to-end meaning, but are often observed by | Transport headers fields have been observed within the network for a | |||
equipment within the network. The decision about which transport | variety of purposes. Some of these are related to network management | |||
headers fields are made observable offers trade-offs around header | and operations. The lists below, and in the following section, seek | |||
confidentiality versus header observability (including non-encrypted | to identify some of these uses and the implications of the increased | |||
but authenticated header fields) for network operations and | use of transport header encryption. This analysis does not judge | |||
management, and the implications for ossification and user privacy. | whether specific practises are necessary, or endorse the use of any | |||
The impact differs depending on the activity, as discussed below and | specific approach. | |||
developed in the remainder of this document: | ||||
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 or a specific network | equipment/configurations, to a specific network | |||
segment. | segment, or sometimes to a specific protocol or | |||
application. | ||||
Concealing transport header information makes | When transport header information is not | |||
performance/behaviour unavailable to passive | observable, it cannot be used by network | |||
observers along the path. Operators will then be | operators. Operators might work without that | |||
unable to use this information directly and could | information, or they might turn to more ambitious | |||
turn to more ambitious ways to collect, estimate, | ways to collect, estimate, or infer this data. | |||
or infer that data. (Operational practices aimed | (Operational practises aimed at guessing | |||
at guessing transport parameters are out of scope | transport parameters are out of scope for this | |||
for this document, and are only mentioned here to | 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 practices 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 Sections 3, 5, and 6.4. | |||
Traffic Analysis: Observable transport headers can be used to | Traffic Analysis: Observable transport headers have been used to | |||
determine which transport protocols and features | determine which transport protocols and features | |||
are being used across a network segment, and to | are being used across a network segment, and to | |||
measure trends in the pattern of usage. For some | measure trends in the pattern of usage. For some | |||
use cases, end-to-end measurements/traces are | use cases, end-to-end measurements/traces are | |||
sufficient and can assist in developing and | sufficient and can assist in developing and | |||
debugging new transports and analysing their | debugging new transports and analysing their | |||
deployment. In other uses, it is important to | deployment. In other uses, it is important to | |||
relate observations to specific equipment/ | relate observations to specific equipment/ | |||
configurations or particular network segments. | configurations or particular network segments. | |||
Concealing transport header information can make | This information can help anticipate the demand | |||
analysis harder or impossible. This could impact | for network upgrades and roll-out, or affect on- | |||
the ability to anticipate the need for network | going traffic engineering activities performed by | |||
upgrades and roll-out, or affect on-going traffic | operators such as determining which parts of the | |||
engineering activities performed by operators | path contribute delay, jitter, or loss. | |||
such as determining which parts of the path | ||||
contribute delay, jitter, or loss. While this | Tools that rely upon observing headers, could | |||
impact could, in many cases, be small, there are | fail to produce useful data when those headers | |||
scenarios where operators will actively monitor | are encrypted. While this impact could, in many | |||
and support particular services, e.g., to explore | cases, be small, there are scenarios where | |||
issues relating to Quality of Service (QoS), to | operators have actively monitored and supported | |||
perform fast re-routing of critical traffic, to | particular services, e.g., to explore issues | |||
mitigate the characteristics of specific radio | relating to Quality of Service (QoS), to perform | |||
links, and so on. | fast re-routing of critical traffic, to mitigate | |||
the characteristics of specific radio links, and | ||||
so on. | ||||
See also Sections 3.1-3.2, and 5. | See also Sections 3.1-3.2, and 5. | |||
Troubleshooting: Observable transport headers can be utilised by | Troubleshooting: Observable transport headers have been utilised | |||
operators for network troubleshooting and | by operators as a part of network troubleshooting | |||
diagnostics. Effective troubleshooting often | and diagnostics. Metrics can help localise the | |||
requires visibility into the transport layer | network segment introducing the loss or latency. | |||
behaviour. Flows experiencing packet loss or | Effective troubleshooting often requires | |||
jitter are hard to distinguish from unaffected | understanding of transport behaviour. Flows | |||
flows when only observing network layer headers. | experiencing packet loss or jitter are hard to | |||
distinguish from unaffected flows when only | ||||
observing network layer headers. | ||||
Concealing transport header information reduces | Observable transport feedback information (e.g., | |||
the incentive for operators to troubleshoot, | RTP Control Protocol (RTCP) reception reports | |||
since they cannot interpret the data. This can | [RFC3550]) can explicitly make loss metrics | |||
limit understanding of transport dynamics, such | visible to operators. Loss metrics can also be | |||
as the impact of packet loss or latency on the | deduced with more complexity from other header | |||
flows, or make it harder to localise the network | information (e.g., by observing TCP SACK blocks). | |||
segment introducing the packet loss or latency. | When the transport header information is | |||
Additional mechanisms will be needed to help | encrypted, explicit observable fields could also | |||
reconstruct or replace transport-level metrics | be made available at the network or transport | |||
for troubleshooting and diagnostics. These can | layers to provide these functions. | |||
add complexity and operational costs (e.g., in | ||||
deploying additional functions in equipment or | ||||
adding traffic overhead). | ||||
See also Section 3.3 and 5. | See also Section 3.3 and 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. An | or distributed denial of service attacks. | |||
operator needs to uniquely disambiguate unwanted | Operators often seek to uniquely disambiguate | |||
traffic. | unwanted traffic. | |||
Concealing transport header information would | Where flows cannot be disambiguated based on | |||
prevent disambiguation based on transport | transport information, this could result in less- | |||
information. This could result in less-efficient | efficient identification of unwanted traffic, the | |||
identification of unwanted traffic, the use of | ||||
heuristics to identify anomalous flows, or the | ||||
introduction of rate limits for uncharacterised | introduction of rate limits for uncharacterised | |||
traffic. | traffic, or the use of heuristics to identify | |||
anomalous flows. | ||||
See also Sections 6.2 and 6.3. | See also Sections 6.2 and 6.3. | |||
Verifiable Data: Observable transport headers can provide open and | ||||
verifiable measurements to support operations, | ||||
research, and protocol development. The ability | ||||
of multiple stake holders to review transport | ||||
header traces helps develop insight into | ||||
performance and traffic contribution of specific | ||||
variants of a protocol. Independently observed | ||||
data is important to help ensure the health of | ||||
the research and development communities. | ||||
When transport header information can not be | ||||
observed, this can reduce the range of actors | ||||
that can observe data. This limits the | ||||
information sources available to the Internet | ||||
community to understand the operation of new | ||||
transport protocols, reducing information to | ||||
inform design decisions and standardisation of | ||||
the new protocols and related operational | ||||
practises | ||||
See also Section 6. | ||||
SLA Compliance: Observable transport headers coupled with | SLA Compliance: Observable transport headers coupled with | |||
published transport specifications allow | published transport specifications allow | |||
operators and regulators to explore teh | operators and regulators to explore the | |||
compliance with Service Level Agreements (SLAs). | compliance with Service Level Agreements (SLAs). | |||
Independently verifiable performance metrics can | ||||
also be utilised to demonstrate regulatory | ||||
compliance in some jurisdictions, and as a basis | ||||
for informing design decisions. This can bring | ||||
assurance to those operating networks, often | ||||
avoiding the need to deploy complex techniques | ||||
that routinely monitor and manage Internet | ||||
traffic flows (e.g., avoiding the capital and | ||||
operational costs of deploying flow rate-limiting | ||||
and network circuit-breaker methods [RFC8084]). | ||||
When transport header information is concealed, | When transport header information can not be | |||
it is not possible to observe transport header | observed, other methods have to be found to | |||
information. Methods are still needed to confirm | confirm that the traffic produced conforms to the | |||
that the traffic produced conforms to the | ||||
expectations of the operator or developer. | expectations of the operator or developer. | |||
See also Sections 5 and 6.1-6.3. | Independently verifiable performance metrics can | |||
be utilised to demonstrate regulatory compliance | ||||
Verifiable Data: Observable transport headers can provide open and | in some jurisdictions, and as a basis for | |||
verifiable measurements to support operations, | informing design decisions. This can bring | |||
research, and protocol development. The ability | assurance to those operating networks, often | |||
of other stake holders to review transport header | avoiding deployment of complex techniques that | |||
traces helps develop insight into performance and | routinely monitor and manage Internet traffic | |||
traffic contribution of specific variants of a | flows (e.g., avoiding the capital and operational | |||
protocol. Independently observed data is | costs of deploying flow rate-limiting and network | |||
important to help ensure the health of the | circuit-breaker methods [RFC8084]). | |||
research and development communities. | ||||
Concealing transport header information can | ||||
reduce the range of actors that can observe | ||||
useful data. This limits the information sources | ||||
available to the Internet community to understand | ||||
the operation of new transport protocols, | ||||
reducing information to inform design decisions | ||||
and standardisation of the new protocols and | ||||
related operational practices | ||||
See also Section 6. | See also Sections 5 and 6.1-6.3. | |||
There are architectural challenges and considerations in the way | Note, again, that this lists uses that have been made of transport | |||
transport protocols are designed, and the ability to characterise and | header information, and does not necessarily endorse any particular | |||
compare different transport solutions [Measure]. Different parties | approach. | |||
will view the relative importance of these differently. For some, | ||||
the benefits of encrypting the transport headers could outweigh the | ||||
impact of doing so; others might make a different trade-off. | ||||
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. To understand the | the trade-offs discussed in Section 2.3. | |||
implications, it is necessary to understand how transport layer | ||||
headers are currently observed and/or modified by middleboxes within | ||||
the network. | ||||
This section reviews some current usage. This review does not | There are architectural challenges and considerations in the way | |||
consider the intentional modification of transport headers by | transport protocols are designed, and the ability to characterise and | |||
middleboxes (such as in Network Address Translation, NAT, or | compare different transport solutions [Measure]. The decision about | |||
Firewalls). Common issues concerning IP address sharing are | which transport headers fields are made observable offers trade-offs | |||
described in [RFC6269]. | around header confidentiality versus header observability (including | |||
non-encrypted but authenticated header fields) for network operations | ||||
and management, and the implications for ossification and user | ||||
privacy. Different parties will view the relative importance of | ||||
these differently. For some, the benefits of encrypting all | ||||
transport headers outweigh the impact of doing so; others might | ||||
analyse the security, privacy and ossification impacts and arrive at | ||||
a different trade-off. | ||||
3.1. Observing Transport Information in the Network | To understand the implications, it is necessary to understand how | |||
transport layer headers are currently observed and/or modified by | ||||
middleboxes within the network. This section therefore reviews | ||||
examples of current usage. It does not consider the intentional | ||||
modification of transport headers by middleboxes (such as in Network | ||||
Address Translation, NAT, or Firewalls). Common issues concerning IP | ||||
address sharing are described in [RFC6269]. | ||||
If in-network observation of transport protocol headers is needed, | 3.1. Observing Transport Information in the Network | |||
this requires knowledge of the format of the transport header: | ||||
o Flows need to be identified at the level needed to perform the | In-network observation of transport protocol headers requires | |||
observation; | knowledge of the format of the transport header: | |||
o The protocol and version of the header need to be visible, e.g., | o Flows have to be identified at the level where observation is | |||
by defining the wire image [RFC8546]. As protocols evolve over | performed. This implies visibility of the protocol and version of | |||
time and there could be a need to introduce new transport headers. | the header, e.g., by defining the wire image [RFC8546]. As | |||
This could require interpretation of protocol version information | protocols evolve over time, new transport headers could be | |||
or connection setup information; | introduced. Detecting this could require interpretation of | |||
protocol version information or connection setup information; | ||||
o The location and syntax of any observed transport headers need to | o Observing transport information depends on knowing the location | |||
be known. IETF transport protocols can specify this information. | and syntax of the observed transport headers. 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 Using Transport Layer Headers | 3.1.1. Flow Identification Using Transport Layer Headers | |||
Flow/Session identification [RFC8558] is a common function. For | Flow/Session identification [RFC8558] is a common function. For | |||
example, performed by measurement activities, QoS classification, | example, performed by measurement activities, QoS classification, | |||
firewalls, Denial of Service, DOS, prevention. | firewalls, Denial of Service, DOS, prevention. | |||
Observable transport header information, together with information in | Observable transport header information, together with information in | |||
the network header, has been used to identify flows and their | the network header, has been used to identify flows and their | |||
connection state, together with the protocol options being used. | connection state, together with the set of protocol options being | |||
Transport protocols, such as TCP and the Stream Control Transport | used. Transport protocols, such as TCP and the Stream Control | |||
Protocol (SCTP), specify a standard base header that includes | Transport Protocol (SCTP), specify a standard base header that | |||
sequence number information and other data. They also have the | includes sequence number information and other data. They also have | |||
possibility to negotiate additional headers at connection setup, | the possibility to negotiate additional headers at connection setup, | |||
identified by an option number in the transport header. | identified by an option number in the transport header. | |||
In some uses, a low-numbered (well-known) transport port number can | In some uses, a low-numbered (well-known) transport port number can | |||
identify the protocol. However, port information alone is not | identify the protocol. However, port information alone is not | |||
sufficient to guarantee identification when 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 | |||
instead be identified by observing signalling protocol data (e.g., | be identified by observing signalling protocol data (e.g., [RFC3261], | |||
[RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic | [I-D.ietf-rtcweb-overview]) or through the use of magic numbers | |||
numbers placed in the first byte(s) of the datagram payload | placed in the first byte(s) of the datagram payload [RFC7983]. | |||
[RFC7983]. | ||||
Concealing transport header information can remove information used | When transport header information can not be observed, this removes | |||
to classify flows by passive observers along the path, so operators | information that could be used to classify flows by passive observers | |||
will be unable to use this information directly. Operators could | along the path. More ambitious ways could be used to collect, | |||
turn to more ambitious ways to collect, estimate, or infer that data, | estimate, or infer flow information, including heuristics based on | |||
including heuristics based on the analysis of traffic patterns. For | the analysis of traffic patterns. For example, an operator that | |||
example, an operator that cannot access the Session Description | cannot access the Session Description Protocol (SDP) session | |||
Protocol (SDP) session descriptions to classify a flow as audio | descriptions to classify a flow as audio traffic, might instead use | |||
traffic, might instead use (possibly less-reliable) heuristics to | (possibly less-reliable) heuristics to infer that short UDP packets | |||
infer that short UDP packets with regular spacing carry audio | with regular spacing carry audio traffic. Operational practises | |||
traffic. Operational practices aimed at inferring transport | aimed at inferring transport parameters are out of scope for this | |||
parameters are out of scope for this document, and are only mentioned | document, and are only mentioned here to recognize that encryption | |||
here to recognize that encryption does not prevent operators from | does not prevent operators from attempting to apply practises that | |||
attempting to apply practices that were used with unencrypted | were used with unencrypted transport headers. | |||
transport headers. | ||||
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: Protocol sequence number and packet size | |||
can be used to derive volume measures per-application, to | could be used to derive volume measures per-application, to | |||
characterise the traffic that uses a network segment or the | characterise the traffic that uses a network segment or the | |||
pattern of network usage. Measurements can be per endpoint or for | pattern of network usage. Measurements can be per endpoint or for | |||
an endpoint aggregate (e.g., to assess subscriber usage). | an endpoint aggregate (e.g., to assess subscriber usage). | |||
Measurments can also be used to trigger traffic shaping, and to | Measurements can also be used to trigger traffic shaping, and to | |||
associate QoS support within the network and lower layers. Volume | associate QoS support within the network and lower layers. Volume | |||
measures can also be valuable for capacity planning and providing | measures can also be valuable for capacity planning and providing | |||
detail of trends in usage. | 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) and has been used as a metric for | from transport sequence numbers or inferred from observing | |||
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. | |||
There are various causes of loss, including: corruption of link | There are various causes of loss, including: corruption of link | |||
frames (e.g., due to interference on a radio link), buffering loss | frames (e.g., due to interference on a radio link), buffering loss | |||
(e.g., overflow due to congestion, Active Queue Management, AQM | (e.g., overflow due to congestion, Active Queue Management, AQM | |||
[RFC7567], or inadequate provision following traffic pre-emption), | [RFC7567], or inadequate provision following traffic pre-emption), | |||
and policing (traffic management). Understanding flow loss rates | and policing (traffic management). Understanding flow loss rates | |||
requires either observing sequence numbers in transport headers, | requires either observing sequence numbers in network or transport | |||
or maintaining per-flow packet counters (flow identification often | headers, or maintaining per-flow packet counters (flow | |||
requires transport header information). Per-hop loss can also | identification often requires transport header information). Per- | |||
sometimes be monitored at the interface level by devices in the | hop loss can also sometimes be monitored at the interface level by | |||
network. It is often valuable to understand the conditions under | devices in the network. | |||
which packet loss occurs, which usually requires relating loss to | ||||
the traffic flowing on the network node/segment at the time of | ||||
loss. | ||||
Observation of transport feedback information (e.g., RTP Control | Losses can often occur as bursts, randomly-timed events, etc. The | |||
Protocol (RTCP) reception reports [RFC3550], TCP SACK blocks) can | pattern of loss can provide insight into the cause of loss. It | |||
increase understanding of the impact of loss and help identify | can also be valuable to understand the conditions under which loss | |||
cases where loss could have been wrongly identified, or where the | occurs, which usually requires relating loss to the traffic | |||
transport did not require transmission of the lost packet. It is | flowing on the network node/segment at the time of loss. This can | |||
sometimes more helpful to understand the pattern of loss, than the | also help identify cases where loss could have been wrongly | |||
loss rate, because losses can often occur as bursts, rather than | identified, or where the transport did not require transmission of | |||
randomly-timed events. | a lost packet. | |||
Throughput and Goodput: Throughput is the amount of data sent by a | Throughput and Goodput: Throughput is the amount of payload data | |||
flow per time interval. Goodput [RFC7928] is a measure of useful | sent by a flow per time interval. Goodput [RFC7928] is a measure | |||
data exchanged (the ratio of useful data to total volume of | of useful data exchanged (the ratio of useful data to total volume | |||
traffic sent by a flow). The throughput of a flow can be | of traffic sent by a flow). The throughput of a flow can be | |||
determined even when transport header information is concealed, | determined in the absence of transport header information, | |||
providing the individual flow can be identified. Goodput requires | providing that the individual flow can be identified, and the | |||
ability to differentiate loss and retransmission of packets, for | overhead known. Goodput requires ability to differentiate loss | |||
example by observing packet sequence numbers in the TCP or the | and retransmission of packets, for example by observing packet | |||
Real-time Transport Protocol (RTP) headers [RFC3550]. | sequence numbers in the TCP or the Real-time Transport Protocol | |||
(RTP) headers [RFC3550]. | ||||
Latency: Latency is a key performance metric that impacts | Latency: Latency is a key performance metric that impacts | |||
application and user-perceived response times. It often | application and user-perceived response times. It often | |||
indirectly impacts throughput and flow completion time. This | indirectly impacts throughput and flow completion time. This | |||
determines the reaction time of the transport protocol itself, | determines the reaction time of the transport protocol itself, | |||
impacting flow setup, congestion control, loss recovery, and other | impacting flow setup, congestion control, loss recovery, and other | |||
transport mechanisms. The observed latency can have many | transport mechanisms. The observed latency can have many | |||
components [Latency]. Of these, unnecessary/unwanted queuing in | components [Latency]. Of these, unnecessary/unwanted queuing in | |||
network buffers has often been observed as a significant factor | network buffers has often been observed as a significant factor | |||
[bufferbloat]. Once the cause of unwanted latency has been | [bufferbloat]. Once the cause of unwanted latency has been | |||
identified, this can often be eliminated. | identified, this can often be eliminated. | |||
To measure latency across a part of a path, an observation point | To measure latency across a part of a path, an observation point | |||
[RFC7799] can measure the experienced round trip time (RTT) using | [RFC7799] can measure the experienced round trip time (RTT) using | |||
packet sequence numbers, and acknowledgements, or by observing | packet sequence numbers and acknowledgements, or by observing | |||
header timestamp information. Such information allows an | header timestamp information. Such information allows an | |||
observation point in the network to determine not only the path | observation point in the network to determine not only the path | |||
RTT, but also allows measurement of the upstream and downstream | RTT, but also allows measurement of the upstream and downstream | |||
contribution to the RTT. This could be used to locate a source of | contribution to the RTT. This could be used to locate a source of | |||
latency, e.g., by observing cases where the median RTT is much | latency, e.g., by observing cases where the median RTT is much | |||
greater than the minimum RTT for a part of a path. | greater than the minimum RTT for a part of a path. | |||
The service offered by network operators can benefit from latency | The service offered by network operators can benefit from latency | |||
information to understand the impact of configuration changes and | information to understand the impact of configuration changes and | |||
to tune deployed services. Latency metrics are key to evaluating | to tune deployed services. Latency metrics are key to evaluating | |||
skipping to change at page 14, line 23 ¶ | skipping to change at page 14, line 36 ¶ | |||
[RFC8290] and although parameter-less methods are desired | [RFC8290] and although parameter-less methods are desired | |||
[RFC7567], current methods often require tuning [RFC8290] | [RFC7567], current methods often require tuning [RFC8290] | |||
[RFC8289] [RFC8033] because they cannot scale across all possible | [RFC8289] [RFC8033] because they cannot scale across all possible | |||
deployment scenarios. | deployment scenarios. | |||
Variation in delay: Some network applications are sensitive to | Variation in delay: Some network applications are sensitive to | |||
(small) changes in packet timing (jitter). Short and long-term | (small) changes in packet timing (jitter). Short and long-term | |||
delay variation can impact on the latency of a flow and hence the | delay variation can impact on the latency of a flow and hence the | |||
perceived quality of applications using the network. For example, | perceived quality of applications using the network. For example, | |||
jitter metrics are often cited when characterising paths | jitter metrics are often cited when characterising paths | |||
supporting real-time traffic. To assess the performance of such | supporting real-time traffic. The expected performance of such | |||
applications, it can be necessary to measure the variation in | applications, can be inferred from a measure the variation in | |||
delay observed along a portion of the path [RFC3393] [RFC5481]. | delay observed along a portion of the path [RFC3393] [RFC5481]. | |||
The requirements for observable transport headers resemble those | The requirements resemble those for the measurement of latency. | |||
for the measurement of latency. | ||||
Flow Reordering: Significant packet reordering within a flow can | Flow Reordering: Significant packet reordering within a flow can | |||
impact time-critical applications and can be interpreted as loss | impact time-critical applications and can be interpreted as loss | |||
by reliable transports. Many transport protocol techniques are | by reliable transports. Many transport protocol techniques are | |||
impacted by reordering (e.g., triggering TCP retransmission or re- | impacted by reordering (e.g., triggering TCP retransmission or re- | |||
buffering of real-time applications). Packet reordering can occur | buffering of real-time applications). Packet reordering can occur | |||
for many reasons, from equipment design to misconfiguration of | for many reasons, from equipment design to misconfiguration of | |||
forwarding rules. Since this impacts transport performance, | forwarding rules. Network tools can detect and measure unwanted/ | |||
network tools are needed to detect and measure unwanted/excessive | excessive reordering, and the impact on transport performance. | |||
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 potential to simplify network equipment design as well as the | have potential to simplify network equipment design as well as the | |||
potential to improve robustness of the transport service. | potential to improve robustness of the transport service. | |||
Measurements of reordering can help understand the present level | Measurements of reordering can help understand the present level | |||
of reordering 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 | |||
skipping to change at page 15, line 14 ¶ | skipping to change at page 15, line 22 ¶ | |||
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] | maintained packet order on a packet-by-packet basis [RFC4737] | |||
[RFC5236]. | [RFC5236]. | |||
Techniques for measuring reordering typically observe packet | Techniques for measuring reordering typically observe packet | |||
sequence numbers. Some protocols provide in-built monitoring and | sequence numbers. Some protocols provide in-built monitoring and | |||
reporting functions. Transport fields in the RTP header [RFC3550] | reporting functions. Transport fields in the RTP header [RFC3550] | |||
[RFC4585] can be observed to derive traffic volume measurements | [RFC4585] can be observed to derive traffic volume measurements | |||
and provide information on the progress and quality of a session | and provide information on the progress and quality of a session | |||
using RTP. As with other measurement, metadata is often needed to | using RTP. As with other measurement, metadata assist in | |||
understand the context under which the data was collected, | understanding the context under which the data was collected, | |||
including the time, observation point [RFC7799], and way in which | including the time, observation point [RFC7799], and way in which | |||
metrics were accumulated. The RTCP protocol directly reports some | metrics were accumulated. The RTCP protocol directly reports some | |||
of this information in a form that can be directly visible in the | of this information in a form that can be directly visible in the | |||
network. A user of summary measurement data needs to trust the | network. A user of summary measurement data has to trust the | |||
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. | |||
This information can support network operations, inform capacity | These metrics can support network operations, inform capacity | |||
planning, and assist in determining the need for equipment and/or | planning, and assist in determining the demand for equipment and/or | |||
configuration changes by network operators. It 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 | ||||
traffic to perform a measurement (see section 3.4 of [RFC7799]). | ||||
However, most operators do not have access to user equipment, | ||||
therefore the point of test is normally different from the transport | ||||
endpoint. Injection of test traffic can incur an additional cost in | ||||
running such tests (e.g., the implications of capacity tests in a | ||||
mobile network are obvious). Some active measurements [RFC7799] | ||||
(e.g., response under load or particular workloads) perturb other | ||||
traffic, and could require dedicated access to the network segment. | ||||
Passive measurements (see section 3.6 of [RFC7799]) can have | ||||
advantages in terms of eliminating unproductive test traffic, | ||||
reducing the influence of test traffic on the overall traffic mix, | ||||
and the ability to choose the point of observation (see | ||||
Section 3.2.1). Measurements can rely on observing packet headers, | ||||
which is not possible if those headers are encrypted, but could | ||||
utilise information about traffic volumes or patterns of interaction | ||||
to deduce metrics. | ||||
An alternative approach is to use in-network techniques add and | ||||
observe packet headers to facilitate measurements while traffic | ||||
traverses an operational network. This approach does not require the | ||||
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 can be 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 will typically receive 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 can | addition to the exposed transport information [RFC8558]. This | |||
provide information to enable a different forwarding treatment by the | information can enable a different forwarding treatment by the | |||
network, even when a transport employs encryption to protect other | network, even when a transport employs encryption to protect other | |||
header information. | header information. | |||
The user of a transport that multiplexes multiple sub-flows might | The user of a transport that multiplexes multiple sub-flows might | |||
want to hide the presence and characteristics of these sub-flows. On | want to obscure the presence and characteristics of these sub-flows. | |||
the other hand, an encrypted transport could set the network-layer | On the other hand, an encrypted transport could set the network-layer | |||
information to indicate the presence of sub-flows, and to reflect the | information to indicate the presence of sub-flows, and to reflect the | |||
network needs of individual sub-flows. There are several ways this | service requirements of individual sub-flows. There are several ways | |||
could be done: | this could be done: | |||
IP Address: Applications normally expose the addresses used by | IP Address: Applications normally expose the addresses used by | |||
endpoints, and this is used in the forwarding decisions in network | endpoints, and this is used in the forwarding decisions in network | |||
devices. Address and other protocol information can be used by a | devices. Address and other protocol information can be used by a | |||
Multi-Field (MF) classifier to determine how traffic is treated | Multi-Field (MF) classifier to determine how traffic is treated | |||
[RFC2475], and hence the quality of experience for a flow. | [RFC2475], and hence the quality of experience for a flow. | |||
Using the IPv6 Network-Layer Flow Label: A number of Standards Track | Using the IPv6 Network-Layer Flow Label: A number of Standards Track | |||
and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], | and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], | |||
[RFC6438]) encourage endpoints to set the IPv6 Flow label field of | [RFC6438]) encourage endpoints to set the IPv6 Flow label field of | |||
the network-layer header. IPv6 "source nodes SHOULD assign each | the network-layer header. IPv6 "source nodes SHOULD assign each | |||
unrelated transport connection and application data stream to a | unrelated transport connection and application data stream to a | |||
new flow" [RFC6437]. A multiplexing transport could choose to use | new flow" [RFC6437]. A multiplexing transport could choose to use | |||
multiple Flow labels to allow the network to independently forward | multiple Flow labels to allow the network to independently forward | |||
subflows. RFC6437 provides further guidance on choosing a flow | sub-flows. RFC6437 provides further guidance on choosing a flow | |||
label value, stating these "should be chosen such that their bits | label value, stating these "should be chosen such that their bits | |||
exhibit a high degree of variability", and chosen so that "third | exhibit a high degree of variability", and chosen so that "third | |||
parties should be unlikely to be able to guess the next value that | parties should be unlikely to be able to guess the next value that | |||
a source of flow labels will choose". | a source of flow labels will choose". | |||
Once set, a flow label can provide information that can help | Once set, a flow label can provide information that can help | |||
inform network-layer queuing and forwarding [RFC6438], for example | inform network-layer queuing and forwarding [RFC6438], for example | |||
with Equal Cost Multi-Path routing and Link Aggregation [RFC6294]. | with Equal Cost Multi-Path routing and Link Aggregation [RFC6294]. | |||
Considerations when using IPsec are further described in | Considerations when using IPsec are further described in | |||
[RFC6438]. | [RFC6438]. | |||
skipping to change at page 16, line 48 ¶ | skipping to change at page 17, line 33 ¶ | |||
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 | |||
operator inferring traffic requirements from transport and | operator inferring traffic requirements from transport and | |||
application headers via a multi-field classifier. Inappropriate | application headers via a multi-field classifier. Inappropriate | |||
use can have privacy implications (e.g., assigning the same label | use by the transport can have privacy implications (e.g., | |||
to two independent flows that ought not to be classified the | assigning a different DSCP to a subflow could assist in a network | |||
same). Inappropriate use by the transport can have privacy | device discovering the traffic pattern used by an application, | |||
implications (e.g., assigning a different DSCP to a subflow could | assigning the same label to two independent flows that ought not | |||
assist in a network device discovering the traffic pattern used by | to be classified the same). The field is mutable, i.e., some | |||
an application). The field is mutable, i.e., some network devices | network devices can be expected to change this field (use of each | |||
can be expected to change this field (use of each DSCP value is | DSCP value is defined by an RFC). | |||
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 need to consider this | flow, observations of service performance has to consider this | |||
field when a network path has support for 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 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 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 | |||
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 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 are concealed, operators will be unable to use | When transport headers cannot be observed, operators are unable to | |||
this information directly. Careful use of the network layer features | use this information directly. Careful use of the network layer | |||
can help address 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 Section 5 describes use of network extension headers. | Section Section 5 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 conceals 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 | |||
skipping to change at page 18, line 44 ¶ | skipping to change at page 19, line 28 ¶ | |||
common network device, interface port, etc. A simple example is | common network device, interface port, etc. A simple example is | |||
monitoring of a network device that uses a scheduler or active queue | monitoring of a network device that uses a scheduler or active queue | |||
management technique [RFC7567], where it could be desirable to | management technique [RFC7567], where it could be desirable to | |||
understand whether the algorithms are correctly controlling latency, | understand whether the algorithms are correctly controlling latency, | |||
or if overload protection is working. This understanding implies | or if overload protection is working. This understanding implies | |||
knowledge of how traffic is assigned to any sub-queues used for flow | knowledge of how traffic is assigned to any sub-queues used for flow | |||
scheduling, but can also require information about how the traffic | scheduling, but can also require information about how the traffic | |||
dynamics impact active queue management, starvation prevention | dynamics impact active queue management, starvation prevention | |||
mechanisms, and circuit-breakers. | mechanisms, and circuit-breakers. | |||
Sometimes multiple on-path observation points are needed. By | Sometimes multiple on-path observation points have to be used. 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 are used by operators to help plan deployment of | Traffic rate and volume measurements are used by operators to help | |||
new equipment and configuration in their networks. Data is also | plan deployment of new equipment and configuration in their networks. | |||
valuable to equipment vendors who want to understand traffic trends | Data is also valuable to equipment vendors who want to understand | |||
and patterns of usage as inputs to decisions about planning products | traffic trends and patterns of usage as inputs to decisions about | |||
and provisioning for new deployments. This measurement information | planning products and provisioning for new deployments. This | |||
can also be correlated with billing information when this is also | measurement information can also be correlated with billing | |||
collected by an operator. | information when this is also collected by an operator. | |||
A network operator supporting traffic that uses transport header | ||||
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 might be impossible to | endpoint addresses being used, but when transport information is not | |||
correlate patterns in measurements with changes in transport | observable, it might be impossible to correlate patterns in | |||
protocols (e.g., the impact of changes in introducing a new transport | measurements with changes in transport protocols. This increases the | |||
protocol mechanism). This increases the dependency on other indirect | dependency on other indirect sources of information to inform | |||
sources of information to inform planning and provisioning. | planning and provisioning. | |||
3.2.3. Service Performance Measurement | 3.2.3. Service Performance Measurement | |||
Traffic measurements (e.g., traffic volume, loss, latency) can be | Performance measurements (e.g., throughput, loss, latency) can be | |||
used by various actors to help analyse the performance offered to the | used by various actors to analyse the service offered to the users of | |||
users of a network segment, and to inform operational practice. | a network segment, and to inform operational practice. | |||
While active measurements (see section 3.4 of [RFC7799]) could be | ||||
used within a network, passive measurements (see section 3.6 of | ||||
[RFC7799]) can have advantages in terms of eliminating unproductive | ||||
test traffic, reducing the influence of test traffic on the overall | ||||
traffic mix, and the ability to choose the point of observation (see | ||||
Section 3.2.1). Passive measurements can rely on observing transport | ||||
headers, which is not possible if those headers are encrypted, but | ||||
could utilise information about traffic volumes or patterns of | ||||
interaction to deduce metrics. | ||||
3.2.4. Measuring Transport to Support Network Operations | 3.2.4. Measuring Transport to Support Network Operations | |||
Information provided by tools observing transport headers can help | The traffic that can be observed by on-path network devices (the | |||
determine whether mechanisms are needed in the network to prevent | "wire image") is a function of transport protocol design/options, | |||
flows from acquiring excessive network capacity. Operators can | network use, applications, and user characteristics. In general, | |||
implement operational practices to manage traffic flows (e.g., under | when only a small proportion of the traffic has a specific | |||
severe congestion) by deploying rate-limiters, traffic shaping or | (different) characteristic, such traffic seldom leads to operational | |||
network transport circuit breakers [RFC8084]. | concern, although the ability to measure and monitor it is less. The | |||
desire to understand the traffic and protocol interactions typically | ||||
grows as the proportion of traffic increases in volume. The | ||||
challenges increase when multiple instances of an evolving protocol | ||||
contribute to the traffic that share network capacity. | ||||
Operators can manage traffic load (e.g., when the network is severely | ||||
overloaded) by deploying rate-limiters, traffic shaping, or network | ||||
transport circuit breakers [RFC8084]. The information provided by | ||||
observing transport headers is a source of data that can help to | ||||
inform such mechanisms. | ||||
Congestion Control Compliance of Traffic: Congestion control is a | Congestion Control Compliance of Traffic: Congestion control is a | |||
key transport function [RFC2914]. Many network operators | key transport function [RFC2914]. Many network operators | |||
implicitly accept that TCP traffic complies with a behaviour that | implicitly accept that TCP traffic complies with a behaviour that | |||
is acceptable for use in the shared Internet. TCP algorithms have | is acceptable for the shared Internet. TCP algorithms have been | |||
been continuously improved over decades and they have reached a | continuously improved over decades, and have reached a level of | |||
level of efficiency and correctness that custom application-layer | efficiency and correctness that is difficult to match in custom | |||
mechanisms will struggle to easily duplicate [RFC8085]. | application-layer mechanisms [RFC8085]. | |||
A standards-compliant TCP stack provides congestion control that | A standards-compliant TCP stack provides congestion control that | |||
is judged safe for use across the Internet. Applications | is judged safe for use across the Internet. Applications | |||
developed on top of well-designed transports can be expected to | developed on top of well-designed transports can be expected to | |||
appropriately control their network usage, reacting when the | appropriately control their network usage, reacting when the | |||
network experiences congestion, by back-off and reduce the load | network experiences congestion, by back-off and reduce the load | |||
placed on the network. This is the normal expected behaviour for | placed on the network. This is the normal expected behaviour for | |||
IETF-specified transports (e.g., TCP and SCTP). | IETF-specified transports (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 an understanding of the dynamics of a flow and | network can gain an understanding of the dynamics of a flow and | |||
its congestion control behaviour. Analysing observed flows can | its congestion control behaviour. Analysing observed flows can | |||
help to build confidence that an application flow backs-off its | help to build confidence that an application flow backs-off its | |||
share of the network load in the face of persistent congestion, | share of the network load under persistent congestion, and hence | |||
and hence to understand whether the behaviour is appropriate for | to understand whether the behaviour is appropriate for sharing | |||
sharing limited network capacity. For example, it is common to | limited network capacity. For example, it is common to visualise | |||
visualise plots of TCP sequence numbers versus time for a flow to | plots of TCP sequence numbers versus time for a flow to understand | |||
understand how a flow shares available capacity, deduce its | how a flow shares available capacity, deduce its dynamics in | |||
dynamics in response to congestion, etc. | response to congestion, etc. | |||
The ability to identify sources that contribute to persistent | The ability to identify sources that contribute to persistent | |||
congestion is important to the safe operation of network | congestion is important to the safe operation of network | |||
infrastructure, and can inform configuration of network devices to | infrastructure, and can inform configuration of network devices to | |||
complement the endpoint congestion avoidance mechanisms [RFC7567] | complement the endpoint congestion avoidance mechanisms [RFC7567] | |||
[RFC8084] to avoid a portion of the network being driven into | [RFC8084] to avoid a portion of the network being driven into | |||
congestion collapse [RFC2914]. | congestion collapse [RFC2914]. | |||
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 need to | other protocols that choose to use UDP as a transport have to | |||
employ mechanisms to prevent collapse, avoid unacceptable | employ mechanisms to prevent collapse, avoid unacceptable | |||
contributions to jitter/latency, and to establish an acceptable | contributions to jitter/latency, and to establish an acceptable | |||
share of capacity with concurrent traffic [RFC8085]. | share of capacity with concurrent traffic [RFC8085]. | |||
A network operator needs tools to understand if datagram flows | A network operator can observe the headers of transport protocols | |||
(e.g., using UDP) comply with congestion control expectations and | layered above UDP to understand if the datagram flows comply with | |||
therefore whether there is a need to deploy methods such as rate- | congestion control expectations. This can help inform a decision | |||
limiters, transport circuit breakers, or other methods to enforce | on whether it might be appropriate to deploy methods such as rate- | |||
acceptable usage for the offered service. | limiters to enforce acceptable usage. | |||
UDP flows that expose a well-known header by specifying the format | UDP flows that expose a well-known header can be observed to gain | |||
of header fields can allow information to be observed to gain | ||||
understanding of the dynamics of a flow and its congestion control | understanding of the dynamics of a flow and its congestion control | |||
behaviour. For example, tools exist to monitor various aspects of | behaviour. For example, tools exist to monitor various aspects of | |||
RTP and RTCP header information for real-time flows (see | RTP header information and RTCP reports for real-time flows (see | |||
Section 3.1.2). The Secure RTP extensions [RFC3711] were | Section 3.1.2). The Secure RTP and RTCP extensions [RFC3711] were | |||
explicitly designed to expose some header information to enable | explicitly designed to expose some header information to enable | |||
such observation, while protecting the payload data. | such observation, while protecting the payload data. | |||
3.3. Use for Network Diagnostics and Troubleshooting | 3.3. Use for Network Diagnostics and Troubleshooting | |||
Transport header information can be useful for a variety of | Transport header information can be utilised for a variety of | |||
operational tasks [RFC8404]: to diagnose network problems, assess | operational tasks [RFC8404]: to diagnose network problems, assess | |||
network provider performance, evaluate equipment/protocol | network provider performance, evaluate equipment or protocol | |||
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. Section 3.1.2 and Section 5 of [RFC8404] provide further | questions. Section 3.1.2 and Section 5 of [RFC8404] provide further | |||
examples. These tasks seldom involve the need to determine the | examples. | |||
contents of the transport payload, or other application details. The | ||||
use of payload encryption has the desirable effect of preventing | ||||
unintended observation of the user data. | ||||
A network operator supporting traffic that uses transport header | ||||
encryption can see only encrypted transport headers. This prevents | ||||
deployment of performance measurement tools that rely on transport | ||||
protocol information. Choosing to encrypt all the information | ||||
reduces the ability of an operator to observe transport performance | ||||
and could limit the ability of network operators to trace problems, | ||||
make appropriate QoS decisions, or response to other queries about | ||||
the network service. For some this will be blessing, for others it | ||||
might be a curse. For example, operational performance data about | ||||
encrypted flows needs to be determined by traffic pattern analysis, | ||||
rather than relying on traditional tools. This can impact the | ||||
ability of the operator to respond to faults, it could require | ||||
reliance on endpoint diagnostic tools or user involvement in | ||||
diagnosing and troubleshooting unusual use cases or non-trivial | ||||
problems. A key need here is for tools to provide useful information | ||||
during network anomalies (e.g., significant reordering, high or | ||||
intermittent loss). | ||||
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 | ||||
can assist in setting buffer sizes, debugging and diagnosing the root | ||||
causes of faults that concern a particular user's traffic. They can | ||||
also be used to support post-mortem investigation after an anomaly to | ||||
determine the root cause of a problem. | ||||
In some cases, measurements could involve active injection of test | Operators can monitor the health of a portion of the Internet, to | |||
traffic to perform a measurement. However, most operators do not | provide early warning and trigger action. Traffic and performance | |||
have access to user equipment, therefore the point of test is | measurements can assist in setting buffer sizes, debugging and | |||
normally different from the transport endpoint. Injection of test | diagnosing the root causes of faults that concern a particular user's | |||
traffic can incur an additional cost in running such tests (e.g., the | traffic. They can also be used to support post-mortem investigation | |||
implications of capacity tests in a mobile network are obvious). | after an anomaly to determine the root cause of a problem. | |||
Some active measurements [RFC7799] (e.g., response under load or | ||||
particular workloads) perturb other traffic, and could require | ||||
dedicated access to the network segment. An alternative approach is | ||||
to use in-network techniques that observe transport packet headers | ||||
added while traffic traverses an operational network to make the | ||||
measurements. These 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. Observed transport header information can help identify | |||
whether the link/network tuning is effective and alert to potential | whether 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. | |||
different from those of wired networks. A radio-based network (e.g., | ||||
cellular mobile, enterprise WiFi, satellite access/back-haul, point- | ||||
to-point radio) has the complexity of a subsystem that performs radio | ||||
resource management, with direct impact on the available capacity, | ||||
and potentially loss/reordering of packets. The impact of the | ||||
pattern of loss and congestion, differs for different traffic types, | ||||
correlation with propagation and interference can all have | ||||
significant impact on the cost and performance of a provided service. | ||||
The need for this type of information is expected to increase as | ||||
operators bring together heterogeneous types of network equipment and | ||||
seek to deploy opportunistic methods to access radio spectrum. | ||||
A flow that conceals its transport header information could imply | An alternative could rely on access to endpoint diagnostic tools or | |||
"don't touch" to some operators. This could limit a trouble-shooting | user involvement in diagnosing and troubleshooting unusual use cases | |||
response to "can't help, no trouble found". | or to troubleshoot non-trivial problems. | |||
Another approach is to use traffic pattern analysis. Such tools can | ||||
provide useful information during network anomalies (e.g., detecting | ||||
significant reordering, high or intermittent loss), however indirect | ||||
measurements would need to be carefully designed to provide reliable | ||||
signals for diagnostics and troubleshooting. | ||||
The design trade-offs for radio networks are often very different | ||||
from those of wired networks. A radio-based network (e.g., cellular | ||||
mobile, enterprise WiFi, satellite access/back-haul, point-to-point | ||||
radio) has the complexity of a subsystem that performs radio resource | ||||
management, with direct impact on the available capacity, and | ||||
potentially loss/reordering of packets. The impact of the pattern of | ||||
loss and congestion, differs for different traffic types, correlation | ||||
with propagation and interference can all have significant impact on | ||||
the cost and performance of a provided service. For radio links, the | ||||
use for this type of information is expected to increase as operators | ||||
bring together heterogeneous types of network equipment and seek to | ||||
deploy opportunistic methods to access radio spectrum. | ||||
Lack of tools and resulting information can reduce the ability of an | ||||
operator to observe transport performance and could limit the ability | ||||
of network operators to trace problems, make appropriate QoS | ||||
decisions, or respond to other queries about the network service. | ||||
A network operator supporting traffic that uses transport header | ||||
encryption is unable to use tools that rely on transport protocol | ||||
information. However, the use of encryption has the desirable effect | ||||
of preventing unintended observation of the payload data and these | ||||
tools seldom seek to observe the payload, or other application | ||||
details. A flow that hides its transport header information could | ||||
imply "don't touch" to some operators. This might limit a trouble- | ||||
shooting response to "can't help, no trouble found". | ||||
3.4. Header Compression | 3.4. Header Compression | |||
Header compression saves link capacity by compressing network and | Header compression saves link capacity by compressing network and | |||
transport protocol headers on a per-hop basis. It was widely used | transport protocol headers on a per-hop basis. It was widely used | |||
with low bandwidth dial-up access links, and still finds application | with low bandwidth dial-up access links, and still finds application | |||
on wireless links that are subject to capacity constraints. Header | on wireless links that are subject to capacity constraints. Header | |||
compression has been specified for use with TCP/IP and RTP/UDP/IP | compression has been specified for use with TCP/IP and RTP/UDP/IP | |||
flows [RFC2507], [RFC2508], [RFC4995]. | flows [RFC2507], [RFC2508], [RFC4995]. | |||
skipping to change at page 23, line 18 ¶ | skipping to change at page 23, line 34 ¶ | |||
network layer headers, with a significant reduction in efficiency. | network layer headers, with a significant reduction in efficiency. | |||
4. Encryption and Authentication of Transport Headers | 4. Encryption and Authentication of Transport Headers | |||
End-to-end encryption can be applied at various protocol layers. It | End-to-end encryption can be applied at various protocol layers. It | |||
can be applied above the transport to encrypt the transport payload | can be applied above the transport to encrypt the transport payload | |||
(e.g., using TLS). This can hide information from an eavesdropper in | (e.g., using TLS). This can hide information from an eavesdropper in | |||
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 | ||||
There are several motivations for encryption: | There are several motivations for encryption: | |||
o One motive to use encryption is a response to perceptions that the | o One motive to encrypt transport headers is in response to | |||
network has become ossified by over-reliance on middleboxes that | perceptions that the network has become ossified, since traffic | |||
prevent new protocols and mechanisms from being deployed. This | inspecting middleboxes prevent new protocols and mechanisms from | |||
has lead to a perception that there is too much "manipulation" of | being deployed. This has lead to a perception that there is too | |||
protocol headers within the network, and that designing to deploy | much "manipulation" of protocol headers within the network, and | |||
in such networks is preventing transport evolution. In the light | that designing to deploy in such networks is preventing transport | |||
of this, a method that authenticates transport headers could help | evolution. One benefit of encrypting transport headers is that it | |||
improve the pace of transport development, by eliminating the need | can help improve the pace of transport development by eliminating | |||
to always consider deployed middleboxes | interference by deployed middleboxes. | |||
[I-D.trammell-plus-abstract-mech], or potentially to only | ||||
explicitly enable use by middleboxes for particular paths with | ||||
particular middleboxes that are deliberately deployed to realise a | ||||
useful function for the network and/or users[RFC3135]. | ||||
o Another motivation stems from increased concerns about privacy and | o Another motivation stems from increased concerns about privacy and | |||
surveillance. Some Internet users have valued the ability to | surveillance. Users value the ability to protect their identity | |||
protect identity, user location, and defend against traffic | and location, and defend against traffic analysis. Revelations | |||
analysis, and have used methods such as IPsec Encapsulated | about the use of pervasive surveillance [RFC7624] have, to some | |||
Security Payload (ESP), VPNs and other encrypted tunnel | extent, eroded trust in the service offered by network operators | |||
technologies. Revelations about the use of pervasive surveillance | and have led to an increased use of encryption to avoid unwanted | |||
[RFC7624] have, to some extent, eroded trust in the service | eavesdropping on communications. Concerns have also been voiced | |||
offered by network operators, and following the Snowden | about the addition of information to packets by third parties to | |||
revelations in the USA in 2013 has led to an increased desire for | provide analytics, customization, advertising, cross-site tracking | |||
people to employ encryption to avoid unwanted "eavesdropping" on | of users, to bill the customer, or to selectively allow or block | |||
their communications. Concerns have also been voiced about the | content. Whatever the reasons, the IETF is designing protocols | |||
addition of information to packets by third parties to provide | that include transport header encryption (e.g., QUIC | |||
analytics, customization, advertising, cross-site tracking of | ||||
users, to bill the customer, or to selectively allow or block | ||||
content. Whatever the reasons, the IETF is designing new | ||||
protocols that include transport header encryption (e.g., QUIC | ||||
[I-D.ietf-quic-transport]) to supplement the already widespread | [I-D.ietf-quic-transport]) to supplement the already widespread | |||
payload encryption. | payload encryption, and to further limit exposure of transport | |||
metadata to the network. | ||||
o Any header information that has a clear definition in the protocol | ||||
message format(s), or is implied by that definition, and is not | ||||
cryptographically confidentiality-protected can be unambiguously | ||||
interpreted by on-path observers [RFC8546]. | ||||
Encryption methods do not prevent traffic analysis, and usage needs | The use of transport header authentication and encryption exposes a | |||
to reflect that profiling of users, identification of location, and | tussle between middlebox vendors, operators, applications developers | |||
fingerprinting of behaviour can take place even on encrypted traffic | and users: | |||
flows. The use of transport layer authentication and encryption | ||||
exposes a tussle between middlebox vendors, operators, applications | ||||
developers and users: | ||||
o On the one hand, future Internet protocols that enable large-scale | o On the one hand, future Internet protocols that support transport | |||
encryption assist in the restoration of the end-to-end nature of | header encryption assist in the restoration of the end-to-end | |||
the Internet by returning complex processing to the endpoints, | nature of the Internet by returning complex processing to the | |||
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. | ||||
o On the other hand, encryption of transport layer header | o On the other hand, encryption of transport layer header | |||
information has implications for people who are responsible for | information has implications for people who are responsible for | |||
operating networks and researchers and analysts seeking to | operating networks, and researchers and analysts seeking to | |||
understand the dynamics of protocols and traffic patterns. | understand the dynamics of protocols and traffic patterns. | |||
Whatever the motives, a decision to use pervasive transport header | A decision to use transport header encryption can improve user | |||
encryption will have implications on the way in which design and | privacy, and can reduce protocol ossification and help the evolution | |||
evaluation is performed. This can, in turn, impact the direction of | of the transport protocol stack, but is also has implications for | |||
evolution of the transport protocol stack. While the IETF can | network operations and management. | |||
specify protocols, the success in actual deployment is often | ||||
determined by many factors [RFC5218] that are not always clear at the | 4.2. Approaches to Transport Header Protection | |||
time when protocols are being defined. | ||||
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, | |||
skipping to change at page 26, line 6 ¶ | skipping to change at page 26, line 12 ¶ | |||
considers only immutable fields in the transport headers, that is, | considers only immutable fields in the transport headers, that is, | |||
fields that can be authenticated End-to-End across a path. | fields that can be authenticated End-to-End across a path. | |||
An example of a method that encrypts some, but not all, transport | An example of a method that encrypts some, but not all, transport | |||
information is GRE-in-UDP [RFC8086] when used with GRE encryption. | information is GRE-in-UDP [RFC8086] when used with GRE encryption. | |||
Optional Encryption of Header Information: There are implications to | Optional Encryption of Header Information: There are implications to | |||
the use of optional header encryption in the design of a transport | the use of optional header encryption in the design of a transport | |||
protocol, where support of optional mechanisms can increase the | protocol, where support of optional mechanisms can increase the | |||
complexity of the protocol and its implementation, and in the | complexity of the protocol and its implementation, and in the | |||
management decisions that are needed to use variable format | management decisions that are have to be made to use variable | |||
fields. Instead, fields of a specific type ought to always be | format fields. Instead, fields of a specific type ought to always | |||
sent with the same level of confidentiality or integrity | be sent with the same level of confidentiality or integrity | |||
protection. | protection. | |||
As seen, different transports use encryption to protect their header | As seen, different transports use encryption to protect their header | |||
information to varying degrees. There is, however, a trend towards | information to varying degrees. The trend is towards increased | |||
increased protection with newer transport protocols. | protection. | |||
5. Addition of Transport Information to Network-Layer Headers | 5. Addition of Transport Information to Network-Layer Headers | |||
An on-path device can make measurements by utilising additional | An on-path device can make measurements by utilising additional | |||
protocol headers carrying operations, administration and management | protocol headers carrying operations, administration and management | |||
(OAM) information in an additional packet header. Using network- | (OAM) information in an additional packet header. Using network- | |||
layer approaches to reveal information has the potential that the | layer approaches to reveal information has the potential that the | |||
same method (and hence same observation and analysis tools) can be | same method (and hence same observation and analysis tools) can be | |||
consistently used by multiple transport protocols [RFC8558]. There | consistently used by multiple transport protocols [RFC8558]. There | |||
could also be less desirable implications of separating the operation | could also be less desirable implications of separating the operation | |||
skipping to change at page 27, line 7 ¶ | skipping to change at page 27, line 12 ¶ | |||
extension header or an IPv4 option. This information can be used | extension header or an IPv4 option. This information can be used | |||
across multiple network segments, or between the transport endpoints. | across multiple network segments, or between the transport endpoints. | |||
One example is the IPv6 Performance and Diagnostic Metrics (PDM) | One example is the IPv6 Performance and Diagnostic Metrics (PDM) | |||
Destination Option [RFC8250]. This allows a sender to optionally | Destination Option [RFC8250]. This allows a sender to optionally | |||
include a destination option that caries header fields that can be | include a destination option that caries header fields that can be | |||
used to observe timestamps and packet sequence numbers. This | used to observe timestamps and packet sequence numbers. This | |||
information could be authenticated by receiving transport endpoints | information could be authenticated by receiving transport endpoints | |||
when the information is added at the sender and visible at the | when the information is added at the sender and visible at the | |||
receiving endpoint, although methods to do this have not currently | receiving endpoint, although methods to do this have not currently | |||
been proposed. This method needs to be explicitly enabled at the | been proposed. This method has to be explicitly enabled at the | |||
sender. | sender. | |||
Current measurement results suggest that it could currently be | Current measurement results suggest that it could currently be | |||
undesirable to rely on methods requiring end to end support of | undesirable to rely on methods requiring end-to-end support of | |||
network options or extension headers across the Internet. IPv4 | network options or extension headers across the Internet. 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 have been observed to drop | processing path) and some IPv6 networks have been observed to drop | |||
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]). | |||
Another potential issue is that protocols that separately expose | Protocols can be designed to expose header information separately to | |||
header information do not necessarily have an incentive to expose the | the (hidden) fields used by the protocol state machine. On the one | |||
actual information that is utilised by the protocol itself and could | hand, such approaches can simplify tools by exposing the relevant | |||
metrics (loss, latency, etc), rather having to derive this from other | ||||
fields. This also permits the protocol to evolve independently of | ||||
the ossified observable header [RFC8558]. On the other hand, | ||||
protocols do not necessarily have an incentive to expose the actual | ||||
information that is utilised by the protocol itself and could | ||||
therefore manipulate the exposed header information to gain an | therefore manipulate the exposed header information to gain an | |||
advantage from the network. Where the information is provided by an | advantage from the network. Where the information is provided by an | |||
endpoint, the incentive to reflect actual transport information needs | endpoint, the incentive to reflect actual transport information has | |||
to be considered when proposing a method. | to be considered when proposing a method. | |||
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 transport header fields to expose and which to | |||
choice for the transport protocol. Any selective encryption method | encrypt is a design decision for the transport protocol. Selective | |||
requires trading two conflicting goals for a transport protocol | encryption requires trading conflicting goals of observability and | |||
designer to decide which header fields to encrypt. Security work | network support, privacy, and risk of ossification, to decide what | |||
typically employs a design technique that seeks to expose only what | header fields to protect and which to make visible. | |||
is needed. This approach provides incentives to not reveal any | ||||
information that is not necessary for the end-to-end communication. | Security work typically employs a design technique that seeks to | |||
However, there can be performance and operational benefits in | expose only what is needed. This approach provides incentives to not | |||
exposing selected information to network tools. | reveal any information that is not necessary for the end-to-end | |||
communication. However, there can be performance and operational | ||||
benefits in exposing selected information to network tools. | ||||
This section explores key implications of working with encrypted | This section explores key implications of working with encrypted | |||
transport protocols. | transport protocols. | |||
6.1. Independent Measurement | 6.1. Independent Measurement | |||
Independent observation by multiple actors is important if the | Independent observation by multiple actors is important if the | |||
transport community is to maintain an accurate understanding of the | transport community is to maintain an accurate understanding of the | |||
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 need 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 need 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 utilises RTP format headers in the payload of | |||
the UDP datagram. Since these protocol headers have been fixed for | the 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. | |||
skipping to change at page 28, line 30 ¶ | skipping to change at page 28, line 41 ¶ | |||
when TCP is used over an unencrypted network path (i.e., one that | when TCP is used over an unencrypted network path (i.e., one that | |||
does not use IPsec or other encryption below the transport), it | does not use IPsec or other encryption below the transport), it | |||
implicitly exposes header information that can be used for | implicitly exposes header information that can be used for | |||
measurement at any point along the path. This information is | measurement at any point along the path. This information is | |||
necessary for the protocol's correct operation, therefore there is no | necessary for the protocol's correct operation, therefore there is no | |||
incentive for a TCP or RTP implementation to put incorrect | incentive for a TCP or RTP implementation to put incorrect | |||
information in this transport header. A network device can have | information in this transport header. A network device can have | |||
confidence that the well-known (and ossified) transport information | confidence that the well-known (and ossified) transport information | |||
represents the actual state of the endpoints. | represents the actual state of the endpoints. | |||
When encryption is used to conceal some or all of the transport | When encryption is used to hide some or all of the transport headers, | |||
headers, the transport protocol chooses which information to reveal | the transport protocol chooses which information to reveal to the | |||
to the network about its internal state, what information to leave | network about its internal state, what information to leave | |||
encrypted, and what fields to grease to protect against future | encrypted, and what fields to grease to protect against future | |||
ossification. Such a transport could be designed, for example, to | ossification. Such a transport could be designed, for example, to | |||
provide summary data regarding its performance, congestion control | provide summary data regarding its performance, congestion control | |||
state, etc., or to make an explicit measurement signal available. | state, etc., or to make an explicit measurement signal available. | |||
For example, a QUIC endpoint can optionally set the spin bit to | For example, a QUIC endpoint can optionally set the spin bit to | |||
reflect to explicitly reveal the RTT of an encrypted transport | reflect to explicitly reveal the RTT of an encrypted transport | |||
session to the on-path network devices [I-D.ietf-quic-transport]). | session to the on-path network devices [I-D.ietf-quic-transport]). | |||
When providing or using such information, it becomes important to | When providing or using such information, it is important to consider | |||
consider the privacy of the user and their incentive for providing | the privacy of the user and their incentive for providing accurate | |||
accurate and detailed information. Protocols that selectively reveal | and detailed information. Protocols that selectively reveal some | |||
some transport state or measurement signals are choosing to establish | transport state or measurement signals are choosing to establish a | |||
a trust relationship with the network operators. There is no | trust relationship with the network operators. There is no protocol | |||
protocol mechanism that can guarantee that the information provided | mechanism that can guarantee that the information provided represents | |||
represents the actual transport state of the endpoints, since those | the actual transport state of the endpoints, since those endpoints | |||
endpoints can always send additional information in the encrypted | can always send additional information in the encrypted part of the | |||
part of the header, to update or replace whatever they reveal. This | header, to update or replace whatever they reveal. This reduces the | |||
reduces the ability to independently measure and verify that a | ability to independently measure and verify that a protocol is | |||
protocol is behaving as expected. Some operational uses need the | behaving as expected. For some operational uses, the information has | |||
information to contain sufficient detail to understand, and possibly | to contain sufficient detail to understand, and possibly reconstruct, | |||
reconstruct, the network traffic pattern for further testing; such | the network traffic pattern for further testing. In this case, | |||
operators need to gain the trust of transport protocol implementers | operators have to gain the trust of transport protocol implementers | |||
if they are to correctly reveal such information. | if the transport headers are to correctly reveal such information. | |||
Operations, Administration, and Maintenance (OAM) data records | Operations, Administration, and Maintenance (OAM) data records | |||
[I-D.ietf-ippm-ioam-data] could be embedded into a variety of | [I-D.ietf-ippm-ioam-data] could be embedded into a variety of | |||
encapsulation methods at different layers to support the goals of a | encapsulation methods at different layers to support the goals of a | |||
specific operational domain. OAM-related metadata can support | specific operational domain. OAM-related metadata can support | |||
functions such as performance evaluation, path-tracing, path | functions such as performance evaluation, path-tracing, path | |||
verification information, classification and a diversity of other | verification information, classification and a diversity of other | |||
uses. When encryption is used to conceal some or all of the | uses. When encryption is used to hide some or all of the transport | |||
transport headers, analysis will require coordination between actors | headers, analysis requires coordination between actors at different | |||
at different layers to successfully characterise flows and correlate | layers to successfully characterise flows and correlate the | |||
the performance or behaviour of a specific mechanism with the | performance or behaviour of a specific mechanism with the | |||
configuration and traffic using operational equipment (e.g., | configuration and traffic using operational equipment (e.g., | |||
combining transport and network measurements to explore congestion | combining transport and network measurements to explore congestion | |||
control dynamics, the implications of designs for active queue | control dynamics, the implications of designs for active queue | |||
management or circuit breakers). | management or circuit breakers). | |||
Some measurements could be completed by utilising a standardised | Some measurements could be completed by utilising endpoint-based | |||
endpoint-based logging format (e.g., based on Quic-Trace | logging (e.g., based on Quic-Trace [Quic-Trace]). Such information | |||
[Quic-Trace]). Such information will have a diversity of uses, | has a diversity of uses, including developers wishing to debug/ | |||
including developers wishing to debug/understand the transport/ | understand the transport/application protocols with which they work, | |||
application protocols with which they work, researchers seeking to | researchers seeking to spot trends and anomalies, and to characterise | |||
spot trends and anomalies, and to characterise variants of protocols. | variants of protocols. A standard format for endpoint logging could | |||
Logs collected at endpoints could be shared (after appropriate | allow these to be shared (after appropriate anonymisation) to | |||
annoymisation) to help understand performance and pathologies. | understand performance and pathologies. Measurements based on | |||
Measurements based on logging will need to establish the validity and | logging have to establish the validity and provenance of the logged | |||
provenance of the logged information to establish how and when traces | information to establish how and when traces were captured. | |||
were captured. | ||||
However, endpoint logs do not provide equivalent information to in- | Despite being applicable in some scenarios, endpoint logs do not | |||
network measurements. In particular, endpoint logs contain only a | provide equivalent information to in-network measurements. In | |||
part of the information needed to understand the operation of network | particular, endpoint logs contain only a part of the information to | |||
devices and identify issues such as link performance or capacity | understand the operation of network devices and identify issues such | |||
sharing between multiple flows. Additional information is needed to | as link performance or capacity sharing between multiple flows. | |||
determine which equipment/links are used and the configuration of | Additional information has to be combined to determine which | |||
equipment along the network paths being measured. | equipment/links are used and the configuration of equipment along the | |||
network paths being measured. | ||||
6.2. Characterising "Unknown" Network Traffic | 6.2. Characterising "Unknown" Network Traffic | |||
The patterns and types of traffic that share Internet capacity change | The patterns and types of traffic that share Internet capacity change | |||
over time as networked applications, usage patterns and protocols | over time as networked applications, usage patterns and protocols | |||
continue to evolve. | continue to evolve. | |||
If "unknown" or "uncharacterised" traffic patterns form a small part | If "unknown" or "uncharacterised" traffic patterns form a small part | |||
of the traffic aggregate passing through a network device or segment | of the traffic aggregate passing through a network device or segment | |||
of the network the path, the dynamics of the uncharacterised traffic | of the network the path, the dynamics of the uncharacterised traffic | |||
might not have a significant collateral impact on the performance of | might not have a significant collateral impact on the performance of | |||
other traffic that shares this network segment. Once the proportion | other traffic that shares this network segment. Once the proportion | |||
of this traffic increases, the need to monitor the traffic and | of this traffic increases, monitoring the traffic can determine if | |||
determine if appropriate safety measures need to be put in place. | appropriate safety measures have to be put in place. | |||
Tracking the impact of new mechanisms and protocols requires traffic | Tracking the impact of new mechanisms and protocols requires traffic | |||
volume to be measured and new transport behaviours to be identified. | volume to be measured and new transport behaviours to be identified. | |||
This is especially true of protocols operating over a UDP substrate. | This is especially true of protocols operating over a UDP substrate. | |||
The level and style of encryption needs to be considered in | The level and style of encryption has to be considered in determining | |||
determining how this activity is performed. On a shorter timescale, | how this activity is performed. On a shorter timescale, information | |||
information could also need to be collected to manage denial of | could also have to be collected to manage denial of service attacks | |||
service attacks against the infrastructure. | against the infrastructure. | |||
6.3. Accountability and Internet Transport Protocols | 6.3. Accountability and Internet Transport Protocols | |||
Information provided by tools observing transport headers can be used | Information provided by tools observing transport headers can be used | |||
to classify traffic, and to limit the network capacity used by | to classify traffic, and to limit the network capacity used by | |||
certain flows, as discussed in Section 3.2.4). Equally, operators | certain flows, as discussed in Section 3.2.4). Equally, operators | |||
could use analysis of transport headers and transport flow state to | could use analysis of transport headers and transport flow state to | |||
demonstrate that they are not providing differential treatment to | demonstrate that they are not providing differential treatment to | |||
certain flows. Obfuscating or hiding this information using | certain flows. Obfuscating or hiding this information using | |||
encryption could lead operators and maintainers of middleboxes | encryption could lead operators and maintainers of middleboxes | |||
(firewalls, etc.) to seek other methods to classify, and potentially | (firewalls, etc.) to seek other methods to classify, and potentially | |||
other mechanisms to condition, network traffic. | other mechanisms to condition, network traffic. | |||
A lack of data that reduces the level of precision with which flows | A lack of data that reduces the level of precision with which flows | |||
can be classified also reduces the design space for conditioning | can be classified also reduces the design space for conditioning | |||
mechanisms (e.g., rate limiting, circuit breaker techniques | mechanisms (e.g., rate limiting, circuit breaker techniques | |||
[RFC8084], or blocking of uncharacterised traffic), and this needs to | [RFC8084], or blocking of uncharacterised traffic), and this has to | |||
be considered when evaluating the impact of designs for transport | be considered when evaluating the impact of designs for transport | |||
encryption [RFC5218]. | encryption [RFC5218]. | |||
6.4. Impact on Operational Cost | 6.4. Impact on Operational Cost | |||
Many network operators currently utilise observed transport | Some network operators currently use observed transport header | |||
information as a part of their operational practice, and have | information as a part of their operational practice, and have | |||
developed tools and operational practices based around currently | developed tools and techniques that use information observed in | |||
deployed transports and their applications. Encryption of the | currently deployed transports and their applications. A variety of | |||
transport information prevents tools from directly observing this | open source and proprietary tools have been deployed that use this | |||
information. A variety of open source and commercial tools have been | information for a variety of short and long term measurements. | |||
deployed that utilise this information for a variety of short and | Encryption of the transport information prevents tooling from | |||
long term measurements. | observing the header information, limiting its utility. | |||
The network will not break just because transport headers are | Alternative diagnostic and troubleshooting tools would have to be | |||
encrypted, although alternative diagnostic and troubleshooting tools | developed and deployed is transport header encryption is widely | |||
would need to be developed and deployed. Introducing a new protocol | deployed. Introducing a new protocol or application might then | |||
or application can require these tool chains and practice to be | require these tool chains and practises to be updated, and could in | |||
updated, and could in turn impact operational mechanisms, and | turn impact operational mechanisms, and policies. Each change can | |||
policies. Each change can introduce associated costs, including the | introduce associated costs, including the cost of collecting data, | |||
cost of collecting data, and the tooling needed to handle multiple | and the tooling to handle multiple formats (possibly as these co- | |||
formats (possibly as these co-exist in the network, when measurements | exist in the network, when measurements span time periods during | |||
need to span time periods during which changes are deployed, or to | which changes are deployed, or to compare with historical data). | |||
compare with historical data). These costs are incurred by an | These costs are incurred by an operator to manage the service and | |||
operator to manage the service and debug network issues. | debug network issues. | |||
At the time of writing, the additional operational cost of using | At the time of writing, the additional operational cost of using | |||
encrypted transports is not yet well understood. Design trade-offs | encrypted transports is not yet well understood. Design trade-offs | |||
could mitigate these costs by explicitly choosing to expose selected | could mitigate these costs by explicitly choosing to expose selected | |||
information (e.g., header invariants and the spin-bit in QUIC | information (e.g., header invariants and the spin-bit in QUIC | |||
[I-D.ietf-quic-transport]), the specification of common log formats, | [I-D.ietf-quic-transport]), the specification of common log formats, | |||
and development of alternative approaches. | and development of alternative approaches. | |||
6.5. Impact on Research, Development and Deployment | 6.5. Impact on Research, Development and Deployment | |||
Evolution and the ability to understand (measure) the impact need to | Transport protocol evolution, and the ability to measure and | |||
proceed hand-in-hand. Observable transport headers can provide open | understand the impact of protocol changes, have to proceed hand-in- | |||
and verifiable measurement data. Observation of pathologies has a | hand. Observable transport headers can provide open and verifiable | |||
critical role in the design of transport protocol mechanisms and | measurement data. Observation of pathologies has a critical role in | |||
development of new mechanisms and protocols. This helps | the design of transport protocol mechanisms and development of new | |||
understanding the interactions between cooperating protocols and | mechanisms and protocols. This helps understanding the interactions | |||
network mechanism, the implications of sharing capacity with other | between cooperating protocols and network mechanism, the implications | |||
traffic and the impact of different patterns of usage. The ability | of sharing capacity with other traffic and the impact of different | |||
of other stake holders to review transport header traces helps | patterns of usage. The ability of other stake holders to review | |||
develop insight into performance and traffic contribution of specific | transport header traces helps develop insight into performance and | |||
variants of a protocol. | traffic contribution of specific variants of a protocol. | |||
In development of new transport protocol mechanisms, attention needs | Development of new transport protocol mechanisms has to consider the | |||
to be paid to the expected scale of deployment. Whatever the | scale of deployment and the range of environments in which the | |||
mechanism, experience has shown that it is often difficult to | transport is used. Experience has shown that it is often difficult | |||
correctly implement combinations of mechanisms [RFC8085]. Mechanisms | to correctly implement new mechanisms [RFC8085], and that mechanisms | |||
often evolve as a protocol matures, or in response to changes in | often evolve as a protocol matures, or in response to changes in | |||
network conditions, changes in network traffic, or changes to | network conditions, changes in network traffic, or changes to | |||
application usage. Analysis is especially valuable when based on the | application usage. Analysis is especially valuable when based on the | |||
behaviour experienced across a range of topologies, vendor equipment, | behaviour experienced across a range of topologies, vendor equipment, | |||
and traffic patterns. | and traffic patterns. | |||
New transport protocol formats are expected to facilitate an | New transport protocol formats are expected to facilitate an | |||
increased pace of transport evolution, and with it the possibility to | increased pace of transport evolution, and with it the possibility to | |||
experiment with and deploy a wide range of protocol mechanisms. | experiment with and deploy a wide range of protocol mechanisms. | |||
There has been recent interest in a wide range of new transport | There has been recent interest in a wide range of new transport | |||
skipping to change at page 32, line 9 ¶ | skipping to change at page 32, line 25 ¶ | |||
(PRR), congestion control methods based on measuring bottleneck | (PRR), congestion control methods based on measuring bottleneck | |||
bandwidth and round-trip propagation time, the introduction of AQM | bandwidth and round-trip propagation time, the introduction of AQM | |||
techniques and new forms of ECN response (e.g., Data Centre TCP, | techniques and new forms of ECN response (e.g., Data Centre TCP, | |||
DCTP, and methods proposed for L4S).The growth and diversity of | DCTP, and methods proposed for L4S).The growth and diversity of | |||
applications and protocols using the Internet also continues to | applications and protocols using the Internet also continues to | |||
expand. For each new method or application it is desirable to build | expand. For each new method or application it is desirable to build | |||
a body of data reflecting its behaviour under a wide range of | a body of data reflecting its behaviour under a wide range of | |||
deployment scenarios, traffic load, and interactions with other | deployment scenarios, traffic load, and interactions with other | |||
deployed/candidate methods. | deployed/candidate methods. | |||
Concealing transport header information could reduce the range of | Encryption of transport header information could reduce the range of | |||
actors that can observe useful data. This would limit the | actors that can observe useful data. This would limit the | |||
information sources available to the Internet community to understand | information sources available to the Internet community to understand | |||
the operation of new transport protocols, reducing information to | the operation of new transport protocols, reducing information to | |||
inform design decisions and standardisation of the new protocols and | inform design decisions and standardisation of the new protocols and | |||
related operational practices. The cooperating dependence of | related operational practises. The cooperating dependence of | |||
network, application, and host to provide communication performance | network, application, and host to provide communication performance | |||
on the Internet is uncertain when only endpoints (i.e., at user | on the Internet is uncertain when only endpoints (i.e., at user | |||
devices and within service platforms) can observe performance, and | devices and within service platforms) can observe performance, and | |||
when performance cannot be independently verified by all parties. | when performance cannot be independently verified by all parties. | |||
Independently observed data is also important to ensure the health of | Independently observed data is also important to ensure the health of | |||
the research and development communities and can help promote | the research and development communities and can help promote | |||
acceptance of proposed specifications by the wider community (e.g., | acceptance of proposed specifications by the wider community (e.g., | |||
as a method to judge the safety for Internet deployment) and provides | as a method to judge the safety for Internet deployment) and provides | |||
valuable input during standardisation. Open standards motivate a | valuable input during standardisation. Open standards motivate a | |||
skipping to change at page 32, line 41 ¶ | skipping to change at page 33, line 9 ¶ | |||
7. Conclusions | 7. Conclusions | |||
Header encryption and strong integrity checks are being incorporated | Header encryption and strong integrity checks are being incorporated | |||
into new transport protocols and have important benefits. The pace | into new transport protocols and have important benefits. The pace | |||
of development of transports using the WebRTC data channel, and the | of development of transports using the WebRTC data channel, and the | |||
rapid deployment of the QUIC transport protocol, can both be | rapid deployment of the QUIC transport protocol, can both be | |||
attributed to using the combination of UDP as a substrate while | attributed to using the combination of UDP as a substrate while | |||
providing confidentiality and authentication of the encapsulated | providing confidentiality and authentication of the encapsulated | |||
transport headers and payload. | transport headers and payload. | |||
To achieve stable Internet operations, the IETF transport community | This document has described some current practises, and the | |||
has, to date, relied heavily on measurement and insights of the | implications for some stakeholders, when transport layer header | |||
network operations community to understand the trade-offs, and to | encryption is used. It does not judge whether these practises are | |||
inform selection of appropriate mechanisms, to ensure a safe, | necessary, or endorse the use of any specific practise. Rather, the | |||
reliable, and robust Internet (e.g., [RFC1273],[RFC2914]). | intent is to highlight operational tools and practises to consider | |||
when designing transport protocols, so protocol designers can make | ||||
The traffic that can be observed by on-path network devices (the | informed choice about what transport header fields to encrypt, and | |||
"wire image") is a function of transport protocol design/options, | whether it might be beneficial to make an explicit choice to expose | |||
network use, applications, and user characteristics. In general, | certain fields to the network. In making such a decision, it is | |||
when only a small proportion of the traffic has a specific | important to balance: | |||
(different) characteristic, such traffic seldom leads to operational | ||||
concern, although the ability to measure and monitor it is less. The | ||||
desire to understand the traffic and protocol interactions typically | ||||
grows as the proportion of traffic increases in volume. The | ||||
challenges increase when multiple instances of an evolving protocol | ||||
contribute to the traffic that share network capacity. | ||||
An increased pace of evolution therefore needs to be accompanied by | o User Privacy: The less transport header information that is | |||
methods that can be successfully deployed and used across operational | exposed to the network, the lower the risk of leaking metadata | |||
networks. This leads to a need for network operators at various | that might have privacy implications for the users. Transports | |||
levels (ISPs, enterprises, firewall maintainer, etc.) to identify | that chose to expose some header fields need to make a privacy | |||
appropriate operational support functions and procedures. Protocols | assessment to understand the privacy cost versus benefit trade-off | |||
that change their transport header format (wire image) or their | in making that information available. The process used to define | |||
behaviour (e.g., algorithms that are needed to classify and | and expose the QUIC spin bit to the network is an example of such | |||
characterise the protocol), will require new network tooling to be | an analysis. | |||
developed to catch-up with each change. If a protocol changes so | ||||
that the currently deployed tools and methods are no longer relevant, | ||||
then these tools can not be used to measure performance. This can | ||||
increase the response-time after faults, and can impact the ability | ||||
to manage the network resulting in traffic causing traffic to be | ||||
treated inappropriately (e.g., rate-limiting as a result of incorrect | ||||
classification or monitoring). | ||||
There are benefits in exposing consistent information to the network | o Protocol Ossification: Unencrypted transport header fields are | |||
that avoids traffic being inappropriately classified and then | likely to ossify rapidly, as middleboxes come to rely on their | |||
receiving a default treatment by the network. The flow label and | presence, making it difficult to change the transport in future. | |||
DSCP fields provide examples of how transport information can be made | This argues that the choice to expose information to the network | |||
available for network-layer decisions. Extension headers could also | is made deliberately and with care, since it is essentially | |||
be used to carry transport information that can inform network-layer | defining a stable interface between the transport and the network. | |||
decisions. Other information might also be useful to various | Some protocols will want to make that interface as limited as | |||
stakeholders, however this document does not make recommendations | possible; other protocols might find value in exposing certain | |||
about what information ought to be exposed, to whom it ought to be | information to signal to the network, or in allowing the network | |||
observable, or how this will be achieved. | to change certain header fields as signals to the transport. The | |||
visible wire image of a protocol should be explicitly designed. | ||||
There are trade-offs and implications of increased use of transport | o Impact on Operational Practice: The network operations community | |||
header encryption when designing a protocol. Transport protocol | has long relied on being able to understand Internet traffic | |||
designers have often ignored the implications of whether the | patterns, both in aggregate and at the flow level, to support | |||
information in transport header fields can or will be used by in- | network management, traffic engineering, and troubleshooting. | |||
network devices, and the implications this places on protocol | Operational practice has developed based on the information | |||
evolution. This motivates a design that provides confidentiality of | available from unencrypted transport headers. The IETF has | |||
header information. This lack of visibility of transport header | supported this practice by developing operations and management | |||
information can be expected to impact the ways that protocols are | specifications, interface specifications, and associated Best | |||
deployed, standardised, and their operational support. The impact of | Current Practises. Widespread deployment of transport protocols | |||
hiding transport headers therefore needs to be considered in the | that encrypt their header information might impact network | |||
specification and development of protocols and standards. This has a | operations, unless operators can develop alternative practises | |||
potential impact on the way in which the IRTF and IETF develop new | that work without access to the transport header information. | |||
protocols, specifications, and guidelines: | ||||
o Coexistence of Transport Protocols and Configurations: TCP is | o Pace of Evolution: Removing obstacles to change can enable an | |||
currently the predominant transport protocol used over Internet | increased pace of evolution. If a protocol changes its transport | |||
paths. Its many variants have broadly consistent approaches to | header format (wire image) or their transport behaviour, this can | |||
avoiding congestion collapse, and to ensuring the stability of the | result in the currently deployed tools and methods becoming no | |||
Internet. Increased use of transport layer encryption can | longer relevant. Where this needs to be accompanied by | |||
overcome ossification, allowing deployment of new transports and | development of appropriate operational support functions and | |||
different types of congestion control. This flexibility can be | procedures, it can incur a cost in new tooling to catch-up with | |||
beneficial, but it could come at the cost of fragmenting the | each change. Protocols that consistently expose observable data | |||
ecosystem. There is little doubt that developers will try to | do not require such development, but can suffer from ossification | |||
produce high quality transports for their intended target uses, | and need to consider if the exposed protocol metadata has privacy | |||
but it is not yet clear there are sufficient incentives to ensure | implications, There is no single deployment context, and therefore | |||
good practice that benefits the wide diversity of requirements for | designers need to consider the diversity of operational networks | |||
the Internet community as a whole. | (ISPs, enterprises, DDoS mitigation and firewall maintainers, | |||
etc.). | ||||
o Supporting Common Specifications: Common open specifications can | o Supporting Common Specifications: Common, open, specifications can | |||
stimulate engagement by developers, users, and researchers. | stimulate engagement by developers, users, researchers, and the | |||
Increased diversity, and the ability to innovate without public | broader community. Increased protocol diversity can be beneficial | |||
scrutiny, risks point solutions that optimise for specific needs, | in meeting new requirements, but the ability to innovate without | |||
but accidentally disrupt operations of/in different parts of the | public scrutiny risks point solutions that optimise for specific | |||
network. The social contract that maintains the stability of the | cases, but that can accidentally disrupt operations of/in | |||
Internet relies on accepting common interworking specifications, | different parts of the network. The social contract that | |||
and on it being possible to detect violations. | maintains the stability of the Internet relies on accepting common | |||
interworking specifications, and on it being possible to detect | ||||
violations. It is important to find new ways of maintaining that | ||||
community trust as increased use of transport header encryption | ||||
limits visibility into transport behaviour. | ||||
o Benchmarking and Understanding Feature Interactions: An | o Impact on Benchmarking and Understanding Feature Interactions: An | |||
appropriate vantage point for observation, coupled with timing | appropriate vantage point for observation, coupled with timing | |||
information about traffic flows, provides a valuable tool for | information about traffic flows, provides a valuable tool for | |||
benchmarking network devices, endpoint stacks, functions, and/or | benchmarking network devices, endpoint stacks, functions, and/or | |||
configurations. This can also help with understanding complex | configurations. This can also help with understanding complex | |||
feature interactions. An inability to observe transport layer | feature interactions. An inability to observe transport layer | |||
header information can make it harder to diagnose and explore | header information can make it harder to diagnose and explore | |||
interactions between features at different protocol layers, a | interactions between features at different protocol layers, a | |||
side-effect of not allowing a choice of vantage point from which | side-effect of not allowing a choice of vantage point from which | |||
this information is observed. New approaches will need to be | this information is observed. New approaches might have to be | |||
developed. | developed. | |||
o Operational Practice: The network operations community relies on | o Impact on Research and Development: Hiding transport information | |||
being able to understand the pattern and requirements of traffic | can impede independent research into new mechanisms, measurement | |||
passing over the Internet, both in aggregate and at the flow | of behaviour, and development initiatives. Experience shows that | |||
level. These operational practices have developed based on the | ||||
information available from unencrypted transport headers. The | ||||
IETF supports this activity by developing operations and | ||||
management specifications, interface specifications, and | ||||
associated Best Current Practice (BCP) specifications. Concealing | ||||
transport header information impacts current practice and demand | ||||
new specifications. | ||||
o Research and Development: Concealing transport information can | ||||
impede independent research into new mechanisms, measurement 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 have 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 increased use of transport header encryption results | capacity. If increased use of transport header encryption results | |||
in reduced availability of open data, it could eliminate the | in reduced availability of open data, it could eliminate the | |||
independent self-checks to the standardisation process that have | independent self-checks to the standardisation process that have | |||
previously been in place from research and academic contributors | previously been in place from research and academic contributors | |||
(e.g., the role of the IRTF Internet Congestion Control Research | (e.g., the role of the IRTF Internet Congestion Control Research | |||
Group (ICCRG) and research publications in reviewing new transport | Group (ICCRG) and research publications in reviewing new transport | |||
mechanisms and assessing the impact of their experimental | mechanisms and assessing the impact of their deployment). | |||
deployment). | ||||
The design of future transport protocols needs to consider encryption | Observable transport information information might be useful to | |||
of their transport headers to satisfy security and privacy concerns. | various stakeholders. Other stakeholders have incentives to limit | |||
This choice to encrypt all, or part, of the transport layer protocol | what can be observed. This document does not make recommendations | |||
headers needs to also take into account the impact on operations, | about what information ought to be exposed, to whom it ought to be | |||
standards, and research. As [RFC7258] notes, "Making networks | observable, or how this will be achieved. There are also design | |||
unmanageable to mitigate (pervasive monitoring) is not an acceptable | choices about where observable fields are placed. For example, one | |||
outcome, but ignoring (pervasive monitoring) would go against the | location could be a part of the transport header outside of the | |||
consensus documented here." | encryption envelope, another alternative is to carry the information | |||
in a network-layer extension header. New transport protocol designs | ||||
ought to explicitly identify any fields that are intended to be | ||||
observed, consider if there are alternative ways of providing the | ||||
information, and reflect on the implications of observable fields | ||||
being used by in-network devices, and how this might impact user | ||||
privacy and protocol evolution when these fields become ossified. | ||||
As part of a protocol's design, the community therefore needs to | As [RFC7258] notes, "Making networks unmanageable to mitigate | |||
weigh the benefits of ossifying common headers versus the potential | (pervasive monitoring) is not an acceptable outcome, but ignoring | |||
demerits of exposing specific information that could be observed | (pervasive monitoring) would go against the consensus documented | |||
along the network path, to ensure network operators, researchers and | here." Providing explicit information can help avoid traffic being | |||
other stakeholders have appropriate tools to manage their networks | inappropriately classified, impacting application performance. An | |||
and enable stable operation of the Internet as new protocols are | appropriate balance will emerge over time as real instances of this | |||
deployed. An appropriate balance will emerge over time as real | tension are analysed [RFC7258]. This balance between information | |||
instances of this tension are analysed [RFC7258]. This balance | exposed and information hidden ought to be carefully considered when | |||
between information exposed and information concealed ought to be | specifying new transport protocols. | |||
carefully considered when specifying new transport protocols. | ||||
8. Security Considerations | 8. Security Considerations | |||
This document is about design and deployment considerations for | This document is about design and deployment considerations for | |||
transport protocols. Issues relating to security are discussed | transport protocols. Issues relating to security are discussed | |||
throughout this document. | throughout this document. | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as Transport Features by [RFC8095]. As currently | are identified as Transport Features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
skipping to change at page 36, line 4 ¶ | skipping to change at page 36, line 7 ¶ | |||
throughout this document. | throughout this document. | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as Transport Features by [RFC8095]. As currently | are identified as Transport Features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
protocol or layer on top of the transport protocol | protocol or layer on top of the transport protocol | |||
[I-D.ietf-taps-transport-security]. | [I-D.ietf-taps-transport-security]. | |||
Confidentiality and strong integrity checks have properties that can | Confidentiality and strong integrity checks have properties that can | |||
also be incorporated into the design of a transport protocol. | also be incorporated into the design of a transport protocol. | |||
Integrity checks can protect an endpoint from undetected modification | Integrity checks can protect an endpoint from undetected modification | |||
of protocol fields by network devices, whereas encryption and | of protocol fields by network devices, whereas encryption and | |||
obfuscation or greasing can further prevent these headers being | obfuscation or greasing can further prevent these headers being | |||
utilised by network devices. Hiding headers can therefore provide | utilised by network devices. Preventing observation of headers | |||
the opportunity for greater freedom to update the protocols and can | provides an opportunity for greater freedom to update the protocols | |||
ease experimentation with new techniques and their final deployment | and can ease experimentation with new techniques and their final | |||
in endpoints. A protocol specification needs to weigh the costs of | deployment in endpoints. A protocol specification needs to weigh the | |||
ossifying common headers, versus the potential benefits of exposing | costs of ossifying common headers, versus the potential benefits of | |||
specific information that could be observed along the network path to | exposing specific information that could be observed along the | |||
provide tools to manage new variants of protocols. | network path to provide tools to manage new variants of protocols. | |||
A protocol design that uses header encryption can provide | A protocol design that uses header encryption can provide | |||
confidentiality of some or all of the protocol header information. | confidentiality of some or all of the protocol header information. | |||
This prevents an on-path device from knowledge of the header field. | This prevents an on-path device from knowledge of the header field. | |||
It therefore prevents mechanisms being built that directly rely on | It therefore prevents mechanisms being built that directly rely on | |||
the information or seeks to infer semantics of an exposed header | the information or seeks to infer semantics of an exposed header | |||
field. Hiding headers reduces visibility into transport metadata, | field. Reduces visibility into transport metadata can limit the | |||
and can limit the ability to measure and characterise traffic. It | ability to measure and characterise traffic. It can also provide | |||
can also provide privacy benefits in some cases. | privacy benefits in some cases. | |||
Extending the transport payload security context to also include the | ||||
transport protocol header protects both information with the same | ||||
key. A privacy concern would arise if this key was shared with a | ||||
third party, e.g., providing access to transport header information | ||||
to debug a performance issue, would also result in exposing the | ||||
transport payload data to the same third party. A layered security | ||||
design that separates network data from payload data would avoid such | ||||
risks. | ||||
Exposed transport headers are sometimes utilised as a part of the | Exposed transport headers are sometimes utilised as a part of the | |||
information to detect anomalies in network traffic. This can be used | information to detect anomalies in network traffic. "While PM is an | |||
as the first line of defence to identify potential threats from DOS | attack, other forms of monitoring that might fit the definition of PM | |||
or malware and redirect suspect traffic to dedicated nodes | can be beneficial and not part of any attack, e.g., network | |||
management functions monitor packets or flows and anti-spam | ||||
mechanisms need to see mail message content." [RFC7258]. This can | ||||
be used as the first line of defence to identify potential threats | ||||
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 are sometimes also utilised as a part | |||
of the information used by the receiver of a transport protocol to | of the information used by the receiver of a transport protocol to | |||
protect the transport layer from data injection by an attacker. In | protect the transport layer from data injection by an attacker. In | |||
evaluating this use of exposed header information, it is important to | evaluating this use of exposed header information, it is important to | |||
skipping to change at page 37, line 16 ¶ | skipping to change at page 37, line 29 ¶ | |||
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 needs 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 | |||
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 38, line 38 ¶ | skipping to change at page 39, line 5 ¶ | |||
Alvestrand, H., "Overview: Real Time Protocols for | Alvestrand, H., "Overview: Real Time Protocols for | |||
Browser-based Applications", draft-ietf-rtcweb-overview-19 | Browser-based Applications", draft-ietf-rtcweb-overview-19 | |||
(work in progress), November 2017. | (work in progress), November 2017. | |||
[I-D.ietf-taps-transport-security] | [I-D.ietf-taps-transport-security] | |||
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. | Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. | |||
Rose, "A Survey of Transport Security Protocols", draft- | Rose, "A Survey of Transport Security Protocols", draft- | |||
ietf-taps-transport-security-08 (work in progress), August | ietf-taps-transport-security-08 (work in progress), August | |||
2019. | 2019. | |||
[I-D.ietf-tls-grease] | ||||
Benjamin, D., "Applying GREASE to TLS Extensibility", | ||||
draft-ietf-tls-grease-04 (work in progress), August 2019. | ||||
[I-D.ietf-tsvwg-rtcweb-qos] | [I-D.ietf-tsvwg-rtcweb-qos] | |||
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | |||
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | |||
qos-18 (work in progress), August 2016. | qos-18 (work in progress), August 2016. | |||
[I-D.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. | |||
skipping to change at page 39, line 17 ¶ | skipping to change at page 39, line 27 ¶ | |||
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- | [Measure] 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". | |||
[RFC1273] Schwartz, M., "Measurement Study of Changes in Service- | ||||
Level Reachability in the Global TCP/IP Internet: Goals, | ||||
Experimental Design, Implementation, and Policy | ||||
Considerations", RFC 1273, DOI 10.17487/RFC1273, November | ||||
1991, <https://www.rfc-editor.org/info/rfc1273>. | ||||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
DOI 10.17487/RFC2474, December 1998, | DOI 10.17487/RFC2474, December 1998, | |||
<https://www.rfc-editor.org/info/rfc2474>. | <https://www.rfc-editor.org/info/rfc2474>. | |||
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
and W. Weiss, "An Architecture for Differentiated | and W. Weiss, "An Architecture for Differentiated | |||
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | |||
<https://www.rfc-editor.org/info/rfc2475>. | <https://www.rfc-editor.org/info/rfc2475>. | |||
skipping to change at page 39, line 47 ¶ | skipping to change at page 40, line 5 ¶ | |||
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP | [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP | |||
Headers for Low-Speed Serial Links", RFC 2508, | Headers for Low-Speed Serial Links", RFC 2508, | |||
DOI 10.17487/RFC2508, February 1999, | DOI 10.17487/RFC2508, February 1999, | |||
<https://www.rfc-editor.org/info/rfc2508>. | <https://www.rfc-editor.org/info/rfc2508>. | |||
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | |||
RFC 2914, DOI 10.17487/RFC2914, September 2000, | RFC 2914, DOI 10.17487/RFC2914, September 2000, | |||
<https://www.rfc-editor.org/info/rfc2914>. | <https://www.rfc-editor.org/info/rfc2914>. | |||
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. | ||||
Shelby, "Performance Enhancing Proxies Intended to | ||||
Mitigate Link-Related Degradations", RFC 3135, | ||||
DOI 10.17487/RFC3135, June 2001, | ||||
<https://www.rfc-editor.org/info/rfc3135>. | ||||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, DOI 10.17487/RFC3168, September 2001, | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
<https://www.rfc-editor.org/info/rfc3168>. | <https://www.rfc-editor.org/info/rfc3168>. | |||
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | |||
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | |||
<https://www.rfc-editor.org/info/rfc3234>. | <https://www.rfc-editor.org/info/rfc3234>. | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
skipping to change at page 42, line 14 ¶ | skipping to change at page 42, line 14 ¶ | |||
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | |||
for Equal Cost Multipath Routing and Link Aggregation in | for Equal Cost Multipath Routing and Link Aggregation in | |||
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, | Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, | |||
<https://www.rfc-editor.org/info/rfc6438>. | <https://www.rfc-editor.org/info/rfc6438>. | |||
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | |||
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May | Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May | |||
2014, <https://www.rfc-editor.org/info/rfc7258>. | 2014, <https://www.rfc-editor.org/info/rfc7258>. | |||
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | ||||
"Recommendations for Secure Use of Transport Layer | ||||
Security (TLS) and Datagram Transport Layer Security | ||||
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | ||||
2015, <https://www.rfc-editor.org/info/rfc7525>. | ||||
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | |||
Recommendations Regarding Active Queue Management", | Recommendations Regarding Active Queue Management", | |||
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | |||
<https://www.rfc-editor.org/info/rfc7567>. | <https://www.rfc-editor.org/info/rfc7567>. | |||
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
Aitken, P., and A. Akhter, "A Framework for Large-Scale | Aitken, P., and A. Akhter, "A Framework for Large-Scale | |||
Measurement of Broadband Performance (LMAP)", RFC 7594, | Measurement of Broadband Performance (LMAP)", RFC 7594, | |||
DOI 10.17487/RFC7594, September 2015, | DOI 10.17487/RFC7594, September 2015, | |||
<https://www.rfc-editor.org/info/rfc7594>. | <https://www.rfc-editor.org/info/rfc7594>. | |||
skipping to change at page 46, line 41 ¶ | skipping to change at page 46, line 41 ¶ | |||
repetition. This edit finally gets to this, and eliminates some | repetition. This edit finally gets to this, and eliminates some | |||
duplication. This also moves some of the material from section 2 to | duplication. This also moves some of the material from section 2 to | |||
reform a clearer conclusion. The scope remains focussed on the usage | reform a clearer conclusion. The scope remains focussed on the usage | |||
of transport headers and the implications of encryption - not on | of transport headers and the implications of encryption - not on | |||
proposals for new techniques/specifications to be developed. | proposals for new techniques/specifications to be developed. | |||
-08 Addressed feedback and completed editorial work, including | -08 Addressed feedback and completed editorial work, including | |||
updating the text referring to RFC7872, in preparation for a WGLC. | updating the text referring to RFC7872, in preparation for a WGLC. | |||
-09 Updated following WGLC. In particular, thanks to Joe Touch | -09 Updated following WGLC. In particular, thanks to Joe Touch | |||
(specific comments and commentry on style and tone); Dimitri Tikonov | (specific comments and commentary on style and tone); Dimitri Tikonov | |||
(editorial); Christian Huitema (various) David Black (various). | (editorial); Christian Huitema (various); David Black (various). | |||
Ammended privacy considerations based on SECDIR review. Emile | Amended privacy considerations based on SECDIR review. Emile Stephan | |||
Stephan (inputs on operations measurement); Various others. | (inputs on operations measurement); Various others. | |||
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 | ||||
from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter | ||||
Gutmann; Ekr; and many others via the TSVWG list. Some people | ||||
thought that "needed" and "need" could represent requirements in the | ||||
document, etc. this has been clarified. | ||||
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. 164 change blocks. | ||||
805 lines changed or deleted | 803 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/ |