draft-ietf-tsvwg-transport-encrypt-01.txt   draft-ietf-tsvwg-transport-encrypt-02.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: April 25, 2019 University of Glasgow Expires: May 29, 2019 University of Glasgow
October 22, 2018 November 25, 2018
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-01 draft-ietf-tsvwg-transport-encrypt-02
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 April 25, 2019. This Internet-Draft will expire on May 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3
3. Current uses of Transport Headers within the Network . . . . 9 3. Current uses of Transport Headers within the Network . . . . 10
3.1. Observing Transport Information in the Network . . . . . 9 3.1. Observing Transport Information in the Network . . . . . 10
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 18 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 19
3.4. Observing Headers to Implement Network Policy . . . . . . 19 3.4. Use of transport information to influence network
4. Encryption and Authentication of Transport Headers . . . . . 19 forwarding . . . . . . . . . . . . . . . . . . . . . . . 20
4. Encryption and Authentication of Transport Headers . . . . . 21
5. Addition of Transport Information to Network-Layer Protocol 5. Addition of Transport Information to Network-Layer Protocol
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Implications of Protecting the Transport Headers . . . . . . 24 5.1. Use of transport information to influence network
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 24 forwarding . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 25 5.2. Network-layer measurement . . . . . . . . . . . . . . . . 27
6.3. Accountability and Internet Transport Protocols . . . . . 25 6. Implications of Protecting the Transport Headers . . . . . . 28
6.4. Impact on Research, Development and Deployment . . . . . 26 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 28
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.3. Accountability and Internet Transport Protocols . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6.4. Impact on Research, Development and Deployment . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
Appendix A. Revision information . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
11. Informative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. Revision information . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
We are seeing increased interest in, and deployment of, new protocols There is increased interest in, and deployment of, new protocols that
that employ end-to-end encryption at the transport layer, including employ end-to-end encryption at the transport layer, including the
the transport layer headers. An example of such a transport is the transport layer headers. An example of such a transport is the QUIC
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, and we strongly support These benefits have been widely discussed, and we strongly support
them. There are also, however, some costs, in that the wide use of them. There are also, however, some costs, in that the wide use of
transport encryption requires changes to network operations, and transport encryption requires changes to network operations, and
complicates network measurement for research, operational, and complicates network measurement for research, operational, and
standardisation purposes. standardisation purposes.
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
skipping to change at page 3, line 45 skipping to change at page 3, line 49
robust Internet (e.g., [RFC1273]). In turn, the network operations robust Internet (e.g., [RFC1273]). In turn, the network operations
community relies on being able to understand the pattern and community relies on being able to understand the pattern and
requirements of traffic passing over the Internet, both in aggregate requirements of traffic passing over the Internet, both in aggregate
and at the flow level. and at the flow level.
There are many motivations for deploying encrypted transports There are many motivations for deploying encrypted transports
[RFC7624] (i.e., transport protocols that use encryption to provide [RFC7624] (i.e., transport protocols that use encryption to provide
confidentiality of some or all of the transport-layer header confidentiality of some or all of the transport-layer header
information), and encryption of transport payloads (i.e. information), and encryption of transport payloads (i.e.
confidentiality of the payload data). The increasing public concerns confidentiality of the payload data). The increasing public concerns
about the interference with Internet traffic have led to a rapidly about interference with Internet traffic have led to a rapidly
expanding deployment of encryption to protect end-user privacy, in expanding deployment of encryption to protect end-user privacy, e.g.,
protocols like QUIC [I-D.ietf-quic-transport], but also expected to QUIC [I-D.ietf-quic-transport]. Encryption is also expected to form
form a basis of future protocol designs. a basis of future transport protocol designs.
Some network operators and access providers have come to rely on the Some network operators and access providers have come to rely on the
in-network measurement of transport properties and the functionality in-network measurement of transport properties and the functionality
provided by middleboxes to both support network operations and provided by middleboxes to both support network operations and
enhance performance. There can therefore be implications when enhance performance. There can therefore be implications when
working with encrypted transport protocols that hide transport header working with encrypted transport protocols that hide transport header
information from the network. These present architectural challenges information from the network. These present architectural challenges
and considerations in the way transport protocols are designed, and and considerations in the way transport protocols are designed, and
ability to characterise and compare different transport solutions ability to characterise and compare different transport solutions
[Measure]. Implementations of network devices are encouraged to [Measure]. Implementations of network devices are encouraged to
skipping to change at page 4, line 50 skipping to change at page 5, line 8
unknown TCP options, that drop segments with unknown TCP options, unknown TCP options, that drop segments with unknown TCP options,
that drop segments that contain data and have the SYN bit set, that that drop segments that contain data and have the SYN bit set, that
drop packets with SYN/ACK that acknowledge data, or that disrupt drop packets with SYN/ACK that acknowledge data, or that disrupt
connections that send data before the three-way handshake completes. connections that send data before the three-way handshake completes.
In both cases, the issue was caused by middleboxes that had a hard- In both cases, the issue was caused by middleboxes that had a hard-
coded understanding of transport behaviour, and that interacted coded understanding of transport behaviour, and that interacted
poorly with transports that tried to change that behaviour. Other poorly with transports that tried to change that behaviour. Other
examples have included middleboxes that rewrite TCP sequence and examples have included middleboxes that rewrite TCP sequence and
acknowledgement numbers but are unaware of the (newer) SACK option acknowledgement numbers but are unaware of the (newer) SACK option
and don't correctly rewrite selective acknowledgements to match the and don't correctly rewrite selective acknowledgements to match the
changes made to the fixed TCP header; or devices that inspect, and changes made to the fixed TCP header.
change, TCP MSS options that can interfere with path MTU discovery.
A protocol design that uses header encryption can provide A protocol design that uses header encryption can provide
confidentiality of some or all of the protocol header information. confidentiality of some or all of the protocol header information.
This prevents an on-path device from knowledge of the header field. This prevents an on-path device from knowledge of the header field.
It therefore prevents mechanisms being built that directly rely on It therefore prevents mechanisms being built that directly rely on
the information or seek to imply semantics of an exposed header the information or seek to infer semantics of an exposed header
field. Using encryption to provide confidentiality of the transport field. Using encryption to provide confidentiality of the transport
layer brings some well-known privacy and security benefits and can layer brings some well-known privacy and security benefits and can
therefore help reduce ossification of the transport layer. In therefore help reduce ossification of the transport layer. In
particular, it is important that protocols either do not expose particular, it is important that protocols either do not expose
information where the usage may change in future protocols, or that information where the usage could change in future protocols, or that
methods that utilise the information are robust to potential changes methods that utilise the information are robust to potential changes
as protocols evolve over time. To avoid unwanted inspection, a as protocols evolve over time. To avoid unwanted inspection, a
protocol could also intentionally vary the format and value of header protocol could also intentionally vary the format and/or value of
fields (sometimes known as Greasing [I-D.thomson-quic-grease]). header fields (sometimes known as Greasing
However, while encryption hides the protocol header information, it [I-D.thomson-quic-grease]). However, while encryption hides the
does not prevent ossification of the network service: People seeking protocol header information, it does not prevent ossification of the
understanding of network traffic could come to rely on pattern network service: People seeking understanding of network traffic
inferences and other heuristics as the basis for network decision and could come to rely on pattern inferences and other heuristics as the
to derive measurement data, creating new dependencies on the basis for network decision and to derive measurement data, creating
transport protocol. new dependencies on the transport protocol.
A level of ossification of the transport header can offer trade-offs Specification of non-encrypted transport header fields explicitly
around authentication, and confidentiality of transport protocol allows protocol designers to make specific header information
headers and has the potential to explicitly support for other uses of observable in the network. This supports other uses of this
this header information. For example, a design that provides information by on-path devices, and at the same time this can be
expected to lead to ossification of the transport header, because
network forwarding could evolve to depend on the presence and/or
value of these fields. The decision about which transport headers
fields are made observable offers trade-offs around authentication,
and confidentiality. For example, a design that provides
confidentiality of protocol header information can impact the confidentiality of protocol header information can impact the
following activities that rely on measurement and analysis of traffic following activities that rely on measurement and analysis of traffic
flows: flows:
Network Operations and Research: Observable transport headers enable Network Operations and Research: Observable transport headers enable
both operators and the research community to measure and analyse both operators and the research community to measure and analyse
protocol performance, network anomalies, and failure pathologies. protocol performance, network anomalies, and failure pathologies.
This information can help inform capacity planning, and assist in This information can help inform capacity planning, and assist in
determining the need for equipment and/or configuration changes by determining the need for equipment and/or configuration changes by
skipping to change at page 6, line 11 skipping to change at page 6, line 23
some, or all, of the transport headers unencrypted, possibly with some, or all, of the transport headers unencrypted, possibly with
authentication, can provide the majority of the privacy and authentication, can provide the majority of the privacy and
security benefits while supporting operations and research. security benefits while supporting operations and research.
Protection from Denial of Service: Observable transport headers Protection from Denial of Service: Observable transport headers
currently provide useful input to classify traffic and detect currently provide useful input to classify traffic and detect
anomalous events (e.g., changes in application behaviour, anomalous events (e.g., changes in application behaviour,
distributed denial of service attacks). To be effective, this distributed denial of service attacks). To be effective, this
protection needs to be able to uniquely disambiguate unwanted protection needs to be able to uniquely disambiguate unwanted
traffic. An inability to separate this traffic using packet traffic. An inability to separate this traffic using packet
header information may result in less-efficient identification of header information could result in less-efficient identification
unwanted traffic or development of different methods (e.g. rate- of unwanted traffic or development of different methods (e.g.
limiting of uncharacterised traffic). rate-limiting of uncharacterised traffic).
Network Troubleshooting and Diagnostics: Encrypting transport Network Troubleshooting and Diagnostics: Encrypting transport
header information eliminates the incentive for operators to header information eliminates the incentive for operators to
troubleshoot what they cannot interpret. A flow experiencing troubleshoot what they cannot interpret. A flow experiencing
packet loss or jitter looks like an unaffected flow when only packet loss or jitter looks like an unaffected flow when only
observing network layer headers (if transport sequence numbers and observing network layer headers (if transport sequence numbers and
flow identifiers are obscured). This limits understanding of the flow identifiers are obscured). This limits understanding of the
impact of packet loss or latency on the flows, or even localizing impact of packet loss or latency on the flows, or even localizing
the network segment causing the packet loss or latency. Encrypted the network segment causing the packet loss or latency. Encrypted
traffic may imply "don't touch" to some, and could limit a traffic could imply "don't touch" to some, and could limit a
trouble-shooting response to "can't help, no trouble found". The trouble-shooting response to "can't help, no trouble found". The
additional mechanisms that will need to be introduced to help additional mechanisms that will need to be introduced to help
reconstruct transport-level metrics add complexity and operational reconstruct transport-level metrics add complexity and operational
costs (e.g., in deploying additional functions in equipment or costs (e.g., in deploying additional functions in equipment or
adding traffic overhead). adding traffic overhead).
Network Traffic Analysis: Hiding transport protocol header Network Traffic Analysis: Hiding transport protocol header
information can make it harder to determine which transport information can make it harder to determine which transport
protocols and features are being used across a network segment and protocols and features are being used across a network segment and
to measure trends in the pattern of usage. This could impact the to measure trends in the pattern of usage. This could impact the
ability for an operator to anticipate the need for network ability for an operator to anticipate the need for network
upgrades and roll-out. It can also impact the on-going traffic upgrades and roll-out. It can also impact the on-going traffic
engineering activities performed by operators (such as determining engineering activities performed by operators (such as determining
which parts of the path contribute delay, jitter or loss). While which parts of the path contribute delay, jitter or loss). While
the impact may, in many cases, be small there are scenarios where the impact could, in many cases, be small there are scenarios
operators directly support particular services (e.g., to where operators directly support particular services (e.g., to
troubleshoot issues relating to Quality of Service, QoS; the troubleshoot issues relating to Quality of Service, QoS; the
ability to perform fast re-routing of critical traffic, or support ability to perform fast re-routing of critical traffic, or support
to mitigate the characteristics of specific radio links). The to mitigate the characteristics of specific radio links). The
more complex the underlying infrastructure the more important this more complex the underlying infrastructure the more important this
impact. impact.
Open and Verifiable Network Data: Hiding transport protocol header Open and Verifiable Network Data: Hiding transport protocol header
information can reduce the range of actors that can capture useful information can reduce the range of actors that can capture useful
measurement data. For example, one approach could be to employ an measurement data. For example, one approach could be to employ an
existing transport protocol that reveals little information (e.g., existing transport protocol that reveals little information (e.g.,
skipping to change at page 7, line 26 skipping to change at page 7, line 38
topologies, vendor equipment, and traffic patterns that are topologies, vendor equipment, and traffic patterns that are
evaluated. evaluated.
Independently captured data is important to help ensure the health Independently captured data is important to help ensure the health
of the research and development communities. It can provide input of the research and development communities. It can provide input
and test scenarios to support development of new transport and test scenarios to support development of new transport
protocol mechanisms, especially when this analysis can be based on protocol mechanisms, especially when this analysis can be based on
the behaviour experienced in a diversity of deployed networks. the behaviour experienced in a diversity of deployed networks.
Independently verifiable performance metrics might also be Independently verifiable performance metrics might also be
important to demonstrate regulatory compliance in some utilised to demonstrate regulatory compliance in some
jurisdictions, and provides an important basis for informing jurisdictions, and provides a basis for informing design
design decisions. decisions.
The last point leads us to consider the impact of hiding transport The last point leads us to consider the impact of hiding transport
headers in the specification and development of protocols and headers in the specification and development of protocols and
standards. This has potential impact on: standards. This has potential impact on:
o Understanding Feature Interactions: An appropriate vantage point, o Understanding Feature Interactions: An appropriate vantage point,
coupled with timing information about traffic flows, provides a coupled with timing information about traffic flows, provides a
valuable tool for benchmarking equipment, functions, and/or valuable tool for benchmarking equipment, functions, and/or
configurations, and to understand complex feature interactions. configurations, and to understand complex feature interactions.
An inability to observe transport protocol information can limit An inability to observe transport protocol information can limit
skipping to change at page 8, line 12 skipping to change at page 8, line 24
flexibility can be beneficial, but it can come at the cost of flexibility can be beneficial, but it can come at the cost of
fragmenting the ecosystem. There is little doubt that developers fragmenting the ecosystem. There is little doubt that developers
will try to produce high quality transports for their intended will try to produce high quality transports for their intended
target uses, but it is not clear there are sufficient incentives target uses, but it is not clear there are sufficient incentives
to ensure good practice that benefits the wide diversity of to ensure good practice that benefits the wide diversity of
requirements for the Internet community as a whole. Increased requirements for the Internet community as a whole. Increased
diversity, and the ability to innovate without public scrutiny, diversity, and the ability to innovate without public scrutiny,
risks point solutions that optimise for specific needs, but risks point solutions that optimise for specific needs, but
accidentally disrupt operations of/in different parts of the accidentally disrupt operations of/in different parts of the
network. The social contract that maintains the stability of the network. The social contract that maintains the stability of the
Internet relies on accepting common specifications, and on the Internet relies on accepting common specifications.
ability to verify that others also conform.
o Operational practice: Published transport specifications allow o Operational Practice: The network operations community relies on
operators to check compliance. This can bring assurance to those being able to understand the pattern and requirements of traffic
passing over the Internet, both in aggregate and at the flow
level. These operational practices have developed based on the
information available from unencrypted transport headers. If this
information is only carried in encrypted transport headers,
operators will not be able to use this information directly, but
if operators still wish to use these practices, they may turn to
more ambitious ways of discovering this information. For example,
if an operator wants to know that traffic is audio traffic, and no
longer has access to Session Description Protocol (SDP) session
descriptions that would explicitly say a flow "is audio", the
operator might use heuristics to guess that short UDP packets with
regular spacing are carrying audio traffic. Operational practices
aimed at guessing transport parameters are out of scope for this
document, and are only mentioned here to recognize that encryption
may not prevent operators from attempting to apply the same
practices they used with unencrypted transport headers.
o Compliance: Published transport specifications allow operators and
regulators to check compliance. This can bring assurance to those
operating networks, often avoiding the need to deploy complex operating networks, often avoiding the need to deploy complex
techniques that routinely monitor and manage TCP/IP traffic flows techniques that routinely monitor and manage TCP/IP traffic flows
(e.g. Avoiding the capital and operational costs of deploying (e.g. Avoiding the capital and operational costs of deploying
flow rate-limiting and network circuit-breaker methods [RFC8084]). flow rate-limiting and network circuit-breaker methods [RFC8084]).
When it is not possible to observe transport header information, When it is not possible to observe transport header information,
methods are still needed to confirm that the traffic produced methods are still needed to confirm that the traffic produced
conforms to the expectations of the operator or developer. conforms to the expectations of the operator or developer.
o Restricting research and development: Hiding transport information o Restricting research and development: Hiding transport information
can impede independent research into new mechanisms, measurement can impede independent research into new mechanisms, measurement
skipping to change at page 8, line 48 skipping to change at page 9, line 30
deployment) deployment)
In summary, there are trade offs. On the one hand, protocol In summary, there are trade offs. On the one hand, protocol
designers have often ignored the implications of whether the designers have often ignored the implications of whether the
information in transport header fields can or will be used by in- information in transport header fields can or will be used by in-
network devices, and the implications this places on protocol network devices, and the implications this places on protocol
evolution. This motivates a design that provides confidentiality of evolution. This motivates a design that provides confidentiality of
the header information. On the other hand, it can be expected that a the header information. On the other hand, it can be expected that a
lack of visibility of transport header information can impact the lack of visibility of transport header information can impact the
ways that protocols are deployed, standardised, and their operational ways that protocols are deployed, standardised, and their operational
support. The choice of whether future transport protocols encrypt support.
their protocol headers therefore needs to be taken based not solely
on security and privacy considerations, but also taking into account To achieve stable Internet operations the IETF transport community
the impact on operations, standards, and research. Any new Internet has to date relied heavily on measurement and insights of the network
transport need to provide appropriate transport mechanisms and operations community to understand the trade-offs, and to inform
selection of appropriate mechanisms, to ensure a safe, reliable, and
robust Internet (e.g., [RFC1273],[RFC2914]).
The choice of whether future transport protocols encrypt their
protocol headers therefore needs to be taken based not solely on
security and privacy considerations, but also taking into account the
impact on operations, standards, and research. Any new Internet
transport will need to provide appropriate transport mechanisms and
operational support to assure the resulting traffic can not result in operational support to assure the resulting traffic can not result in
persistent congestion collapse [RFC2914]. This document suggests persistent congestion collapse [RFC2914]. This document suggests
that the balance between information exposed and concealed should be that the balance between information exposed and concealed should be
carefully considered when specifying new protocols. carefully considered when specifying new protocols.
3. Current uses of Transport Headers within the Network 3. Current uses of Transport Headers within the Network
Despite transport headers having end-to-end meaning, some of these Despite transport headers having end-to-end meaning, some of these
transport headers have come to be used in various ways within the transport headers have come to be used in various ways within the
Internet. In response to pervasive monitoring [RFC7624] revelations Internet. In response to pervasive monitoring [RFC7624] revelations
skipping to change at page 9, line 41 skipping to change at page 10, line 36
3.1. Observing Transport Information in the Network 3.1. Observing Transport Information in the Network
If in-network observation of transport protocol headers is needed, If in-network observation of transport protocol headers is needed,
this requires knowledge of the format of the transport header: this requires knowledge of the format of the transport header:
o Flows need to be identified at the level required to perform the o Flows need to be identified at the level required to perform the
observation; observation;
o The protocol and version of the header need to be visible, e.g., o The protocol and version of the header need to be visible, e.g.,
by defining the wire image [I-D.trammell-wire-image]. As by defining the wire image [I-D.trammell-wire-image]. As
protocols evolve over time and there may be a need to introduce protocols evolve over time and there could be a need to introduce
new transport headers. This could require interpretation of new transport headers. This could require interpretation of
protocol version information or connection setup information; protocol version information or connection setup information;
o The location and syntax of any observed transport headers needs to o The location and syntax of any observed transport headers needs to
be known. IETF transport protocols can specify this information. be known. IETF transport protocols can specify this information.
The following subsections describe various ways that observable The following subsections describe various ways that observable
transport information has been utilised. transport information has been utilised.
3.1.1. Flow Identification 3.1.1. Flow Identification
skipping to change at page 10, line 43 skipping to change at page 11, line 35
Some actors manage their portion of the Internet by characterizing Some actors manage their portion of the Internet by characterizing
the performance of link/network segments. Passive monitoring uses the performance of link/network segments. Passive monitoring uses
observed traffic to makes inferences from transport headers to derive observed traffic to makes inferences from transport headers to derive
these measurements. A variety of open source and commercial tools these measurements. A variety of open source and commercial tools
have been deployed that utilise this information. The following have been deployed that utilise this information. The following
metrics can be derived from transport header information: metrics can be derived from transport header information:
Traffic Rate and Volume: Header information e.g., (sequence number, Traffic Rate and Volume: Header information e.g., (sequence number,
length) allows derivation of volume measures per-application, to length) allows derivation of volume measures per-application, to
characterise the traffic that uses a network segment or the characterise the traffic that uses a network segment or the
pattern of network usage. This may be measured per endpoint or pattern of network usage. This can be measured per endpoint or
for an aggregate of endpoints (e.g., by an operator to assess for an aggregate of endpoints (e.g., by an operator to assess
subscriber usage). It can also be used to trigger measurement- subscriber usage). It can also be used to trigger measurement-
based traffic shaping and to implement QoS support within the based traffic shaping and to implement QoS support within the
network and lower layers. Volume measures can be valuable for network and lower layers. Volume measures can be valuable for
capacity planning (providing detail of trends rather than the capacity planning (providing detail of trends rather than the
volume per subscriber). volume per subscriber).
Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g.,
from sequence number) and has been used as a metric for from sequence number) and has been used as a metric for
performance assessment and to characterise transport behaviour. performance assessment and to characterise transport behaviour.
Understanding the root cause of loss can help an operator Understanding the root cause of loss can help an operator
determine whether this requires corrective action. Network determine whether this requires corrective action. Network
operators have used the variation in patterns of loss as a key operators have used the variation in patterns of loss as a key
performance metric, utilising this to detect changes in the performance metric, utilising this to detect changes in the
offered service. offered service.
There are various causes of loss, including: corruption of link There are various causes of loss, including: corruption of link
frames (e.g., interference on a radio link), buffer overflow frames (e.g., interference on a radio link), buffer overflow
(e.g., due to congestion), policing (traffic management), buffer (e.g., due to congestion), policing (traffic management), buffer
management (e.g., Active Queue Management, AQM [RFC7567]), management (e.g., Active Queue Management, AQM [RFC7567]),
inadequate provision of traffic preemption. Understanding flow inadequate provision of traffic preemption. Understanding flow
loss rate requires either maintaining per flow packet counters or loss rate requires either maintaining per flow packet counters or
by observing sequence numbers in transport headers. Loss can be by observing sequence numbers in transport headers. Loss can be
monitored at the interface level by devices in the network. It is monitored at the interface level by devices in the network. It is
often important to understand the conditions under which packet often valuable to understand the conditions under which packet
loss occurs. This usually requires relating loss to the traffic loss occurs. This usually requires relating loss to the traffic
flowing on the network node/segment at the time of loss. flowing on the network node/segment at the time of loss.
Observation of transport feedback information (observing loss Observation of transport feedback information (observing loss
reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK) reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK)
can increase understanding of the impact of loss and help identify can increase understanding of the impact of loss and help identify
cases where loss may have been wrongly identified, or the cases where loss could have been wrongly identified, or the
transport did not require the lost packet. It is sometimes more transport did not require the lost packet. It is sometimes more
important to understand the pattern of loss, than the loss rate, helpful to understand the pattern of loss, than the loss rate,
because losses can often occur as bursts, rather than randomly- because losses can often occur as bursts, rather than randomly-
timed events. timed events.
Throughput and Goodput: The throughput achieved by a flow can be Throughput and Goodput: The throughput achieved by a flow can be
determined even when a flow is encrypted, providing the individual determined even when a flow is encrypted, providing the individual
flow can be identified. Goodput [RFC7928] is a measure of useful flow can be identified. Goodput [RFC7928] is a measure of useful
data exchanged (the ratio of useful/total volume of traffic sent data exchanged (the ratio of useful/total volume of traffic sent
by a flow). This requires ability to differentiate loss and by a flow). This requires ability to differentiate loss and
retransmission of packets (e.g., by observing packet sequence retransmission of packets (e.g., by observing packet sequence
numbers in the TCP or the Real-time Transport Protocol, RTP, numbers in the TCP or the Real-time Transport Protocol, RTP,
skipping to change at page 12, line 11 skipping to change at page 12, line 52
in network buffers has often been observed as a significant in network buffers has often been observed as a significant
factor. Once the cause of unwanted latency has been identified, factor. Once the cause of unwanted latency has been identified,
this can often be eliminated. this can often be eliminated.
To measure latency across a part of a path, an observation point To measure latency across a part of a path, an observation point
can measure the experienced round trip time (RTT) using packet can measure the experienced round trip time (RTT) using packet
sequence numbers, and acknowledgements, or by observing header sequence numbers, and acknowledgements, or by observing header
timestamp information. Such information allows an observation timestamp information. Such information allows an observation
point in the network to determine not only the path RTT, but also point in the network to determine not only the path RTT, but also
to measure the upstream and downstream contribution to the RTT. to measure the upstream and downstream contribution to the RTT.
This has been used to locate a source of latency, e.g., by This could be used to locate a source of latency, e.g., by
observing cases where the ratio of median to minimum RTT is large observing cases where the median RTT is much greater than the
for a part of a path. minimum RTT for a part of a path.
The service offered by operators can benefit from latency The service offered by operators can benefit from latency
information to understand the impact of deployment and tune information to understand the impact of deployment and tune
deployed services. Latency metrics are key to evaluating and deployed services. Latency metrics are key to evaluating and
deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
could identify excessively large buffers, indicating where to could identify excessively large buffers, indicating where to
deploy or configure AQM. An AQM method is often deployed in deploy or configure AQM. An AQM method is often deployed in
combination with other techniques, such as scheduling [RFC7567] combination with other techniques, such as scheduling [RFC7567]
[RFC8290] and although parameter-less methods are desired [RFC8290] and although parameter-less methods are desired
skipping to change at page 13, line 17 skipping to change at page 14, line 10
Metrics have been defined that evaluate whether a network has Metrics have been defined that evaluate whether a network has
maintained packet order on a packet-by-packet basis [RFC4737] and maintained packet order on a packet-by-packet basis [RFC4737] and
[RFC5236]. [RFC5236].
Techniques for measuring reordering typically observe packet sequence Techniques for measuring reordering typically observe packet sequence
numbers. Some protocols provide in-built monitoring and reporting numbers. Some protocols provide in-built monitoring and reporting
functions. Transport fields in the RTP header [RFC3550] [RFC4585] functions. Transport fields in the RTP header [RFC3550] [RFC4585]
can be observed to derive traffic volume measurements and provide can be observed to derive traffic volume measurements and provide
information on the progress and quality of a session using RTP. As information on the progress and quality of a session using RTP. As
with other measurement, metadata is often important to understand the with other measurement, metadata is often needed to understand the
context under which the data was collected, including the time, context under which the data was collected, including the time,
observation point, and way in which metrics were accumulated. The observation point, and way in which metrics were accumulated. The
RTCP protocol directly reports some of this information in a form RTCP protocol directly reports some of this information in a form
that can be directly visible in the network. A user of summary that can be directly visible in the network. A user of summary
measurement data needs to trust the source of this data and the measurement data needs to trust the source of this data and the
method used to generate the summary information. method used to generate the summary information.
3.1.3. Metrics derived from Network Layer Headers 3.1.3. Transport use of Network Layer Header Fields
Some transport information is made visible in the network-layer Network-layer classification methods that rely on a multi-field
protocol header. These header fields are not encrypted and have been classifier (e.g. infering QoS from the 5-tuple or choice of
utilised to make flow observations. application protocol) are incompatible with transport protocols that
encrypt the transport information.
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged In contrast, network-layer header fields are not encrypted and can
expose flow information in the IPv6 Flow Label field of the explicitly provide information from the transport layer to enable a
network-layer header (e.g., [RFC8085]). This can be used to different forwarding treatment by the network. This information can
be provided by a transport that employs encryption.
When a transport multiplexes multiple subflows, the user of the
transport could wish to hide the presence and characteristics of
these subflows. other uses of an encrypted transport could set the
network-layer information to indicate the presence of subflows and to
reflect the network needs of individual subflows (e.g., a WebRTC can
identify different forwarding treatments for individual packets based
on the value of the Differentiated Services Code Point (DSCP) field
[I-D.ietf-tsvwg-rtcweb-qos]).
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged to
set the IPv6 Flow Label field of the network-layer header (e.g.,
[RFC8085]). The label can provide information that can help
inform network-layer queuing, forwarding (e.g., for Equal Cost inform network-layer queuing, forwarding (e.g., for Equal Cost
Multi-Path, ECMP, routing, and Link Aggregation, LAG). This can Multi-Path, ECMP, routing, and Link Aggregation, LAG) [RFC6294].
provide useful information to assign packets to flows in the data A multiplexing transport could choose to use multiple flow labels
collected by measurement campaigns. Although important to to allow the network to independently forward subflows.
characterising a path, it does not directly provide performance
data.
Use Network-Layer Differentiated Services Code Point Point: Use Network-Layer Differentiated Services Code Point Point:
Applications can expose their delivery expectations to the network Applications can expose their delivery expectations to the network
by setting the Differentiated Services Code Point (DSCP) field of by setting the DSCP field of IPv4 and IPv6 packets [RFC2474].This
IPv4 and IPv6 packets. This can be used to inform network-layer provides explicit information to inform network-layer queuing and
queuing and forwarding, and can also provide information on the forwarding, rather than an operator inferring traffic requirements
relative importance of packet information collected by measurement from transport and application headers via a multi-field
campaigns, but does not directly provide performance data. classifier.
This field provides explicit information that can be used in place
of inferring traffic requirements (e.g., by inferring QoS
requirements from port information via a multi-field classifier).
The DSCP value can therefore impact the quality of experience for Since the DSCP value can impact the quality of experience for a
a flow. Observations of service performance need to consider this flow., observations of service performance need to consider this
field when a network path has support for differentiated service field when a network path has support for differentiated service
treatment. treatment.
Use of Explicit Congestion Marking: ECN [RFC3168] is an optional Use of Explicit Congestion Marking: ECN [RFC3168] is a transport
transport mechanism that uses a code point in the network-layer mechanism that utilises the ECN field in the network-layer header.
header. Use of ECN can offer gains in terms of increased Use of ECN explicitly informs the network-layer that a transport
throughput, reduced delay, and other benefits when used over a is ECN-capable, and requests ECN treatment of the flows packets.
path that includes equipment that supports an AQM method that An ECN-capable transport can offer benefits when used over a path
performs Congestion Experienced (CE) marking of IP packets with equipment taht implements an AQM method with Congestion
[RFC8087]. Experienced (CE) marking of IP packets [RFC8087].
ECN exposes the presence of congestion on a network path to the
transport and network layer. The reception of CE-marked packets
can therefore be used to monitor the presence and estimate the
level of incipient congestion on the upstream portion of the path
from the point of observation (Section 2.5 of [RFC8087]). Because
ECN marks are carried in the IP protocol header, it is much easier
to measure ECN than to measure packet loss. However, interpreting
the marking behaviour (i.e., assessing congestion and diagnosing
faults) requires context from the transport layer (path RTT,
visibility of loss - that could be due to queue overflow,
congestion response, etc) [RFC7567].
Some ECN-capable network devices can provide richer (more frequent
and fine-grained) indication of their congestion state. Setting
congestion marks proportional to the level of congestion (e.g.,
Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable
throughput, L4S, [I-D.ietf-tsvwg-l4s-arch].
Use of ECN requires a transport to feed back reception information ECN exposes the presence of congestion. The reception of CE-
on the path towards the data sender. Exposure of this Transport marked packets can be used to estimate the level of incipient
ECN feedback provides an additional powerful tool to understand congestion on the upstream portion of the path from the point of
ECN-enabled AQM-based networks [RFC8087]. observation (Section 2.5 of [RFC8087]). Interpreting the marking
behaviour (i.e., assessing congestion and diagnosing faults)
requires context from the transport layer (such as path RTT).
AQM and ECN offer a range of algorithms and configuration options, AQM and ECN offer a range of algorithms and configuration options.
it is therefore important for tools to be available to network Tools therefore need to be available to network operators and
operators and researchers to understand the implication of researchers to understand the implication of configuration choices
configuration choices and transport behaviour as use of ECN and transport behaviour as use of ECN increases and new methods
increases and new methods emerge [RFC7567] [RFC8087]. ECN- emerge [RFC7567].
monitoring is expected to become important as AQM is deployed that
supports ECN [RFC8087].
3.2. Transport Measurement 3.2. Transport Measurement
The common language between network operators and application/content The common language between network operators and application/content
providers/users is packet transfer performance at a layer that all providers/users is packet transfer performance at a layer that all
can view and analyse. For most packets, this has been transport can view and analyse. For most packets, this has been transport
layer, until the emergence of QUIC, with the obvious exception of layer, until the emergence of QUIC, with the obvious exception of
Virtual Private Networks (VPNs) and IPsec. Virtual Private Networks (VPNs) and IPsec.
When encryption conceals more layers in each packet, people seeking When encryption conceals more layers in each packet, people seeking
skipping to change at page 15, line 49 skipping to change at page 16, line 31
flows, with a focus on transport measurement. flows, with a focus on transport measurement.
3.2.1. Point of Observation 3.2.1. Point of Observation
On-path measurements are particularly useful for locating the source On-path measurements are particularly useful for locating the source
of problems or to assess the performance of a network segment or a of problems or to assess the performance of a network segment or a
particular device configuration. Often issues can only be understood particular device configuration. Often issues can only be understood
in the context of the other flows that share a particular path, in the context of the other flows that share a particular path,
common network device, interface port, etc. A simple example is common network device, interface port, etc. A simple example is
monitoring of a network device that uses a scheduler or active queue monitoring of a network device that uses a scheduler or active queue
management technique [RFC7567], where it may be desirable to management technique [RFC7567], where it could be desirable to
understand whether algorithms are correctly controlling latency, or understand whether algorithms are correctly controlling latency, or
overload protection. This understanding implies knowledge of how overload protection. This understanding implies knowledge of how
traffic is assigned to any sub-queues used for flow scheduling, but traffic is assigned to any sub-queues used for flow scheduling, but
can also require information about how the traffic dynamics impact can also require information about how the traffic dynamics impact
active queue management, starvation prevention mechanisms and active queue management, starvation prevention mechanisms and
circuit-breakers. circuit-breakers.
Sometimes multiple on-path observation points are needed. By Sometimes multiple on-path observation points are needed. By
correlating observations of headers at multiple points along the path correlating observations of headers at multiple points along the path
(e.g., at the ingress and egress of a network segment), an observer (e.g., at the ingress and egress of a network segment), an observer
can determine the contribution of a portion of the path to an can determine the contribution of a portion of the path to an
observed metric (to locate a source of delay, jitter, loss, observed metric (to locate a source of delay, jitter, loss,
reordering, congestion marking, etc.). reordering, congestion marking, etc.).
3.2.2. Use by Operators to Plan and Provision Networks 3.2.2. Use by Operators to Plan and Provision Networks
Traffic measurements (e.g., traffic volume, loss, latency) is used by Traffic measurements (e.g., traffic volume, loss, latency) is used by
operators to help plan deployment of new equipment and configurations operators to help plan deployment of new equipment and configurations
in their networks. Data is also important to equipment vendors who in their networks. Data is also valuable to equipment vendors who
need to understand traffic trends and patterns of usage as inputs to want to understand traffic trends and patterns of usage as inputs to
decisions about planning products and provisioning for new decisions about planning products and provisioning for new
deployments. This measurement information can also be correlated deployments. This measurement information can also be correlated
with billing information when this is also collected by an operator. with billing information when this is also collected by an operator.
A network operator supporting traffic that uses transport header A network operator supporting traffic that uses transport header
encryption may not have access to per-flow measurement data. Trends encryption may not have access to per-flow measurement data. Trends
in aggregate traffic can be observed and can be related to the in aggregate traffic can be observed and can be related to the
endpoint addresses being used, but it may not be possible to endpoint addresses being used, but it may be impossible to correlate
correlate patterns in measurements with changes in transport patterns in measurements with changes in transport protocols (e.g.,
protocols (e.g., the impact of changes in introducing a new transport the impact of changes in introducing a new transport protocol
protocol mechanism). This increases the dependency on other indirect mechanism). This increases the dependency on other indirect sources
sources of information to inform planning and provisioning. of information to inform planning and provisioning.
3.2.3. Service Performance Measurement 3.2.3. Service Performance Measurement
Traffic measurements (e.g., traffic volume, loss, latency) can be Traffic measurements (e.g., traffic volume, loss, latency) can be
used by various actors to help analyse the performance offered to the used by various actors to help analyse the performance offered to the
users of a network segment, and inform operational practice. users of a network segment, and inform operational practice.
While active measurements may be used in-network, passive While active measurements may be used in-network, passive
measurements can have advantages in terms of eliminating unproductive measurements can have advantages in terms of eliminating unproductive
test traffic, reducing the influence of test traffic on the overall test traffic, reducing the influence of test traffic on the overall
traffic mix, and the ability to choose the point of observation traffic mix, and the ability to choose the point of observation
Section 3.2.1. However, passive measurements may rely on observing Section 3.2.1. However, passive measurements can rely on observing
transport headers. transport headers.
3.2.4. Measuring Transport to Support Network Operations 3.2.4. Measuring Transport to Support Network Operations
Information provided by tools observing transport headers can help Information provided by tools observing transport headers can help
determine whether mechanisms are needed in the network to prevent determine whether mechanisms are needed in the network to prevent
flows from acquiring excessive network capacity. Operators can flows from acquiring excessive network capacity. Operators can
implement operational practices to manage traffic flows (e.g., to implement operational practices to manage traffic flows (e.g., to
prevent flows from acquiring excessive network capacity under severe prevent flows from acquiring excessive network capacity under severe
congestion) by deploying rate-limiters, traffic shaping or network congestion) by deploying rate-limiters, traffic shaping or network
skipping to change at page 17, line 30 skipping to change at page 18, line 12
expected to appropriately control their network usage, reacting expected to appropriately control their network usage, reacting
when the network experiences congestion, by back-off and reduce when the network experiences congestion, by back-off and reduce
the load placed on the network. This is the normal expected the load placed on the network. This is the normal expected
behaviour for IETF-specified transport (e.g., TCP and SCTP). behaviour for IETF-specified transport (e.g., TCP and SCTP).
However, when anomalies are detected, tools can interpret the However, when anomalies are detected, tools can interpret the
transport protocol header information to help understand the transport protocol header information to help understand the
impact of specific transport protocols (or protocol mechanisms) on impact of specific transport protocols (or protocol mechanisms) on
the other traffic that shares a network. An observation in the the other traffic that shares a network. An observation in the
network can gain understanding of the dynamics of a flow and its network can gain understanding of the dynamics of a flow and its
congestion control behaviour. Analysing observed packet sequence congestion control behaviour. Analysing observed flows can help
numbers can be used to help build confidence that an application to build confidence that an application flow backs-off its share
flow backs-off its share of the network load in the face of of the network load in the face of persistent congestion, and
persistent congestion, and hence to understand whether the hence to understand whether the behaviour is appropriate for
behaviour is appropriate for sharing limited network capacity. sharing limited network capacity. For example, it is common to
For example, it is common to visualise plots of TCP sequence visualise plots of TCP sequence numbers versus time for a flow to
numbers versus time for a flow to understand how a flow shares understand how a flow shares available capacity, deduce its
available capacity, deduce its dynamics in response to congestion, dynamics in response to congestion, etc. The ability to identify
etc. sources that contribute excessive congestion is important to safe
operation of network infrastructure, and mechanisms can inform
configuration of network devices to complement the endpoint
congestion avoidance mechanisms [RFC7567] [RFC8084] to avoid a
portion of the network being driven into congestion collapse
[RFC2914].
Congestion Control Compliance for UDP traffic UDP provides a minimal Congestion Control Compliance for UDP traffic UDP provides a minimal
message-passing datagram transport that has no inherent congestion message-passing datagram transport that has no inherent congestion
control mechanisms. Because congestion control is critical to the control mechanisms. Because congestion control is critical to the
stable operation of the Internet, applications and other protocols stable operation of the Internet, applications and other protocols
that choose to use UDP as a transport are required to employ that choose to use UDP as a transport are required to employ
mechanisms to prevent congestion collapse, avoid unacceptable mechanisms to prevent congestion collapse, avoid unacceptable
contributions to jitter/latency, and to establish an acceptable contributions to jitter/latency, and to establish an acceptable
share of capacity with concurrent traffic [RFC8085]. share of capacity with concurrent traffic [RFC8085].
skipping to change at page 18, line 30 skipping to change at page 19, line 21
(including denial of service), and responding to user performance (including denial of service), and responding to user performance
questions. Sections 3.1.2 and 5 of [RFC8404] provide further questions. Sections 3.1.2 and 5 of [RFC8404] provide further
examples. These tasks seldom involve the need to determine the examples. These tasks seldom involve the need to determine the
contents of the transport payload, or other application details. contents of the transport payload, or other application details.
A network operator supporting traffic that uses transport header A network operator supporting traffic that uses transport header
encryption can see only encrypted transport headers. This prevents encryption can see only encrypted transport headers. This prevents
deployment of performance measurement tools that rely on transport deployment of performance measurement tools that rely on transport
protocol information. Choosing to encrypt all the information protocol information. Choosing to encrypt all the information
reduces the ability of an operator to observe transport performance, reduces the ability of an operator to observe transport performance,
and may limit the ability of network operators to trace problems, and could limit the ability of network operators to trace problems,
make appropriate QoS decisions, or response to other queries about make appropriate QoS decisions, or response to other queries about
the network service. For some this will be blessing, for others it the network service. For some this will be blessing, for others it
may be a curse. For example, operational performance data about may be a curse. For example, operational performance data about
encrypted flows needs to be determined by traffic pattern analysis, encrypted flows needs to be determined by traffic pattern analysis,
rather than relying on traditional tools. This can impact the rather than relying on traditional tools. This can impact the
ability of the operator to respond to faults, it could require ability of the operator to respond to faults, it could require
reliance on endpoint diagnostic tools or user involvement in reliance on endpoint diagnostic tools or user involvement in
diagnosing and troubleshooting unusual use cases or non-trivial diagnosing and troubleshooting unusual use cases or non-trivial
problems. A key need here is for tools to provide useful information problems. A key need here is for tools to provide useful information
during network anomalies (e.g., significant reordering, high or during network anomalies (e.g., significant reordering, high or
intermittent loss). Although many network operators utilise intermittent loss). Many network operators currently utilise
transport information as a part of their operational practice, the observed transport information as a part of their operational
network will not break because transport headers are encrypted, and practice. However, the network will not break just because transport
this may require alternative tools may need to be developed and headers are encrypted, although alternative diagnostic and
deployed. troubleshooting tools would need to be developed and deployed.
3.3.1. Examples of measurements 3.3.1. Examples of measurements
Measurements can be used to monitor the health of a portion of the Measurements can be used to monitor the health of a portion of the
Internet, to provide early warning of the need to take action. They Internet, to provide early warning of the need to take action. They
can assist in debugging and diagnosing the root causes of faults that can assist in debugging and diagnosing the root causes of faults that
concern a particular user's traffic. They can also be used to concern a particular user's traffic. They can also be used to
support post-mortem investigation after an anomaly to determine the support post-mortem investigation after an anomaly to determine the
root cause of a problem. root cause of a problem.
skipping to change at page 19, line 36 skipping to change at page 20, line 26
to-point radio) has the complexity of a subsystem that performs radio to-point radio) has the complexity of a subsystem that performs radio
resource management,s with direct impact on the available capacity, resource management,s with direct impact on the available capacity,
and potentially loss/reordering of packets. The impact of the and potentially loss/reordering of packets. The impact of the
pattern of loss and congestion, differs for different traffic types, pattern of loss and congestion, differs for different traffic types,
correlation with propagation and interference can all have correlation with propagation and interference can all have
significant impact on the cost and performance of a provided service. significant impact on the cost and performance of a provided service.
The need for this type of information is expected to increase as The need for this type of information is expected to increase as
operators bring together heterogeneous types of network equipment and operators bring together heterogeneous types of network equipment and
seek to deploy opportunistic methods to access radio spectrum. seek to deploy opportunistic methods to access radio spectrum.
3.4. Observing Headers to Implement Network Policy 3.4. Use of transport information to influence network forwarding
Information from the transport protocol can be used by a multi-field Information from the transport protocol can be used by a multi-field
classifier as a part of policy framework. Policies are commonly used classifier as a part of policy framework. Policies are commonly used
for management of the QoS or Quality of Experience (QoE) in resource- for management of the QoS or Quality of Experience (QoE) in resource-
constrained networks and by firewalls that use the information to constrained networks and by firewalls that use the information to
implement access rules (see also section 2.2.2 of [RFC8404]). implement access rules (see also section 2.2.2 of [RFC8404]).
Traffic that cannot be classified, will typically receive a default Network-layer classification methods that rely on a multi-field
treatment. classifier (e.g. Inferring QoS from the 5-tuple or choice of
application protocol) are incompatible with transport protocols that
encrypt the transport information. Traffic that cannot be
classified, will typically receive a default treatment.
Transport information can also be explicitly set in network-layer
header fields that are not encrypted. This can provide information
to enable a different forwarding treatment by the network, even when
a transport employs encryption to protect other header information.
When a transport multiplexes multiple subflows, a transport could
choose to hide the presence and characteristics of these subflows
from the network. However, a transport is permitted to set the
network-layer information to indicate the presence of subflows and to
reflect the needs of individual subflows (e.g., a WebRTC can identify
different forwarding treatments for individual packets based on the
value of the DS field [I-D.ietf-tsvwg-rtcweb-qos]).
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged to
set the IPv6 Flow Label field of the network-layer header (e.g.,
[RFC8085]). The label can provide information that can help
inform network-layer queuing, forwarding (e.g., for Equal Cost
Multi-Path, ECMP, routing, and Link Aggregation, LAG) [RFC6294].
A multiplexing transport could choose to use multiple flow labels
to allow the network to independently forward subflows.
Use Network-Layer Differentiated Services Code Point Point:
Applications can expose their delivery expectations to the network
by setting the DSCP field of IPv4 and IPv6 packets [RFC2474].
This provides explicit information to inform network-layer queuing
and forwarding, rather than an operator inferring traffic
requirements from transport and application headers via a multi-
field classifier.
Since the DSCP value can impact the quality of experience for a
flow, observations of service performance need to consider this
field when a network path has support for differentiated service
treatment.
Use of Explicit Congestion Marking: ECN [RFC3168] is a transport
mechanism that utilises the ECN field in the network-layer header
to explicitly inform the network-layer that a transport is ECN-
capable and request ECN treatment of the flows packets. This can
offer benefits when used over a path with equipment that
implements an AQM method with Congestion Experienced (CE) marking
of IP packets [RFC8087].
The reception of CE-marked packets can be used to estimate the
level of incipient congestion on the upstream portion of the path
from the point of observation (Section 2.5 of [RFC8087]).
Interpreting the marking behaviour (i.e., assessing congestion and
diagnosing faults) requires context from the transport layer (such
as path RTT).
AQM and ECN offer a range of algorithms and configuration options,
it is therefore important for tools to be available to network
operators and researchers to understand the implication of
configuration choices and transport behaviour as use of ECN
increases and new methods emerge [RFC7567].
4. Encryption and Authentication of Transport Headers 4. Encryption and Authentication of Transport Headers
End-to-end encryption can be applied at various protocol layers. It End-to-end encryption can be applied at various protocol layers. It
can be applied above the transport to encrypt the transport payload. can be applied above the transport to encrypt the transport payload.
Encryption methods can hide information from an eavesdropper in the Encryption methods can hide information from an eavesdropper in the
network. Encryption can also help protect the privacy of a user, by network. Encryption can also help protect the privacy of a user, by
hiding data relating to user/device identity or location. Neither an hiding data relating to user/device identity or location. Neither an
integrity check nor encryption methods prevent traffic analysis, and integrity check nor encryption methods prevent traffic analysis, and
usage needs to reflect that profiling of users, identification of usage needs to reflect that profiling of users, identification of
skipping to change at page 20, line 45 skipping to change at page 22, line 45
encrypted tunnel technologies. Revelations about the use of encrypted tunnel technologies. Revelations about the use of
pervasive surveillance [RFC7624] have, to some extent, eroded pervasive surveillance [RFC7624] have, to some extent, eroded
trust in the service offered by network operators, and following trust in the service offered by network operators, and following
the Snowden revelation in the USA in 2013 has led to an increased the Snowden revelation in the USA in 2013 has led to an increased
desire for people to employ encryption to avoid unwanted desire for people to employ encryption to avoid unwanted
"eavesdropping" on their communications. Concerns have also been "eavesdropping" on their communications. Concerns have also been
voiced about the addition of information to packets by third voiced about the addition of information to packets by third
parties to provide analytics, customization, advertising, cross- parties to provide analytics, customization, advertising, cross-
site tracking of users, to bill the customer, or to selectively site tracking of users, to bill the customer, or to selectively
allow or block content. Whatever the reasons, there are now allow or block content. Whatever the reasons, there are now
activities in the IETF to design new protocols that may include activities in the IETF to design new protocols that could include
some form of transport header encryption (e.g., QUIC some form of transport header encryption (e.g., QUIC
[I-D.ietf-quic-transport]). [I-D.ietf-quic-transport]).
Authentication methods (that provide integrity checks of protocols Authentication methods (that provide integrity checks of protocols
fields) have also been specified at the network layer, and this also fields) have also been specified at the network layer, and this also
protects transport header fields. The network layer itself carries protects transport header fields. The network layer itself carries
protocol header fields that are increasingly used to help forwarding protocol header fields that are increasingly used to help forwarding
decisions reflect the need of transport protocols, such as the IPv6 decisions reflect the need of transport protocols, such as the IPv6
Flow Label [RFC6437], the DSCP and ECN. Flow Label [RFC6437], the DSCP and ECN.
skipping to change at page 22, line 10 skipping to change at page 24, line 10
the IP pseudo header, TCP header, and TCP data. TCP-AO protects the IP pseudo header, TCP header, and TCP data. TCP-AO protects
the transport layer, preventing attacks from disabling the TCP the transport layer, preventing attacks from disabling the TCP
connection itself and provides replay protection. TCP-AO may connection itself and provides replay protection. TCP-AO may
interact with middleboxes, depending on their behaviour [RFC3234]. interact with middleboxes, depending on their behaviour [RFC3234].
The IPsec Authentication Header (AH) [RFC4302] was designed to The IPsec Authentication Header (AH) [RFC4302] was designed to
work at the network layer and authenticate the IP payload. This work at the network layer and authenticate the IP payload. This
approach authenticates all transport headers, and verifies their approach authenticates all transport headers, and verifies their
integrity at the receiver, preventing in-network modification. integrity at the receiver, preventing in-network modification.
Greasing Transport layer header information that is observable can
be observed in the network. Protocols often provide extensibility
features, reserving fields or values for use by future versions of
a specification. The specification of receivers has traditionally
ignored unspecified values, however in-network devices have
emerged that ossify to require a certain value in a field, or re-
use a field for another purpose. When the speicfication is later
updated, it is impossible to deploy the new use of the field, and
forwarding of the protocol could even become conditional on a
specific header field value.
A protocol can intentionally vary the value, format, and/or
presence of observable transport header fields. This behaviour,
known as GREASE (Generate Random Extensions And Sustain
Extensibility), is designed to avoid a network device ossifying
the use of a specific observable field. Greasing seeks to ease
deployment of new methods. It can be designed to avoid in-network
devices utilising the information in a transport header, or can
make an observation robust to a set of changing values, rather
than a specific set of values.
Encrypting the Transport Payload: The transport layer payload can be Encrypting the Transport Payload: The transport layer payload can be
encrypted to protect the content of transport segments. This encrypted to protect the content of transport segments. This
leaves transport protocol header information in the clear. The leaves transport protocol header information in the clear. The
integrity of immutable transport header fields could be protected integrity of immutable transport header fields could be protected
by combining this with an integrity check. by combining this with an integrity check.
Examples of encrypting the payload include Transport Layer Examples of encrypting the payload include Transport Layer
Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS) Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS)
over UDP [RFC6347] [RFC7525], and TCPcrypt over UDP [RFC6347] [RFC7525], and TCPcrypt
[I-D.ietf-tcpinc-tcpcrypt], which permits opportunistic encryption [I-D.ietf-tcpinc-tcpcrypt], which permits opportunistic encryption
skipping to change at page 22, line 46 skipping to change at page 25, line 18
protocol design can encrypt selected header fields, while also protocol design can encrypt selected header fields, while also
choosing to authenticate the entire transport header. This allows choosing to authenticate the entire transport header. This allows
specific transport header fields to be made observable by network specific transport header fields to be made observable by network
devices. End-to end integrity checks can prevent an endpoint from devices. End-to end integrity checks can prevent an endpoint from
undetected modification of the immutable transport headers. undetected modification of the immutable transport headers.
Mutable fields in the transport header provide opportunities for Mutable fields in the transport header provide opportunities for
middleboxes to modify the transport behaviour (e.g., the extended middleboxes to modify the transport behaviour (e.g., the extended
headers described in [I-D.trammell-plus-abstract-mech]). This headers described in [I-D.trammell-plus-abstract-mech]). This
considers only immutable fields in the transport headers, that is, considers only immutable fields in the transport headers, that is,
fields that may be authenticated End-to-End across a path. fields that can be authenticated End-to-End across a path.
An example of a method that encrypts some, but not all, transport An example of a method that encrypts some, but not all, transport
information is GRE-in-UDP [RFC8086] when used with GRE encryption. information is GRE-in-UDP [RFC8086] when used with GRE encryption.
Optional Encryption of Header Information: There are implications to Optional Encryption of Header Information: There are implications to
the use of optional header encryption in the design of a transport the use of optional header encryption in the design of a transport
protocol, where support of optional mechanisms can increase the protocol, where support of optional mechanisms can increase the
complexity of the protocol and its implementation and in the complexity of the protocol and its implementation and in the
management decisions that are required to use variable format management decisions that are required to use variable format
fields. Instead, fields of a specific type ought to always be fields. Instead, fields of a specific type ought to always be
sent with the same level of confidentiality or integrity sent with the same level of confidentiality or integrity
protection. protection.
5. Addition of Transport Information to Network-Layer Protocol Headers 5. Addition of Transport Information to Network-Layer Protocol Headers
Transport protocol information can be made visible in a network-layer Transport protocol information can be made visible in a network-layer
header. This has the advantage that this information can then be header. This has the advantage that this information can then be
observed by in-network devices. This has the advantage that a single observed by in-network devices.
header can support all transport protocols, but there may also be
less desirable implications of separating the operation of the
transport protocol from the measurement framework.
Some measurements may be made by adding additional protocol headers 5.1. Use of transport information to influence network forwarding
Information from the transport protocol can be used by a multi-field
classifier as a part of policy framework. Policies are commonly used
for management of the QoS or Quality of Experience (QoE) in resource-
constrained networks and by firewalls that use the information to
implement access rules (see also section 2.2.2 of [RFC8404]).
Network-layer classification methods that rely on a multi-field
classifier (e.g. Inferring QoS from the 5-tuple or choice of
application protocol) are incompatible with transport protocols that
encrypt the transport information. Traffic that cannot be
classified, will typically receive a default treatment.
Transport information can also be explicitly set in network-layer
header fields that are not encrypted. This can provide information
to enable a different forwarding treatment by the network, even when
a transport employs encryption to protect other header information.
When a transport multiplexes multiple subflows, a transport could
choose to hide the presence and characteristics of these subflows
from the network. However, a transport is permitted to set the
network-layer information to indicate the presence of subflows and to
reflect the needs of individual subflows (e.g., a WebRTC can identify
different forwarding treatments for individual packets based on the
value of the Differentiated Services Code Point (DSCP) field
[I-D.ietf-tsvwg-rtcweb-qos]).
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged to
set the IPv6 Flow Label field of the network-layer header (e.g.,
[RFC8085]). The label can provide information that can help
inform network-layer queuing, forwarding (e.g., for Equal Cost
Multi-Path, ECMP, routing, and Link Aggregation, LAG) [RFC6294].
A multiplexing transport could choose to use multiple flow labels
to allow the network to independently forward subflows.
Use Network-Layer Differentiated Services Code Point Point:
Applications can expose their delivery expectations to the network
by setting the DSCP field of IPv4 and IPv6 packets [RFC2474].This
provides explicit information to inform network-layer queuing and
forwarding, rather than an operator inferring traffic requirements
from transport and application headers via a multi-field
classifier.
Since the DSCP value can impact the quality of experience for a
flow., observations of service performance need to consider this
field when a network path has support for differentiated service
treatment.
Use of Explicit Congestion Marking: ECN [RFC3168] is a transport
mechanism that utilises the ECN field in the network-layer header.
Use of ECN explicitly informs the network-layer that a transport
is ECN-capable, and requests ECN treatment of the flows packets.
An ECN-capable transport can offer benefits when used over a path
with equipment that implements an AQM method with Congestion
Experienced (CE) marking of IP packets [RFC8087].
ECN exposes the presence of congestion. The reception of CE-
marked packets can be used to estimate the level of incipient
congestion on the upstream portion of the path from the point of
observation (Section 2.5 of [RFC8087]). Interpreting the marking
behaviour (i.e., assessing congestion and diagnosing faults)
requires context from the transport layer (such as path RTT).
AQM and ECN offer a range of algorithms and configuration options,
it is therefore important for tools to be available to network
operators and researchers to understand the implication of
configuration choices and transport behaviour as use of ECN
increases and new methods emerge [RFC7567].
5.2. Network-layer measurement
Some measurements can be made by adding additional protocol headers
carrying operations, administration and management (OAM) information carrying operations, administration and management (OAM) information
to packets at the ingress to a maintenance domain (e.g., an Ethernet to packets at the ingress to a maintenance domain (e.g., an Ethernet
protocol header with timestamps and sequence number information using protocol header with timestamps and sequence number information using
a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data])
and removing the additional header at the egress of the maintenance and removing the additional header at the egress of the maintenance
domain. This approach enables some types of measurements, but does domain. This approach enables some types of measurements, but 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 required segments/nodes and there can be challenges in tools at the required segments/nodes and there can be challenges in
correlating the downsream/upstream information when in-band OAM data correlating the downsream/upstream information when in-band OAM data
is inserted by an on-path device. is inserted by an on-path device. This has the advantage that a
single header can support all transport protocols, but there could
also be less desirable implications of separating the operation of
the transport protocol from the measurement framework.
Another example of a network-layer approach is the IPv6 Performance Another example of a network-layer approach is the IPv6 Performance
and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This
allows a sender to optionally include a destination option that allows a sender to optionally include a destination option that
caries header fields that can be used to observe timestamps and caries header fields that can be used to observe timestamps and
packet sequence numbers. This information could be authenticated by packet sequence numbers. This information could be authenticated by
receiving transport endpoints when the information is added at the receiving transport endpoints when the information is added at the
sender and visible at the receiving endpoint, although methods to do sender and visible at the receiving endpoint, although methods to do
this have not currently been proposed. This method needs to be this have not currently been proposed. This method needs to be
explicitly enabled at the sender. explicitly enabled at the sender.XXX
It can be undesirable to rely on methods requiring the presence of Current measurements suggest it can be undesirable to rely on methods
network options or extension headers. IPv4 network options are often requiring the presence of network options or extension headers. IPv4
not supported (or are carried on a slower processing path) and some network options are often not supported (or are carried on a slower
IPv6 networks are also known to drop packets that set an IPv6 header processing path) and some IPv6 networks are also known to drop
extension (e.g., [RFC7872]). Another disadvantage is that protocols packets that set an IPv6 header extension (e.g., [RFC7872]). Another
that separately expose header information do not necessarily have an disadvantage is that protocols that separately expose header
advantage to expose the information that is utilised by the protocol information do not necessarily have an advantage to expose the
itself, and could manipulate this header information to gain an information that is utilised by the protocol itself, and could
advantage from the network. manipulate this header information to gain an advantage from the
network.
6. Implications of Protecting the Transport Headers 6. Implications of Protecting the Transport Headers
The choice of which fields to expose and which to encrypt is a design The choice of which fields to expose and which to encrypt is a design
choice for the transport protocol. Any selective encryption method choice for the transport protocol. Any selective encryption method
requires trading two conflicting goals for a transport protocol requires trading two conflicting goals for a transport protocol
designer to decide which header fields to encrypt. Security work designer to decide which header fields to encrypt. Security work
typically employs a design technique that seeks to expose only what typically employs a design technique that seeks to expose only what
is needed. However, there can be performance and operational is needed. However, there can be performance and operational
benefits in exposing selected information to network tools. benefits in exposing selected information to network tools.
skipping to change at page 24, line 45 skipping to change at page 28, line 45
configuration of the network paths being measured. configuration of the network paths being measured.
Sharing information between actors needs also to consider the privacy Sharing information between actors needs also to consider the privacy
of the user and the incentives for providing accurate and detailed of the user and the incentives for providing accurate and detailed
information. Protocols that expose the state information used by the information. Protocols that expose the state information used by the
transport protocol in their header information (e.g., timestamps used transport protocol in their header information (e.g., timestamps used
to calculate the RTT, packet numbers used to asses congestion and to calculate the RTT, packet numbers used to asses congestion and
requests for retransmission) provide an incentive for the sending requests for retransmission) provide an incentive for the sending
endpoint to provide correct information, increasing confidence that endpoint to provide correct information, increasing confidence that
the observer understands the transport interaction with the network. the observer understands the transport interaction with the network.
This becomes important when considering changes to transport This can support decisions when considering changes to transport
protocols, changes in network infrastructure, or the emergence of new protocols, changes in network infrastructure, or the emergence of new
traffic patterns. traffic patterns.
6.2. Characterising "Unknown" Network Traffic 6.2. Characterising "Unknown" Network Traffic
The patterns and types of traffic that share Internet capacity The patterns and types of traffic that share Internet capacity
changes with time as networked applications, usage patterns and changes with time as networked applications, usage patterns and
protocols continue to evolve. protocols continue to evolve.
If "unknown" or "uncharacterised" traffic patterns form a small part If "unknown" or "uncharacterised" traffic patterns form a small part
skipping to change at page 26, line 9 skipping to change at page 30, line 9
A lack of data reduces the level of precision with which flows can be A lack of data reduces the level of precision with which flows can be
classified and conditioning mechanisms are applied (e.g., rate classified and conditioning mechanisms are applied (e.g., rate
limiting, circuit breaker techniques [RFC8084], or blocking of limiting, circuit breaker techniques [RFC8084], or blocking of
uncharacterised traffic), and this needs to be considered when uncharacterised traffic), and this needs to be considered when
evaluating the impact of designs for transport encryption [RFC5218]. evaluating the impact of designs for transport encryption [RFC5218].
6.4. Impact on Research, Development and Deployment 6.4. Impact on Research, Development and Deployment
The majority of present Internet applications use two well-known The majority of present Internet applications use two well-known
transport protocols: e.g., TCP and UDP. Although TCP represents the transport protocols: e.g., TCP and UDP. Although TCP represents the
majority of current traffic, some important real-time applications majority of current traffic, some real-time applications use UDP, and
use UDP, and much of this traffic utilises RTP format headers in the much of this traffic utilises RTP format headers in the payload of
payload of the UDP datagram. Since these protocol headers have been the UDP datagram. Since these protocol headers have been fixed for
fixed for decades, a range of tools and analysis methods have became decades, a range of tools and analysis methods have became common and
common and well-understood. Over this period, the transport protocol well-understood. Over this period, the transport protocol headers
headers have mostly changed slowly, and so also the need to develop have mostly changed slowly, and so also the need to develop tools
tools track new versions of the protocol. track new versions of the protocol.
Looking ahead, there will be a need to update these protocols and to Looking ahead, there will be a need to update these protocols and to
develop and deploy new transport mechanisms and protocols. There are develop and deploy new transport mechanisms and protocols. There are
both opportunities and also challenges to the design, evaluation and both opportunities and also challenges to the design, evaluation and
deployment of new transport protocol mechanisms. deployment of new transport protocol mechanisms.
Integrity checks can protect an endpoint from undetected modification Integrity checks can protect an endpoint from undetected modification
of protocol fields by network devices, whereas encryption and of protocol fields by network devices, whereas encryption and
obfuscation can further prevent these headers being utilised by obfuscation can further prevent these headers being utilised by
network devices. Hiding headers can therefore provide the network devices. Hiding headers can therefore provide the
skipping to change at page 27, line 27 skipping to change at page 31, line 27
Open standards motivate a desire for this evaluation to include Open standards motivate a desire for this evaluation to include
independent observation and evaluation of performance data, which in independent observation and evaluation of performance data, which in
turn suggests control over where and when measurement samples are turn suggests control over where and when measurement samples are
collected. This requires consideration of the appropriate balance collected. This requires consideration of the appropriate balance
between encrypting all and no transport information. between encrypting all and no transport information.
7. Conclusions 7. Conclusions
The majority of present Internet applications use two well-known The majority of present Internet applications use two well-known
transport protocols: e.g., TCP and UDP. Although TCP represents the transport protocols: e.g., TCP and UDP. Although TCP represents the
majority of current traffic, some important real-time applications majority of current traffic, some real-time applications have used
have used UDP, and much of this traffic utilises RTP format headers UDP, and much of this traffic utilises RTP format headers in the
in the payload of the UDP datagram. Since these protocol headers payload of the UDP datagram. Since these protocol headers have been
have been fixed for decades, a range of tools and analysis methods fixed for decades, a range of tools and analysis methods have became
have became common and well-understood. Over this period, the common and well-understood. Over this period, the transport protocol
transport protocol headers have mostly changed slowly, and so also headers have mostly changed slowly, and so also the need to develop
the need to develop tools track new versions of the protocol. tools track new versions of the protocol.
Confidentiality and strong integrity checks have properties that are Confidentiality and strong integrity checks have properties that are
being incorporated into new protocols and which have important being incorporated into new protocols and that have important
benefits. The pace of development of transports using the WebRTC benefits. The pace of development of transports using the WebRTC
data channel and the rapid deployment of QUIC transport protocol can data channel and the rapid deployment of QUIC transport protocol can
both be attributed to using the combination of UDP as a substrate both be attributed to using the combination of UDP as a substrate
while providing confidentiality and authentication of the while providing confidentiality and authentication of the
encapsulated transport headers and payload. encapsulated transport headers and payload.
The traffic that can be observed by on-path network devices is a The traffic that can be observed by on-path network devices is a
function of transport protocol design/options, network use, function of transport protocol design/options, network use,
applications, and user characteristics. In general, when only a applications, and user characteristics. In general, when only a
small proportion of the traffic has a specific (different) small proportion of the traffic has a specific (different)
skipping to change at page 28, line 15 skipping to change at page 32, line 15
An increased pace of evolution therefore needs to be accompanied by An increased pace of evolution therefore needs to be accompanied by
methods that can be successfully deployed and used across operational methods that can be successfully deployed and used across operational
networks. This leads to a need for network operators (at various networks. This leads to a need for network operators (at various
level (ISPs, enterprises, firewall maintainer, etc) to identify level (ISPs, enterprises, firewall maintainer, etc) to identify
appropriate operational support functions and procedures. appropriate operational support functions and procedures.
Protocols that change their transport header format (wire format) or Protocols that change their transport header format (wire format) or
their behaviour (e.g., algorithms that are needed to classify and their behaviour (e.g., algorithms that are needed to classify and
characterise the protocol), will require new tooling to be developed characterise the protocol), will require new tooling to be developed
to catch-up with the changes. If the currently deployed tools and to catch-up with the changes. If the currently deployed tools and
methods are no longer relevant then performance may not be correctly methods are no longer relevant then it may no longer be posisble to
measured. This can increase the response-time after faults, and can correctly measure performance. This can increase the response-time
impact the ability to manage the network resulting in traffic causing after faults, and can impact the ability to manage the network
traffic to be treated inappropriately (e.g., rate limiting because of resulting in traffic causing traffic to be treated inappropriately
being incorrectly classified/monitored). There are benefits in (e.g., rate limiting because of being incorrectly classified/
exposing consistent information to the network that avoids traffic monitored).
being mis-classified and then receiving a default treatment by the
network. There are benefits in exposing consistent information to the network
that avoids traffic being mis-classified and then receiving a default
treatment by the network. The flow label and DSCP fields provide
examples of how transport information can be made available for
network-layer decisions. Extension headers could also be used to
carry transport information that can inform network-layer decisions.
As a part of its design a new protocol specification therefore needs As a part of its design a new protocol specification therefore needs
to weigh the benefits of ossifying common headers, versus the to weigh the benefits of ossifying common headers, versus the
potential demerits of exposing specific information that could be potential demerits of exposing specific information that could be
observed along the network path, to provide tools to manage new observed along the network path, to provide tools to manage new
variants of protocols. Several scenarios to illustrate different variants of protocols. This can be done for the entire transport
ways this could evolve are provided below: header, or by dividing header fields between those that are
observable and mutable; those that are observable, but imutable; 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 o One scenario is when transport protocols provide consistent
information to the network by intentionally exposing a part of the information to the network by intentionally exposing a part of the
transport header. The design fixes the format of this information transport header. The design fixes the format of this information
between versions of the protocol. This ossification of the between versions of the protocol. This ossification of the
transport header allows an operator to establish tooling and transport header allows an operator to establish tooling and
procedures that enable it to provide consistent traffic management procedures that enable it to provide consistent traffic management
as the protocol evolves. In contrast to TCP (where all protocol as the protocol evolves. In contrast to TCP (where all protocol
information is exposed), evolution of the transport is facilitated information is exposed), evolution of the transport is facilitated
by providing cryptographic integrity checks of the transport by providing cryptographic integrity checks of the transport
skipping to change at page 29, line 5 skipping to change at page 33, line 15
characteristics of the flow traffic). The exposed transport characteristics of the flow traffic). The exposed transport
information can be used by operators to provide troubleshooting, information can be used by operators to provide troubleshooting,
measurement and any necessary functions appropriate to the class measurement and any necessary functions appropriate to the class
of traffic (priority, retransmission, reordering, circuit of traffic (priority, retransmission, reordering, circuit
breakers, etc). breakers, etc).
o An alternative scenario adopts different design goals, with a o An alternative scenario adopts different design goals, with a
different outcome. A protocol that encrypts all header different outcome. A protocol that encrypts all header
information forces network operators to act independently from information forces network operators to act independently from
apps/transport developments to extract the information they need apps/transport developments to extract the information they need
to manage their network. A range of approaches may proliferate, to manage their network. A range of approaches could proliferate,
as in current networks. Some operators can add a shim header to as in current networks. Some operators can add a shim header to
each packet as a flow as it crosses the network; other operators/ each packet as a flow as it crosses the network; other operators/
managers could develop heuristics and pattern recognition to managers could develop heuristics and pattern recognition to
derive information that classifies flows and estimates quality derive information that classifies flows and estimates quality
metrics for the service being used; some could decide to rate- metrics for the service being used; some could decide to rate-
limit or block traffic until new tooling is in place. In many limit or block traffic until new tooling is in place. In many
cases, the derived information can be used by operators to provide cases, the derived information can be used by operators to provide
necessary functions appropriate to the class of traffic (priority, necessary functions appropriate to the class of traffic (priority,
retransmission, reordering, circuit breakers, etc). retransmission, reordering, circuit breakers, etc).
Troubleshooting, and measurement becomes more difficult, and more Troubleshooting, and measurement becomes more difficult, and more
diverse. This could require additional information beyond that diverse. This could require additional information beyond that
visible in the packet header and when this information is used to visible in the packet header and when this information is used to
inform decisions by on-path devices it can lead to dependency on inform decisions by on-path devices it can lead to dependency on
other characteristics of the flow. In some cases, operators might other characteristics of the flow. In some cases, operators might
need access to keying information to interpret encrypted data that need access to keying information to interpret encrypted data that
they observe. Some use cases could demand use of transports that they observe. Some use cases could demand use of transports that
do not use encryption. do not use encryption.
The outcome could have significant implications on the way the The direction in which this evolves could have significant
Internet architecture develops. It exposes a risk that significant implications on the way the Internet architecture develops. It
actors (e.g., developers and transport designers) achieve more exposes a risk that significant actors (e.g., developers and
control of the way in which the Internet architecture develops.In transport designers) achieve more control of the way in which the
particular, there is a possibility that designs could evolve to Internet architecture develops.In particular, there is a possibility
significantly benefit of customers for a specific vendor, and that that designs could evolve to significantly benefit of customers for a
communities with very different network, applications or platforms specific vendor, and that communities with very different network,
could then suffer at the expense of benefits to their vendors own applications or platforms could then suffer at the expense of
customer base. In such a scenario, there could be no incentive to benefits to their vendors own customer base. In such a scenario,
support other applications/products or to work in other networks there could be no incentive to support other applications/products or
leading to reduced access for new approaches. 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
protocol or layer on top of the transport protocol protocol or layer on top of the transport protocol
[I-D.ietf-taps-transport-security]. [I-D.ietf-taps-transport-security].
Confidentiality and strong integrity checks have properties that can Confidentiality and strong integrity checks have properties that can
also be incorporated into the deisgn of a transport protocol. also be incorporated into the deisgn of a transport protocol.
Integrity checks can protect an endpoint from undetected modification Integrity checks can protect an endpoint from undetected modification
of protocol fields by network devices, whereas encryption and of protocol fields by network devices, whereas encryption and
obfuscation can further prevent these headers being utilised by obfuscation or greasing can further prevent these headers being
network devices. Hiding headers can therefore provide the utilised by network devices. Hiding headers can therefore provide
opportunity for greater freedom to update the protocols and can ease the opportunity for greater freedom to update the protocols and can
experimentation with new techniques and their final deployment in ease experimentation with new techniques and their final deployment
endpoints. A protocol specification needs to weigh the benefits of in endpoints. A protocol specification needs to weigh the benefits
ossifying common headers, versus the potential demerits of exposing of ossifying common headers, versus the potential demerits of
specific information that could be observed along the network path to exposing specific information that could be observed along the
provide tools to manage new variants of protocols. network path to provide tools to manage new variants of protocols.
A protocol design that uses header encryption can provide A protocol design that uses header encryption can provide
confidentiality of some or all of the protocol header information. confidentiality of some or all of the protocol header information.
This prevents an on-path device from knowledge of the header field. This prevents an on-path device from knowledge of the header field.
It therefore prevents mechanisms being built that directly rely on It therefore prevents mechanisms being built that directly rely on
the information or seeks to imply semantics of an exposed header the information or seeks to infer semantics of an exposed header
field. Hiding headers can limit the ability to measure and field. Hiding headers can limit the ability to measure and
characterise traffic. characterise traffic.
Exposed transport headers are sometimes utilised as a part of the Exposed transport headers are sometimes utilised as a part of the
information to detect anomalies in network traffic. This can be used information to detect anomalies in network traffic. This can be used
as the first line of defence yo identify potential threats from DOS as the first line of defence yo identify potential threats from DOS
or malware and redirect suspect traffic to dedicated nodes or malware and redirect suspect traffic to dedicated nodes
responsible for DOS analysis, malware detection, or to perform packet responsible for DOS analysis, malware detection, or to perform packet
"scrubbing" (the normalization of packets so that there are no "scrubbing" (the normalization of packets so that there are no
ambiguities in interpretation by the ultimate destination of the ambiguities in interpretation by the ultimate destination of the
packet). These techniques are currently used by some operators to packet). These techniques are currently used by some operators to
also defend from distributed DOS attacks. also defend from distributed DOS attacks.
Exposed transport headers are sometimes also utilised as a part of Exposed transport header fields are sometimes also utilised as a part
the information used by the receiver of a transport protocol to of the information used by the receiver of a transport protocol to
protect the transport layer from data injection by an attacker. In protect the transport layer from data injection by an attacker. In
evaluating this use of exposed header information, it is important to evaluating this use of exposed header information, it is important to
consider whether it introduces a significant DOS threat. For consider whether it introduces a significant DOS threat. For
example, an attacker could construct a DOS attack by sending packets example, an attacker could construct a DOS attack by sending packets
with a sequence number that falls within the currently accepted range with a sequence number that falls within the currently accepted range
of sequence numbers at the receiving endpoint, this would then of sequence numbers at the receiving endpoint, this would then
introduce additional work at the receiving endpoint, even though the introduce additional work at the receiving endpoint, even though the
data in the attacking packet may not finally be delivered by the data in the attacking packet may not finally be delivered by the
transport layer. This is sometimes known as a "shadowing attack". transport layer. This is sometimes known as a "shadowing attack".
An attack can, for example, disrupt receiver processing, trigger loss An attack can, for example, disrupt receiver processing, trigger loss
and retransmission, or make a receiving endpoint perform unproductive and retransmission, or make a receiving endpoint perform unproductive
decryption of packets that cannot be successfully decrypted (forcing decryption of packets that cannot be successfully decrypted (forcing
a receiver to commit decryption resources, or to update and then a receiver to commit decryption resources, or to update and then
restore protocol state). restore protocol state).
One mitigation to off-path attack is to deny knowledge of what header One mitigation to off-path attack is to deny knowledge of what header
information is accepted by a receiver or obfusticate the accepted information is accepted by a receiver or obfusticate the accepted
header information, e.g., setting a non-predictable initial value for header information, e.g., setting a non-predictable initial value for
a sequence number during a protocol handshake, as in [RFC3550] and a sequence number during a protocol handshake, as in [RFC3550] and
skipping to change at page 32, line 27 skipping to change at page 36, line 39
Q., and E. Smith, "Cryptographic protection of TCP Streams Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency,
Low Loss, Scalable Throughput (L4S) Internet Service: Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in
progress), March 2018. progress), March 2018.
[I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016.
[I-D.thomson-quic-grease] [I-D.thomson-quic-grease]
Thomson, M., "More Apparent Randomization for QUIC", Thomson, M., "More Apparent Randomization for QUIC",
draft-thomson-quic-grease-00 (work in progress), December draft-thomson-quic-grease-00 (work in progress), December
2017. 2017.
[I-D.trammell-plus-abstract-mech] [I-D.trammell-plus-abstract-mech]
Trammell, B., "Abstract Mechanisms for a Cooperative Path Trammell, B., "Abstract Mechanisms for a Cooperative Path
Layer under Endpoint Control", draft-trammell-plus- Layer under Endpoint Control", draft-trammell-plus-
abstract-mech-00 (work in progress), September 2016. abstract-mech-00 (work in progress), September 2016.
skipping to change at page 34, line 43 skipping to change at page 39, line 10
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for
the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June
2011, <https://www.rfc-editor.org/info/rfc6294>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
skipping to change at page 36, line 25 skipping to change at page 40, line 44
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>. <https://www.rfc-editor.org/info/rfc8250>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
Iyengar, Ed., "Controlled Delay Active Queue Management", Iyengar, Ed., "Controlled Delay Active Queue Management",
RFC 8289, DOI 10.17487/RFC8289, January 2018, RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/info/rfc8289>. <https://www.rfc-editor.org/info/rfc8289>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290, and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>. <https://www.rfc-editor.org/info/rfc8290>.
skipping to change at page 37, line 41 skipping to change at page 42, line 41
-08 Updated to address comments sent to the TSVWG mailing list by -08 Updated to address comments sent to the TSVWG mailing list by
Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on
11/05/2018, and Spencer Dawkins. 11/05/2018, and Spencer Dawkins.
-09 Updated security considerations. -09 Updated security considerations.
-10 Updated references, split the Introduction, and added a paragraph -10 Updated references, split the Introduction, and added a paragraph
giving some examples of why ossification has been an issue. giving some examples of why ossification has been an issue.
-00 This is the first revision submitted as a working group document.
-01 This resolved some reference issues. Updated section on -01 This resolved some reference issues. Updated section on
observation by devices on the path. observation by devices on the path.
-02 Comments received from Kyle Rose, Spencer Dawkins and Tom
Herbert. The network-layer information has also been re-organised
after comments at IETF-103.
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
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
 End of changes. 71 change blocks. 
234 lines changed or deleted 433 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/