draft-ietf-tsvwg-transport-encrypt-13.txt   draft-ietf-tsvwg-transport-encrypt-14.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 21, 2020 University of Glasgow Expires: October 5, 2020 University of Glasgow
March 20, 2020 April 03, 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-13 draft-ietf-tsvwg-transport-encrypt-14
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 45 skipping to change at page 1, line 45
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 21, 2020. This Internet-Draft will expire on October 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 5
2.1. Use of Transport Header Information in the Network . . . 6 2.1. Use of Transport Header Information in the Network . . . 6
2.2. Authentication of Transport Header Information . . . . . 7 2.2. Authentication of Transport Header Information . . . . . 8
2.3. Perspectives on Observable Transport Header Fields . . . 8 2.3. Perspectives on Observable Transport Header Fields . . . 8
3. Current uses of Transport Headers within the Network . . . . 11 3. Current uses of Transport Headers within the Network . . . . 12
3.1. Observing Transport Information in the Network . . . . . 12 3.1. Observing Transport Information in the Network . . . . . 12
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 20 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 20
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 23 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 23
3.4. Header Compression . . . . . . . . . . . . . . . . . . . 24 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 25
4. Encryption and Authentication of Transport Headers . . . . . 25 4. Encryption and Authentication of Transport Headers . . . . . 25
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Approaches to Transport Header Protection . . . . . . . . 26 4.2. Approaches to Transport Header Protection . . . . . . . . 26
5. Addition of Transport Information to Network-Layer Headers . 28 5. Addition of Transport OAM Information to Network-Layer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 28
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 28 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29
5.3. Exposing Transport Information at the Network Layer . . . 29 6. Intentionally Exposing Transport Information to the Network . 29
6. Implications of Protecting the Transport Headers . . . . . . 30 6.1. Exposing Transport Information in Extension Headers . . . 29
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 30 6.2. Common Exposed Transport Information . . . . . . . . . . 30
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 32 6.3. Considerations for Exposing Transport Information . . . . 30
6.3. Accountability and Internet Transport Protocols . . . . . 32 7. Implications of Protecting the Transport Headers . . . . . . 31
6.4. Impact on Network Operations . . . . . . . . . . . . . . 33 7.1. Independent Measurement . . . . . . . . . . . . . . . . . 31
6.5. Impact on Research, Development and Deployment . . . . . 34 7.2. Characterising "Unknown" Network Traffic . . . . . . . . 33
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3. Accountability and Internet Transport Protocols . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7.4. Impact on Network Operations . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 7.5. Impact on Research, Development and Deployment . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Informative References . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
Appendix A. Revision information . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
12. Informative References . . . . . . . . . . . . . . . . . . . 41
Appendix A. Revision information . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Transport protocols have supported end-to-end encryption of payload Transport protocols have supported end-to-end encryption of payload
data for many years. Examples include Transport Layer Security (TLS) data for many years. Examples include Transport Layer Security (TLS)
over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure over TCP [RFC8446], Datagram TLS (DTLS) over UDP [RFC6347], Secure
RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic RTP [RFC3711], and TCPcrypt [RFC8548] which permits opportunistic
encryption of the TCP transport payload. Some of these also provide encryption of the TCP transport payload. Some of these also provide
integrity protection of all or part of the transport header. integrity protection of all or part of the transport header.
skipping to change at page 9, line 4 skipping to change at page 9, line 13
observable, it cannot be used by network observable, it cannot be used by network
operators. Some operators might work without operators. Some operators might work without
that information, or some might turn to more that information, or some might turn to more
ambitious ways to collect, estimate, or infer ambitious ways to collect, estimate, or infer
this data. (Operational practises aimed at this data. (Operational practises aimed at
guessing transport parameters are out of scope guessing transport parameters are out of scope
for this document, and are only mentioned here to for this document, and are only mentioned here to
recognise that encryption does not stop operators recognise that encryption does not stop operators
from attempting to apply practises that have been from attempting to apply practises that have been
used with unencrypted transport headers.) used with unencrypted transport headers.)
See also Section 3, Section 5, Section 6.4 and s
(Section 6.5). See also Section 3, Section 5, Section 7.4 and s
(Section 7.5).
Analysis of Aggregate Traffic: Observable transport headers have Analysis of Aggregate Traffic: Observable transport headers have
been utilised to determine which transport been utilised to determine which transport
protocols and features are being used across a protocols and features are being used across a
network segment, and to measure trends in the network segment, and to measure trends in the
pattern of usage. For some use cases, end-to-end pattern of usage. For some use cases, end-to-end
measurements/traces are sufficient and can assist measurements/traces are sufficient and can assist
in developing and debugging new transports and in developing and debugging new transports and
analysing their deployment. In other uses, it is analysing their deployment. In other uses, it is
important to relate observations to specific important to relate observations to specific
skipping to change at page 10, line 35 skipping to change at page 10, line 44
service attacks. Operators often seek to service attacks. Operators often seek to
uniquely disambiguate unwanted traffic. uniquely disambiguate unwanted traffic.
Where flows cannot be disambiguated based on Where flows cannot be disambiguated based on
transport header information, this could result transport header information, this could result
in less-efficient identification of unwanted in less-efficient identification of unwanted
traffic, the introduction of rate limits for traffic, the introduction of rate limits for
uncharacterised traffic, or the use of heuristics uncharacterised traffic, or the use of heuristics
to identify anomalous flows. to identify anomalous flows.
See also Section 6.2 and Section 6.3. See also Section 7.2 and Section 7.3.
Verifiable Data: Observable transport headers can be used to Verifiable Data: Observable transport headers can be used to
provide open and verifiable measurements to provide open and verifiable measurements to
support operations, research, and protocol support operations, research, and protocol
development. The ability of multiple stake development. The ability of multiple stake
holders to review transport header traces helps holders to review transport header traces helps
develop insight into performance and traffic develop insight into performance and traffic
contribution of specific variants of a protocol. contribution of specific variants of a protocol.
Independently observed data is important to help Independently observed data is important to help
ensure the health of the research and development ensure the health of the research and development
skipping to change at page 11, line 9 skipping to change at page 11, line 19
When transport header information can not be When transport header information can not be
observed, this can reduce the range of actors observed, this can reduce the range of actors
that can observe data. This limits the that can observe data. This limits the
information sources available to the Internet information sources available to the Internet
community to understand the operation of community to understand the operation of
transport protocols, reducing information to transport protocols, reducing information to
inform design decisions and standardisation of inform design decisions and standardisation of
the new protocols/features and related the new protocols/features and related
operational practises operational practises
See also Section 6. See also Section 7.
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 the operators and regulators to explore the
compliance with Service Level Agreements (SLAs). compliance with Service Level Agreements (SLAs).
When transport header information can not be When transport header information can not be
observed, other methods have to be found to observed, other methods have to be found to
confirm that the traffic produced conforms to the confirm that the traffic produced conforms to the
expectations of the operator or developer. expectations of the operator or developer.
skipping to change at page 11, line 32 skipping to change at page 11, line 42
be utilised to demonstrate regulatory compliance be utilised to demonstrate regulatory compliance
in some jurisdictions, and as a basis for in some jurisdictions, and as a basis for
informing design decisions. This can bring informing design decisions. This can bring
assurance to those operating networks, often assurance to those operating networks, often
avoiding deployment of complex techniques that avoiding deployment of complex techniques that
routinely monitor and manage Internet traffic routinely monitor and manage Internet traffic
flows (e.g., avoiding the capital and operational flows (e.g., avoiding the capital and operational
costs of deploying flow rate-limiting and network costs of deploying flow rate-limiting and network
circuit-breaker methods [RFC8084]). circuit-breaker methods [RFC8084]).
See also Section 5 and Section 6.1 to See also Section 5 and Section 7.1 to
Section 6.4. Section 7.4.
Note, again, that this is a list of example uses that have been made Note, again, that this is a list of example uses that have been made
of transport header information. It is not an endorsement of any of transport header information. It is not an endorsement of any
particular practice. particular practice.
3. Current uses of Transport Headers within the Network 3. Current uses of Transport Headers within the Network
In response to pervasive monitoring [RFC7624] revelations and the In response to pervasive monitoring [RFC7624] revelations and the
IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258],
efforts are underway to increase encryption of Internet traffic. efforts are underway to increase encryption of Internet traffic.
skipping to change at page 18, line 12 skipping to change at page 18, line 26
service requirements of individual sub-flows. There are several ways service requirements of individual sub-flows. There are several ways
this 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], , and Best Current Practice RFCs (e.g., [RFC8085],
[RFC6437][RFC6438]) encourage endpoints to set the IPv6 Flow label [RFC6437][RFC6438]) encourage endpoints to set the IPv6 Flow label
field of the network-layer header. IPv6 "source nodes SHOULD field of the network-layer header. IPv6 "source nodes SHOULD
assign each unrelated transport connection and application data assign each unrelated transport connection and application data
stream to a new flow" [RFC6437]. A multiplexing transport could stream to a new flow" [RFC6437]. A multiplexing transport could
choose to use multiple Flow labels to allow the network to choose to use multiple Flow labels to allow the network to
independently forward sub-flows. RFC6437 provides further independently forward sub-flows. RFC6437 provides further
guidance on choosing a flow label value, stating these "should be guidance on choosing a flow label value, stating these "should be
chosen such that their bits exhibit a high degree of variability", chosen such that their bits exhibit a high degree of variability",
and chosen so that "third parties should be unlikely to be able to and chosen so that "third parties should be unlikely to be able to
guess the next value that a source of flow labels will choose". guess the next value that a source of flow labels will choose".
skipping to change at page 28, line 15 skipping to change at page 28, line 25
deployment of new methods. This seeks to prevent in-network deployment of new methods. This seeks to prevent in-network
devices utilising the information in a transport header, or can devices utilising the information in a transport header, or can
make an observation robust to a set of changing values, rather make an observation robust to a set of changing values, rather
than a specific set of values. It is not a security mechanism, than a specific set of values. It is not a security mechanism,
although use can be combined with an authentication mechanism. although use can be combined with an authentication mechanism.
As seen, different transports use encryption to protect their header As seen, different transports use encryption to protect their header
information to varying degrees. The trend is towards increased information to varying degrees. The trend is towards increased
protection. protection.
5. Addition of Transport Information to Network-Layer Headers 5. Addition of Transport OAM 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. This approach
could also be less desirable implications of separating the operation also could be applied to methods beyond operations, administration
of the transport protocol from the measurement framework. and management (see Section 6). There can also be less desirable
implications from separating the operation of the transport protocol
from the measurement framework.
5.1. Use of OAM within a Maintenance Domain 5.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 The additional header information is typically removed the at the
egress of the maintenance domain. egress of the maintenance domain.
skipping to change at page 29, line 10 skipping to change at page 29, line 23
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 has to be explicitly enabled at the been proposed. This method has to be explicitly enabled at the
sender. sender.
5.3. Exposing Transport Information at the Network Layer 6. Intentionally Exposing Transport Information to the Network
Network packets can carry optional headers may be used to explicitly A transport protocol can choose to expose certain transport
expose transport header information to the on-path devices operating information to on-path devices operating at the network layer by
at the network layer Section 3.1.3. For example, an endpoint that sending observable fields. One approach is to make an explicit
provides an IPv6 Hop-by-Hop option [RFC8200] can provide explicit choice not to encrypt certain transport header fields, making this
transport layer information that can be observed and used by network transport information observable by the network. Another approach is
devices on the path. to choose to expose transport information through the use of network-
layer extension headers. Both are examples of explicit signals that
the information is intended to be used by network devices on the path
[RFC8558].
When the path includes a network device that drops packets that Whatever the mechanism used to expose the information, a decision to
include a specific option used for this purpose (e.g., see[RFC7872]), only expose specific transport information, places the transport
this impacts the proper functioning of the protocols using the path. endpoint in control of what to expose or not to expose outside of the
Protocol methods can be designed to probe to discover whether the encrypted transport header. This decision can then be made
specific option(s) can be used along the current path, enabling use independently of the transport protocol functionality. This provides
on arbitrary paths. opportunities to standardise the method and format used to expose
this transport information. This can be done by exposing part of the
transport header or as a network layer option/extension.
The transport header information exposed by a transport endpoint can 6.1. Exposing Transport Information in Extension Headers
be different to the (hidden) transport header fields used by the
protocol state machine and could instead be specifically designed to
meet the needs of the network layer [RFC8558]. There are
opportunities for the format and usage of this transport information
to be standardised, providing an opportunity for common
specifications and tools to be used with more than one transport
protocol.
o On the one hand, protocols do not necessarily have an incentive to At the network-layer, packets can carry optional headers (similar to
expose the actual information that is used by the protocol itself Section 5) that may be used to explicitly expose transport header
and could therefore manipulate the exposed transport header information to the on-path devices operating at the network layer
information to gain an advantage from the network. The incentive (Section 3.1.3). For example, an endpoint that sends an IPv6 Hop-by-
to reflect actual transport header information has to be Hop option [RFC8200] can provide explicit transport layer information
considered when proposing a method. that can be observed and used by network devices on the path.
o On the other hand, explicit approaches can simplify tools by An arbitrary path can include one or more network devices that drop
exposing the relevant metrics (loss, latency, etc), rather having packets that include a specific header or option used for this
to derive this from other fields. This could stimulate the purpose (see [RFC7872]). This could impact the proper functioning of
development of proocol-independent tools and also permits the protocols using the path. Protocol methods can be designed to
protocols to evolve independently of the ossified observable probe to discover whether the specific option(s) can be used along
header [RFC8558]. the current path, enabling use on arbitrary paths.
6. Implications of Protecting the Transport Headers 6.2. Common Exposed Transport Information
There are opportunities for multiple transport protocols to
consistently supply common observable information [RFC8558]. A
common approach can result in an open definition of the observable
fields. This has the potential that the same information can be
utilised across a range of operational and analysis tools.
6.3. Considerations for Exposing Transport Information
The motivation to reflect actual transport header information and the
implications of network devices using this information has to be
considered when proposing such a method. RFC8558 summarises this as
"When signals from endpoints to the path are independent from the
signals used by endpoints to manage the flow's state mechanics, they
may be falsified by an endpoint without affecting the peer's
understanding of the flow's state. For encrypted flows, this
divergence is not detectable by on-path devices." [RFC8558].
Considerations concerning the selection of appropriate information to
expose include:
o On the one hand, explicitly exposing derived fields containing
relevant transport information (e.g., metrics for loss, latency,
etc) can avoid network devices needing to derive this information
from other header fields. This could result in development and
evolution of transport-independent tools around a common
observable header, and permit transport protocols to also evolve
independently of this ossified header [RFC8558].
o On the other hand, protocols and implementations may not
consistently expose external information that reflects the actual
internal information used by the protocol itself. An endpoint/
protocol could choose to expose transport header information to
optimise the benefit it gets from the network [RFC8558]. The
value of this information would be enhanced if the exposed
information could be verified to match the internal state of the
transport by observing the transport behaviour.
7. Implications of Protecting the Transport Headers
The choice of which transport header fields to expose and which to The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible. header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to Security work typically employs a design technique that seeks to
expose only what is needed. This approach provides incentives to not expose only what is needed. This approach provides incentives to not
reveal any information that is not necessary for the end-to-end reveal any information that is not necessary for the end-to-end
communication. However, there can be performance and operational communication. However, there can be performance and operational
benefits in exposing selected information to network tools. 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 7.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 have to work in protocols employ a set of mechanisms. Some of these have to work in
cooperation with the network layer for loss detection and recovery, cooperation with the network layer for loss detection and recovery,
congestion detection and control. Others have to work only end-to- congestion detection and control. Others have to work only end-to-
end (e.g., parameter negotiation, flow-control). end (e.g., parameter negotiation, flow-control).
skipping to change at page 32, line 25 skipping to change at page 33, line 25
Despite being applicable in some scenarios, endpoint logs do not Despite being applicable in some scenarios, endpoint logs do not
provide equivalent information to in-network measurements. In provide equivalent information to in-network measurements. In
particular, endpoint logs contain only a part of the information to particular, endpoint logs contain only a part of the information to
understand the operation of network devices and identify issues such understand the operation of network devices and identify issues such
as link performance or capacity sharing between multiple flows. as link performance or capacity sharing between multiple flows.
Additional information has to be combined to determine which Additional information has to be combined to determine which
equipment/links are used and the configuration of equipment along the equipment/links are used and the configuration of equipment along the
network paths being measured. network paths being measured.
6.2. Characterising "Unknown" Network Traffic 7.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
skipping to change at page 32, line 47 skipping to change at page 33, line 47
appropriate safety measures have 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 has to be considered in determining The level and style of encryption has to be considered in determining
how this activity is performed. On a shorter timescale, information how this activity is performed. On a shorter timescale, information
could also have to be collected to manage denial of service attacks could also have to be collected to manage denial of service attacks
against the infrastructure. against the infrastructure.
6.3. Accountability and Internet Transport Protocols 7.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 has 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 Network Operations 7.4. Impact on Network Operations
Some network operators currently use observed transport header 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 techniques that use information observed in developed tools and techniques that use information observed in
currently deployed transports and their applications. A variety of currently deployed transports and their applications. A variety of
open source and proprietary tools have been deployed that use this open source and proprietary tools have been deployed that use this
information for a variety of short and long term measurements. information for a variety of short and long term measurements.
Encryption of the transport header information prevents tooling from Encryption of the transport header information prevents tooling from
directly observing the transport header information, limiting its directly observing the transport header information, limiting its
utility. utility.
skipping to change at page 34, line 5 skipping to change at page 35, line 5
These costs are incurred by an operator to manage the service and These costs are incurred by an operator to manage the service and
debug network issues. debug network issues.
At the time of writing, the overall operational impact of using At the time of writing, the overall operational impact 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 7.5. Impact on Research, Development and Deployment
Transport protocol evolution, and the ability to measure and Transport protocol evolution, and the ability to measure and
understand the impact of protocol changes, have to proceed hand-in- understand the impact of protocol changes, have to proceed hand-in-
hand. A transport protocol that provides observable headers can be hand. A transport protocol that provides observable headers can be
used to provide open and verifiable measurement data. Observation of used to provide open and verifiable measurement data. Observation of
pathologies has a critical role in the design of transport protocol pathologies has a critical role in the design of transport protocol
mechanisms and development of new mechanisms and protocols. This mechanisms and development of new mechanisms and protocols. This
helps understanding the interactions between cooperating protocols helps understanding the interactions between cooperating protocols
and network mechanism, the implications of sharing capacity with and network mechanism, the implications of sharing capacity with
other traffic and the impact of different patterns of usage. The other traffic and the impact of different patterns of usage. The
skipping to change at page 35, line 18 skipping to change at page 36, line 18
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
desire to include independent observation and evaluation of desire to include independent observation and evaluation of
performance data, which in turn demands control over where and when performance data, which in turn demands control over where and when
measurement samples are collected. This requires consideration of measurement samples are collected. This requires consideration of
the methods used to observe data and the appropriate balance between the methods used to observe data and the appropriate balance between
encrypting all and no transport header information. encrypting all and no transport header information.
7. Conclusions 8. 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.
This document has described some current practises, and the This document has described some current practises, and the
skipping to change at page 38, line 9 skipping to change at page 39, line 9
As [RFC7258] notes, "Making networks unmanageable to mitigate As [RFC7258] notes, "Making networks unmanageable to mitigate
(pervasive monitoring) is not an acceptable outcome, but ignoring (pervasive monitoring) is not an acceptable outcome, but ignoring
(pervasive monitoring) would go against the consensus documented (pervasive monitoring) would go against the consensus documented
here." Providing explicit information can help avoid traffic being here." Providing explicit information can help avoid traffic being
inappropriately classified, impacting application performance. An inappropriately classified, impacting application performance. An
appropriate balance will emerge over time as real instances of this appropriate balance will emerge over time as real instances of this
tension are analysed [RFC7258]. This balance between information tension are analysed [RFC7258]. This balance between information
exposed and information hidden ought to be carefully considered when exposed and information hidden ought to be carefully considered when
specifying new transport protocols. specifying new transport protocols.
8. Security Considerations 9. 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
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].
skipping to change at page 40, line 19 skipping to change at page 41, line 19
between encrypting all and no transport header information. Open between encrypting all and no transport header information. Open
data, and accessibility to tools that can help understand trends in data, and accessibility to tools that can help understand trends in
application deployment, network traffic and usage patterns can all application deployment, network traffic and usage patterns can all
contribute to understanding security challenges. contribute to understanding security challenges.
The Security and Privacy Considerations in the Framework for Large- The Security and Privacy Considerations in the Framework for Large-
Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain
considerations for Active and Passive measurement techniques and considerations for Active and Passive measurement techniques and
supporting material on measurement context. supporting material on measurement context.
9. IANA Considerations Addition of observable signals to the path increases the information
available to an observer and may, when the information can be linked
to a node or user, reduce the privacy of the user. See the security
considerations of [RFC8558].
10. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgements 11. 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, Martin Thomson, David Black, and other members Wood, Thomas Fossati, Martin Thomson, David Black, and other members
of the TSVWG for their comments and feedback. of the TSVWG for their comments and feedback.
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 688421, research and innovation programme under grant agreement No 688421,
and the EU Stand ICT Call 4. The opinions expressed and arguments and the EU Stand ICT Call 4. The opinions expressed and arguments
employed reflect only the authors' view. The European Commission is employed reflect only the authors' view. The European Commission is
not responsible for any use that might be made of that information. not responsible for any use that might be made of that information.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
11. Informative References 12. Informative References
[bufferbloat] [bufferbloat]
Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in
the Internet. Communications of the ACM, 55(1):57-65", the Internet. Communications of the ACM, 55(1):57-65",
January 2012. January 2012.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
skipping to change at page 50, line 15 skipping to change at page 51, line 15
document, etc. this has been clarified. 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
discussion of adding fields to transport packets to section 6, and
discusses with reference to material in RFC8558.
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. 34 change blocks. 
79 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/