draft-ietf-tsvwg-transport-encrypt-19.txt   draft-ietf-tsvwg-transport-encrypt-20.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: August 1, 2021 University of Glasgow Expires: September 9, 2021 University of Glasgow
January 28, 2021 March 8, 2021
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-19 draft-ietf-tsvwg-transport-encrypt-20
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, mitigate attacks against the transport ossification by middleboxes, mitigate attacks against the transport
protocol, and protect metadata about the communication. Current protocol, and protect metadata about the communication. Current
operational practice in some networks inspect transport header operational practice in some networks inspect transport header
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 August 1, 2021. This Internet-Draft will expire on September 9, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current uses of Transport Headers within the Network . . . . 4 2. Current uses of Transport Headers within the Network . . . . 4
2.1. To Identify Transport Protocols and Flows . . . . . . . . 5 2.1. To Identify Transport Protocols and Flows . . . . . . . . 5
2.2. To Understand Transport Protocol Performance . . . . . . 6 2.2. To Understand Transport Protocol Performance . . . . . . 6
2.3. To Support Network Operations . . . . . . . . . . . . . . 12 2.3. To Support Network Operations . . . . . . . . . . . . . . 12
2.4. To Support Header Compression . . . . . . . . . . . . . . 17 2.4. To Support Header Compression . . . . . . . . . . . . . . 17
2.5. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18 2.5. To Verify SLA Compliance . . . . . . . . . . . . . . . . 18
3. Research, Development and Deployment . . . . . . . . . . . . 18 3. Research, Development and Deployment . . . . . . . . . . . . 18
3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19 3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19
3.2. Measurable Transport Protocols . . . . . . . . . . . . . 19 3.2. Measurable Transport Protocols . . . . . . . . . . . . . 19
3.3. Other Sources of Information . . . . . . . . . . . . . . 20 3.3. Other Sources of Information . . . . . . . . . . . . . . 21
4. Encryption and Authentication of Transport Headers . . . . . 21 4. Encryption and Authentication of Transport Headers . . . . . 21
5. Intentionally Exposing Transport Information to the Network . 25 5. Intentionally Exposing Transport Information to the Network . 26
5.1. Exposing Transport Information in Extension Headers . . . 26 5.1. Exposing Transport Information in Extension Headers . . . 26
5.2. Common Exposed Transport Information . . . . . . . . . . 26 5.2. Common Exposed Transport Information . . . . . . . . . . 27
5.3. Considerations for Exposing Transport Information . . . . 26 5.3. Considerations for Exposing Transport Information . . . . 27
6. Addition of Transport OAM Information to Network-Layer 6. Addition of Transport OAM Information to Network-Layer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 27 6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28
6.2. Use of OAM across Multiple Maintenance Domains . . . . . 28 6.2. Use of OAM across Multiple Maintenance Domains . . . . . 28
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
11. Informative References . . . . . . . . . . . . . . . . . . . 34 11. Informative References . . . . . . . . . . . . . . . . . . . 34
Appendix A. Revision information . . . . . . . . . . . . . . . . 42 Appendix A. Revision information . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
The transport layer supports the end-to-end flow of data across a The transport layer supports the end-to-end flow of data across a
network path, providing features such as connection establishment, network path, providing features such as connection establishment,
reliability, framing, ordering, congestion control, flow control, reliability, framing, ordering, congestion control, flow control,
etc., as needed to support applications. One of the core functions etc., as needed to support applications. One of the core functions
of an Internet transport: to discover and adapt to the of an Internet transport: to discover and adapt to the
characteristics of the network path that is currently being used. characteristics of the network path that is currently being used.
skipping to change at page 8, line 48 skipping to change at page 8, line 48
applications, can be inferred from a 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 resemble those for the measurement of latency. The requirements resemble those for the measurement of latency.
Flow Reordering: Significant packet reordering within a flow can Flow Reordering: Significant packet reordering within a flow can
impact time-critical applications and can be interpreted as loss impact time-critical applications and can be interpreted as loss
by reliable transports. Many transport protocol techniques are by reliable transports. Many transport protocol techniques are
impacted by reordering (e.g., triggering TCP retransmission or 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. Network tools can detect and measure unwanted/ forwarding rules. Flow identification is often required to avoid
excessive reordering, and the impact on transport performance. significant packet mis-ordering (e.g., when ECMP is used).
Network tools can detect and measure unwanted/excessive
reordering, and the impact on transport performance.
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, and inform decisions about how to progress new of reordering, and inform decisions about how to progress new
mechanisms. mechanisms.
skipping to change at page 17, line 37 skipping to change at page 17, line 37
designers can mitigate these costs by explicitly choosing to expose designers can mitigate these costs by explicitly choosing to expose
selected information as invariants that are guaranteed not to change selected information as invariants that are guaranteed not to change
for a particular protocol (e.g., the header invariants and the spin- for a particular protocol (e.g., the header invariants and the spin-
bit in QUIC [I-D.ietf-quic-transport]). Specification of common log bit in QUIC [I-D.ietf-quic-transport]). Specification of common log
formats and development of alternative approaches can also help formats and development of alternative approaches can also help
mitigate the costs of transport changes. mitigate the costs of transport changes.
2.4. To Support Header Compression 2.4. To Support 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. This has been widely
with low bandwidth dial-up access links, and still finds application used with low bandwidth dial-up access links, and still finds
on wireless links that are subject to capacity constraints. Examples application on wireless links that are subject to capacity
of header compression include use with TCP/IP and RTP/UDP/IP flows constraints. These methods are effective for bit-congestive links
[RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful compression sending small packets (e.g., reducing the cost for sending control
depends on observing the transport headers and understanding of the packets or small data packets over radio links).
way fields change between packets, and is hence incompatible with
header encryption. Devices that compress transport headers are Examples of header compression include use with TCP/IP and RTP/UDP/IP
dependent on a stable header format, implying ossification of that flows [RFC2507], [RFC6846], [RFC2508], [RFC5795]. Successful
format. compression depends on observing the transport headers and
understanding of the way fields change between packets, and is hence
incompatible with header encryption. Devices that compress transport
headers are dependent on a stable header format, implying
ossification of that format.
Introducing a new transport protocol, or changing the format of the Introducing a new transport protocol, or changing the format of the
transport header information, will limit the effectiveness of header transport header information, will limit the effectiveness of header
compression until the network devices are updated. Encrypting the compression until the network devices are updated. Encrypting the
transport protocol headers will tend to cause the header compression transport protocol headers will tend to cause the header compression
to a fall back to compressing only the network layer headers, with a to a fall back to compressing only the network layer headers, with a
significant reduction in efficiency. This can limit connectivity if significant reduction in efficiency. This can limit connectivity if
the resulting flow exceeds the link capacity, or if the packets are the resulting flow exceeds the link capacity, or if the packets are
dropped because they exceed the link MTU. dropped because they exceed the link MTU.
skipping to change at page 26, line 21 skipping to change at page 26, line 30
protocol functionality. This can be done by exposing part of the protocol functionality. This can be done by exposing part of the
transport header or as a network layer option/extension. transport header or as a network layer option/extension.
5.1. Exposing Transport Information in Extension Headers 5.1. Exposing Transport Information in Extension Headers
At the network-layer, packets can carry optional headers that At the network-layer, packets can carry optional headers that
explicitly expose transport header information to the on-path devices explicitly expose transport header information to the on-path devices
operating at the network layer (Section 2.2.2). For example, an operating at the network layer (Section 2.2.2). For example, an
endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide
explicit transport layer information that can be observed and used by explicit transport layer information that can be observed and used by
network devices on the path. network devices on the path. New hop-by-hop options are not
recommended in RFC 8200 [RFC8200] "because nodes may be configured to
ignore the Hop-by-Hop Options header, drop packets containing a Hop-
by-Hop Options header, or assign packets containing a Hop-by-Hop
Options header to a slow processing path. Designers considering
defining new hop-by-hop options need to be aware of this likely
behavior."
Network-layer optional headers explicitly indicate the information Network-layer optional headers explicitly indicate the information
that is exposed, whereas use of exposed transport header information that is exposed, whereas use of exposed transport header information
first requires an observer to identify the transport protocol and its first requires an observer to identify the transport protocol and its
format. (See Section 2.1.) format. (See Section 2.1.)
An arbitrary path can include one or more network devices that drop An arbitrary path can include one or more network devices that drop
packets that include a specific header or option used for this packets that include a specific header or option used for this
purpose (see [RFC7872]). This could impact the proper functioning of purpose (see [RFC7872]). This could impact the proper functioning of
the protocols using the path. Protocol methods can be designed to the protocols using the path. Protocol methods can be designed to
skipping to change at page 27, line 45 skipping to change at page 28, line 14
beyond OAM (see Section 5). There can also be less desirable beyond OAM (see Section 5). There can also be less desirable
implications from separating the operation of the transport protocol implications from separating the operation of the transport protocol
from the measurement framework. from the measurement framework.
6.1. Use of OAM within a Maintenance Domain 6.1. Use of OAM within a Maintenance Domain
OAM information can be added at the ingress to a maintenance domain OAM information can be added at the ingress to a maintenance domain
(e.g., an Ethernet protocol header with timestamps and sequence (e.g., an Ethernet protocol header with timestamps and sequence
number information using a method such as 802.11ag or in-situ OAM number information using a method such as 802.11ag or in-situ OAM
[I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol). [I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol).
The additional header information is typically removed the at the This additional header information is not delivered to the endpoints
egress of the maintenance domain. and is typically removed at the egress of the maintenance domain.
Although some types of measurements are supported, this approach does Although some types of measurements are supported, this approach does
not cover the entire range of measurements described in this not cover the entire range of measurements described in this
document. In some cases, it can be difficult to position measurement document. In some cases, it can be difficult to position measurement
tools at the appropriate segments/nodes and there can be challenges tools at the appropriate segments/nodes and there can be challenges
in correlating the downstream/upstream information when in-band OAM in correlating the downstream/upstream information when in-band OAM
data is inserted by an on-path device. data is inserted by an on-path device.
6.2. Use of OAM across Multiple Maintenance Domains 6.2. Use of OAM across Multiple Maintenance Domains
OAM information can also be added at the network layer as an IPv6 OAM information can also be added at the network layer by the sender
extension header or an IPv4 option. This information can be used as an IPv6 extension header or an IPv4 option, or in an
across multiple network segments, or between the transport endpoints. encapsulation/tunnel header that also includes an extension header or
option. This information can be used 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 a receiving transport endpoint
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 need to be explicitly enabled at the sender. been proposed. This need to be explicitly enabled at the sender.
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
skipping to change at page 33, line 45 skipping to change at page 34, line 20
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Mohamed Boucadair, Spencer Dawkins, The authors would like to thank Mohamed Boucadair, Spencer Dawkins,
Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen
Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris
Wood, Thomas Fossati, Mohamed Boucadair, Martin Thomson, David Black, Wood, Thomas Fossati, Mohamed Boucadair, Martin Thomson, David Black,
Martin Duke, and other members of TSVWG for their comments and Martin Duke, Joel Halpern and members of TSVWG for their comments and
feedback. feedback.
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 688421, research and innovation programme under grant agreement No 688421,
and the EU Stand ICT Call 4. The opinions expressed and arguments and the EU Stand ICT Call 4. The opinions expressed and arguments
employed reflect only the authors' view. The European Commission is employed reflect only the authors' view. The European Commission is
not responsible for any use that might be made of that information. not responsible for any use that might be made of that information.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
skipping to change at page 44, line 4 skipping to change at page 45, line 5
(editorial); Christian Huitema (various); David Black (various). (editorial); Christian Huitema (various); David Black (various).
Amended privacy considerations based on SECDIR review. Emile Stephan Amended privacy considerations based on SECDIR review. Emile 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 -10 Updated following additional feedback from 1st WGLC. Comments
from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter
Gutmann; Ekr; and many others via the TSVWG list. Some people Gutmann; Ekr; and many others via the TSVWG list. Some people
thought that "needed" and "need" could represent requirements in the thought that "needed" and "need" could
document, etc. this has been clarified.
represent requirements in the document, etc. this has been clarified.
-11 Updated following additional feedback from Martin Thomson, and -11 Updated following additional feedback from Martin Thomson, and
corrections from other reviewers. corrections from other reviewers.
-12 Updated following additional feedback from reviewers. -12 Updated following additional feedback from reviewers.
-13 Updated following 2nd WGLC with comments from D.L.Black; T. -13 Updated following 2nd WGLC with comments from D.L.Black; T.
Herbert; Ekr; and other reviewers. Herbert; Ekr; and other reviewers.
-14 Update to resolve feedback to rev -13. This moves the general -14 Update to resolve feedback to rev -13. This moves the general
skipping to change at page 44, line 38 skipping to change at page 45, line 40
-17 Revised to satisfy ID-NITs and updates REFs to latest rev, -17 Revised to satisfy ID-NITs and updates REFs to latest rev,
updated HC Refs; cited IAB guidance on security and privacy within updated HC Refs; cited IAB guidance on security and privacy within
IETF specs. IETF specs.
-18 Revised based on AD review. -18 Revised based on AD review.
-19 Revised after additional AD review request, and request to -19 Revised after additional AD review request, and request to
restructure. restructure.
-20 Revised after directorate reviews and IETF LC comments.
Gen-ART:
o While section 2 does include a discussion of traffic mis-ordering,
it does not include a discussion of ECMP, and the dependence of
ECMP on flow identification to avoid significant packet mis-
ordering.:: ECMP added as example.
o Section 5.1 of this document discusses the use of Hop-by-Hop IPv6
options. It seems that it should acknowledge and discuss the
applicability of the sentence "New hop-by-hop options are not
recommended..." from section 4.8 of RFC 8200. I think a good
argument can be made in this case as to why (based on the rest of
the sentence from 8200) the recommendation does not apply to this
proposal. The document should make the argument.:: Quoted RFC
sentences directly to avoid interpretting them.
o I found the discussion of header compression slightly confusing.
Given that the TCP / UDP header is small even compared to the IP
header, it is difficult to see why encrypting it would have a
significant impact on header compression efficacy. :: Added a
preface that explains that HC methods are most effective for bit-
congestive links.
o The wording in section 6.2 on adding header information to an IP
packet has the drawback of seeming to imply that one could add (or
remove) such information in the network, without adding an
encapsulating header. That is not permitted by RFC 8200 (IPv6).
It would be good to clarify the first paragraph. (The example,
which talks about the sender putting in the information is, of
course, fine.) :: Unintended - added a sentence of preface.
SECDIR:: Previous revisions were updated following Early Review
comments.
OPSEC:: No additional changes were requested in the OPSEC review.
IETF LC:: Tom Herbert: Please refer to 8200 on EH :: addressed in
response to Joel above. Michael Richardson, Fernando Gont, Tom
Herbert: Continuation of discussion on domains where EH might be (or
not) useful and the tussle on what information to reveal. Unclear
yet what additional text should be changed within this ID.
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. 18 change blocks. 
35 lines changed or deleted 94 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/