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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/