draft-ietf-tsvwg-transport-encrypt-05.txt | draft-ietf-tsvwg-transport-encrypt-06.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: September 10, 2019 University of Glasgow | Expires: December 2, 2019 University of Glasgow | |||
March 9, 2019 | May 31, 2019 | |||
The Impact of Transport Header Confidentiality on Network Operation and | The Impact of Transport Header Confidentiality on Network Operation and | |||
Evolution of the Internet | Evolution of the Internet | |||
draft-ietf-tsvwg-transport-encrypt-05 | draft-ietf-tsvwg-transport-encrypt-06 | |||
Abstract | Abstract | |||
This document describes implications of applying end-to-end | This document describes implications of applying end-to-end | |||
encryption at the transport layer. It identifies in-network uses of | encryption at the transport layer. It identifies in-network uses of | |||
transport layer header information. It then reviews the implications | transport layer header information. It then reviews the implications | |||
of developing end-to-end transport protocols that use authentication | of developing end-to-end transport protocols that use authentication | |||
to protect the integrity of transport information or encryption to | to protect the integrity of transport information or encryption to | |||
provide confidentiality of the transport protocol header and expected | provide confidentiality of the transport protocol header and expected | |||
implications of transport protocol design and network operation. | implications of transport protocol design and network operation. | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 10, 2019. | This Internet-Draft will expire on December 2, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 | 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 | |||
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 . . . . . 10 | 3.1. Observing Transport Information in the Network . . . . . 10 | |||
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 16 | 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 16 | |||
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 20 | 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 20 | |||
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 21 | 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 21 | |||
4. Encryption and Authentication of Transport Headers . . . . . 21 | 4. Encryption and Authentication of Transport Headers . . . . . 22 | |||
5. Addition of Transport Information to Network-Layer Protocol | 5. Addition of Transport Information to Network-Layer Protocol | |||
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
6. Implications of Protecting the Transport Headers . . . . . . 26 | 6. Implications of Protecting the Transport Headers . . . . . . 26 | |||
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 26 | 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 27 | |||
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 28 | 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 29 | |||
6.3. Accountability and Internet Transport Protocols . . . . . 29 | 6.3. Accountability and Internet Transport Protocols . . . . . 29 | |||
6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 29 | 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 29 | |||
6.5. Impact on Research, Development and Deployment . . . . . 30 | 6.5. Impact on Research, Development and Deployment . . . . . 30 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 35 | 11. Informative References . . . . . . . . . . . . . . . . . . . 34 | |||
Appendix A. Revision information . . . . . . . . . . . . . . . . 42 | Appendix A. Revision information . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
1. Introduction | 1. Introduction | |||
There is increased interest in, and deployment of, new protocols that | There is increased interest in, and deployment of, new protocols that | |||
employ end-to-end encryption at the transport layer, including the | employ end-to-end encryption at the transport layer, including the | |||
transport layer headers. An example of such a transport is the QUIC | transport layer headers. An example of such a transport is the QUIC | |||
transport protocol [I-D.ietf-quic-transport], currently being | transport protocol [I-D.ietf-quic-transport], currently being | |||
standardised in the IETF. Encryption of transport layer headers and | standardised in the IETF. Encryption of transport layer headers and | |||
payload data has many benefits in terms of protecting user privacy. | payload data has many benefits in terms of protecting user privacy. | |||
These benefits have been widely discussed [RFC7258], [RFC7624], and | These benefits have been widely discussed [RFC7258], [RFC7624], and | |||
this document strongly supports the increased use of encryption in | this document strongly supports the increased use of encryption in | |||
transport protocols. There are also, however, some costs, in that | transport protocols. There are also, however, some costs, in that | |||
the widespread use of transport encryption requires changes to | the widespread use of transport encryption requires changes to | |||
network operations, and complicates network measurement for research, | network operations, and complicates network measurement for research, | |||
operational, and standardisation purposes. | operational, and standardisation purposes. The direction in which | |||
the use of transport header confidentiality evolves could have | ||||
significant implications on the way the Internet architecture | ||||
develops, and therefore needs to be considered as a part of protocol | ||||
design. | ||||
This document discusses some consequences of applying end-to-end | This document discusses some consequences of applying end-to-end | |||
encryption at the transport layer. It reviews the implications of | encryption at the transport layer. It reviews the implications of | |||
developing end-to-end transport protocols that use encryption to | developing end-to-end transport protocols that use encryption to | |||
provide confidentiality of the transport protocol header, and | provide confidentiality of the transport protocol header, and | |||
considers the effect of such changes on transport protocol design and | considers the effect of such changes on transport protocol design and | |||
network operations. It also considers anticipated implications on | network operations. It also considers anticipated implications on | |||
transport and application evolution. | transport and application evolution. | |||
The remainder of this document discusses some consequences of | ||||
applying end-to-end encryption at the transpvort layer. It reviews | ||||
the implications of developing end-to-end transport protocols that | ||||
use encryption to provide confidentiality of the transport protocol | ||||
header, and considers the effect of such changes on transport | ||||
protocol design and network operations. It also considers | ||||
anticipated implications on transport and application evolution. | ||||
Transports are increasingly encrypting and authenticating the payload | Transports are increasingly encrypting and authenticating the payload | |||
(i.e., the application data carried within the transport connection) | (i.e., the application data carried within the transport connection) | |||
end-to-end. Such protection is encouraged, and the implications of | end-to-end. Such protection is encouraged, and the implications of | |||
protecting the payload are not further discussed in this memo. | protecting the payload are not further discussed in this memo. | |||
2. Context and Rationale | 2. Context and Rationale | |||
The transport layer provides end-to-end interactions between | The transport layer provides end-to-end interactions between | |||
endpoints (processes) using an Internet path. Transport protocols | endpoints (processes) using an Internet path. Transport protocols | |||
layer directly over the network-layer service and are sent in the | layer directly over the network-layer service and are sent in the | |||
skipping to change at page 28, line 9 ¶ | skipping to change at page 28, line 17 ¶ | |||
represents the actual transport state of the endpoints, since those | represents the actual transport state of the endpoints, since those | |||
endpoints can always send additional information in the encrypted | endpoints can always send additional information in the encrypted | |||
part of the header, to update to replace whatever they reveal. This | part of the header, to update to replace whatever they reveal. This | |||
reduces the ability to independently measure and verify that a | reduces the ability to independently measure and verify that a | |||
protocol is behaving as expected. Some operational uses need the | protocol is behaving as expected. Some operational uses need the | |||
information to contain sufficient detail to understand, and possibly | information to contain sufficient detail to understand, and possibly | |||
reconstruct, the network traffic pattern for further testing; such | reconstruct, the network traffic pattern for further testing; such | |||
operators must gain the trust of transport protocol implementers if | operators must gain the trust of transport protocol implementers if | |||
they are to correctly reveal such information. | they are to correctly reveal such information. | |||
OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a | ||||
variety of encapsulation methods at different layers to support the | ||||
goals of a specific operational domain. OAM-related metadata can | ||||
support functions such as performance evaluation, path-tracing, path | ||||
verification information, classification and a diversity of other | ||||
uses. When encryption is used to conceal some or all of the | ||||
transport headers, analysis will require coordination between actors | ||||
at different layers to successfully characterise flows and correlate | ||||
the performance or behavior of a specific mechanism with the | ||||
configuration and traffic using operational equipment (e.g. | ||||
Combining transport and network measurements to explore congestion | ||||
control dynamics or the implications of active queue management). | ||||
For some usage a standardised endpoint-based logging format (e.g., | For some usage a standardised endpoint-based logging format (e.g., | |||
based onQuic-Trace [Quic-Trace]) could offer an alternative to in- | based onQuic-Trace [Quic-Trace]) could offer an alternative to in- | |||
network measurement. Such information will have a diversity of uses | network measurement. Such information will have a diversity of uses | |||
- examples include developers wishing to debug/understand the | - examples include developers wishing to debug/understand the | |||
transport/applictaion protocols with which they work, to researchers | transport/applictaion protocols with which they work, to researchers | |||
seeking to spot trends, anomalies and to characterise variants of | seeking to spot trends, anomalies and to characterise variants of | |||
protocols. This use will need to establish the validity and | protocols. This use will need to establish the validity and | |||
provenance of the logging information (e.g., to establish how and | provenance of the logging information (e.g., to establish how and | |||
when traces were captured). | when traces were captured). | |||
skipping to change at page 31, line 44 ¶ | skipping to change at page 32, line 19 ¶ | |||
monitored). | monitored). | |||
There are benefits in exposing consistent information to the network | There are benefits in exposing consistent information to the network | |||
that avoids traffic being inappropriately classified and then | that avoids traffic being inappropriately classified and then | |||
receiving a default treatment by the network. The flow label and | receiving a default treatment by the network. The flow label and | |||
DSCP fields provide examples of how transport information can be made | DSCP fields provide examples of how transport information can be made | |||
available for network-layer decisions. Extension headers could also | available for network-layer decisions. Extension headers could also | |||
be used to carry transport information that can inform network-layer | be used to carry transport information that can inform network-layer | |||
decisions. | decisions. | |||
As a part of its design, a new protocol specification therefore needs | As part of a protocol's design, the community needs to weigh the | |||
to weigh the benefits of ossifying common headers, versus the | benefits of ossifying common headers versus the potential demerits of | |||
potential demerits of exposing specific information that could be | exposing specific information that could be observed along the | |||
observed along the network path, to provide tools to manage new | network path, to ensure network operators have appropriate tools to | |||
variants of protocols. This can be done for the entire transport | manage their networks and enable stable operation of the Internet as | |||
header, or by dividing header fields between those that are | new protocols are deployed. | |||
observable and mutable; those that are observable, but immutable; and | ||||
those that are hidden/obfusticated. | ||||
Several scenarios to illustrate different ways this could evolve are | ||||
provided below: | ||||
o One scenario is when transport protocols provide consistent | ||||
information to the network by intentionally exposing a part of the | ||||
transport header. The design fixes the format of this information | ||||
between versions of the protocol. This ossification of the | ||||
transport header allows an operator to establish tooling and | ||||
procedures that enable it to provide consistent traffic management | ||||
as the protocol evolves. In contrast to TCP (where all protocol | ||||
information is exposed), evolution of the transport is facilitated | ||||
by providing cryptographic integrity checks of the transport | ||||
header fields (preventing undetected middlebox changes) and | ||||
encryption of other protocol information (preventing observation | ||||
within the network, or providing incentives for the use of the | ||||
exposed information, rather than inferring information from other | ||||
characteristics of the flow traffic). The exposed transport | ||||
information can be used by operators to provide troubleshooting, | ||||
measurement and any necessary functions appropriate to the class | ||||
of traffic (priority, retransmission, reordering, circuit | ||||
breakers, etc). | ||||
o An alternative scenario adopts different design goals, with a | ||||
different outcome. A protocol that encrypts all header | ||||
information forces network operators to act independently from | ||||
apps/transport developments to extract the information they need | ||||
to manage their network. A range of approaches could proliferate, | ||||
as in current networks. Some operators can add a shim header to | ||||
each packet in a flow as the flow crosses a network segment; other | ||||
operators/managers could develop heuristics and pattern | ||||
recognition to derive information that classifies flows and | ||||
estimates quality metrics for the service being used; some could | ||||
decide to rate-limit or block traffic until new tooling is in | ||||
place. In many cases, the derived information can be used by | ||||
operators to provide necessary functions appropriate to the class | ||||
of traffic (priority, retransmission, reordering, circuit | ||||
breakers, etc). Troubleshooting, and measurement becomes more | ||||
difficult, and more diverse. This could require additional | ||||
information beyond that visible in the packet header and when this | ||||
information is used to inform decisions by on-path devices it can | ||||
lead to dependency on other characteristics of the flow. In some | ||||
cases, operators might need access to keying information to | ||||
interpret encrypted data that they observe. Some use cases could | ||||
demand use of transports that do not use encryption. | ||||
The direction in which this evolves could have significant | ||||
implications on the way the Internet architecture develops. It | ||||
exposes a risk that significant actors (e.g., developers and | ||||
transport designers) achieve more control of the way in which the | ||||
Internet architecture develops.In particular, there is a possibility | ||||
that designs could evolve to significantly benefit of customers for a | ||||
specific vendor, and that communities with very different network, | ||||
applications or platforms could then suffer at the expense of | ||||
benefits to their vendors own customer base. In such a scenario, | ||||
there could be no incentive to support other applications/products or | ||||
to work in other networks leading to reduced access for new | ||||
approaches. | ||||
8. Security Considerations | 8. Security Considerations | |||
This document is about design and deployment considerations for | This document is about design and deployment considerations for | |||
transport protocols. Issues relating to security are discussed in | transport protocols. Issues relating to security are discussed in | |||
the various sections of the document. | the various sections of the document. | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as Transport Features by [RFC8095]. As currently | are identified as Transport Features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
skipping to change at page 43, line 25 ¶ | skipping to change at page 43, line 25 ¶ | |||
o Add text on the explicit spin-bit work in the QUIC DT. Added | o Add text on the explicit spin-bit work in the QUIC DT. Added | |||
greasing of spin-bit. (Section 6.1) | greasing of spin-bit. (Section 6.1) | |||
o Updated section 6 and added more explanation of impact on | o Updated section 6 and added more explanation of impact on | |||
operators. | operators. | |||
o Other comments addressed. | o Other comments addressed. | |||
-05 Editorial pass and minor corrections noted on TSVWG list. | -05 Editorial pass and minor corrections noted on TSVWG list. | |||
-06 Updated conclusions and minor corrections. Responded to request | ||||
to add OAM discussion to Section 6.1. | ||||
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. 11 change blocks. | ||||
79 lines changed or deleted | 47 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/ |