draft-fairhurst-tsvwg-transport-encrypt-08.txt   draft-fairhurst-tsvwg-transport-encrypt-09.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C.S. Perkins Intended status: Informational C.S. Perkins
Expires: November 21, 2018 University of Glasgow Expires: December 14, 2018 University of Glasgow
May 22, 2018 June 14, 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-fairhurst-tsvwg-transport-encrypt-08 draft-fairhurst-tsvwg-transport-encrypt-09
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 21, 2018. This Internet-Draft will expire on December 14, 2018.
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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4. Addition of Transport Information to Network-Layer Protocol 4. Addition of Transport Information to Network-Layer Protocol
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Implications of Protecting the Transport Headers . . . . . . . 23 5. Implications of Protecting the Transport Headers . . . . . . . 23
5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23 5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23
5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24 5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24
5.3. Accountability and Internet Transport Protocols . . . . . 25 5.3. Accountability and Internet Transport Protocols . . . . . 25
5.4. Impact on Research, Development and Deployment . . . . . . 25 5.4. Impact on Research, Development and Deployment . . . . . . 25
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Revision information . . . . . . . . . . . . . . . . . 35 Appendix A. Revision information . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This document describes implications of applying end-to-end This document describes implications of applying end-to-end
encryption at the transport layer. It reviews the implications of encryption at the transport layer. It reviews the implications of
developing end-to-end transport protocols that use encryption to developing end-to-end transport protocols that use encryption to
provide confidentiality of the transport protocol header and expected provide confidentiality of the transport protocol header and expected
implications of transport protocol design and network operation. It implications of transport protocol design and network operation. It
also considers anticipated implications on transport and application also considers anticipated implications on transport and application
evolution. evolution.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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
network operators. network operators.
The data can also inform Internet engineering research, and help The data can also inform Internet engineering research, and help
the development of new protocols, methodologies, and procedures. in the development of new protocols, methodologies, and
Concealing the transport protocol header information makes the procedures. Concealing the transport protocol header information
stream performance unavailable to passive observers along the makes the stream performance unavailable to passive observers
path, and likely leads to the development of alternative methods along the path, and likely leads to the development of alternative
to collect or infer that data. methods to collect or infer that data.
Providing confidentiality of the transport payload, but leaving Providing confidentiality of the transport payload, but leaving
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 allowing some measurement. security benefits while allowing some measurement.
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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
the ability to diagnose and explore interactions between features the ability to diagnose and explore interactions between features
at different protocol layers, a side-effect of not allowing a at different protocol layers, a side-effect of not allowing a
choice of vantage point from which this information is observed. choice of vantage point from which this information is observed.
o Supporting Common Specifications: The Transmission Control o Supporting Common Specifications: Transmission Control Protocol
Protocol (TCP) is currently the predominant transport protocol (TCP) is currently the predominant transport protocol used over
used over Internet paths. Its many variants have broadly Internet paths. Its many variants have broadly consistent
consistent approaches to avoiding congestion collapse, and to approaches to avoiding congestion collapse, and to ensuring the
ensuring the stability of the Internet. Increased use of stability of the Internet. Increased use of transport layer
transport layer encryption can overcome ossification, allowing encryption can overcome ossification, allowing deployment of new
deployment of new transports and different types of congestion transports and different types of congestion control. This
control. This flexibility can be beneficial, but it can come at flexibility can be beneficial, but it can come at the cost of
the cost of fragmenting the ecosystem. There is little doubt that fragmenting the ecosystem. There is little doubt that developers
developers will try to produce high quality transports for their will try to produce high quality transports for their intended
intended target uses, but it is not clear there are sufficient target uses, but it is not clear there are sufficient incentives
incentives to ensure good practice that benefits the wide to ensure good practice that benefits the wide diversity of
diversity of requirements for the Internet community as a whole. requirements for the Internet community as a whole. Increased
Increased diversity, and the ability to innovate without public diversity, and the ability to innovate without public scrutiny,
scrutiny, risks point solutions that optimise for specific needs, risks point solutions that optimise for specific needs, but
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, and on the
ability to verify that others also conform. ability to verify that others also conform.
o Operational practice: Published transport specifications allow o Operational practice: Published transport specifications allow
operators to check compliance. This can bring assurance to those operators 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]).
skipping to change at page 8, line 30 skipping to change at page 8, line 30
considering other mechanisms, across a broad range of network considering other mechanisms, across a broad range of network
topologies and with attention to the impact on traffic sharing the topologies and with attention to the impact on traffic sharing the
capacity. If this results in reduced availability of open data, capacity. If this results in reduced availability of open data,
it could eliminate the independent self-checks to the it could eliminate the independent self-checks to the
standardisation process that have previously been in place from standardisation process that have previously been in place from
research and academic contributors (e.g., the role of the IRTF research and academic contributors (e.g., the role of the IRTF
ICCRG, and research publications in reviewing new transport ICCRG, and research publications in reviewing new transport
mechanisms and assessing the impact of their experimental mechanisms and assessing the impact of their experimental
deployment) deployment)
In summary, there are tradeoffs. On the one hand, protocol designers In summary, there are trade offs. On the one hand, protocol
have often ignored the implications of whether the information in designers have often ignored the implications of whether the
transport header fields can or will be used by in-network devices, information in transport header fields can or will be used by in-
and the implications this places on protocol evolution. This network devices, and the implications this places on protocol
motivates a design that provides confidentiality of the header evolution. This motivates a design that provides confidentiality of
information. On the other hand, it can be expected that a lack of the header information. On the other hand, it can be expected that a
visibility of transport header information can impact the ways that lack of visibility of transport header information can impact the
protocols are deployed, standardised, and their operational support. ways that protocols are deployed, standardised, and their operational
The choice of whether future transport protocols encrypt their support. The choice of whether future transport protocols encrypt
protocol headers therefore needs to be taken based not solely on their protocol headers therefore needs to be taken based not solely
security and privacy considerations, but also taking into account the on security and privacy considerations, but also taking into account
impact on operations, standards, and research. Any new Internet the impact on operations, standards, and research. Any new Internet
transport need to provide appropriate transport mechanisms and transport 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.
2. Current uses of Transport Headers within the Network 2. 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 10, line 4 skipping to change at page 9, line 43
new transport headers. This may require interpretation of new transport headers. This may 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.
2.1.1. Flow Identification 2.1.1. Flow Identification
Transport protocol header information (together with information in Transport protocol header information (together with information in
the network header), has been used to identify a flow and the the network header), has been used to identify a flow and the
connection state of the flow, together with the protocol options connection state of the flow, together with the protocol options
being used. In some usages, a low-numbered (well-known) transport being used. In some usages, a low-numbered (well-known) transport
port number has been used to identify a protocol (although port port number has been used to identify a protocol (although port
information alone is not sufficient to guarantee identification of a information alone is not sufficient to guarantee identification of a
protocol). Transport protocols, such as TCP and Stream Control protocol, since applications can use arbitrary ports, multiple
Transport Protocol (SCTP) specify a standard base header that sessions can be multiplexed on a single port, and ports can be re-
includes sequence number information and other data, with the used by subsequent sessions).
possibility to negotiate additional headers at connection setup,
identified by an option number in the transport header. UDP-based
protocols can use, but sometimes do not use, well-known port numbers.
Some can instead be identified by signalling protocols or through the
use of magic numbers placed in the first byte(s) of the datagram
payload.
Flow identification is more complex and less easily achieved when Transport protocols, such as TCP and Stream Control Transport
multiplexing is used at or above the transport layer. Protocol (SCTP) specify a standard base header that includes sequence
number information and other data, with the possibility to negotiate
additional headers at connection setup, identified by an option
number in the transport header. UDP-based protocols can use, but
sometimes do not use, well-known port numbers. Some flows can
instead be identified by signalling protocols or through the use of
magic numbers placed in the first byte(s) of the datagram payload.
Flow identification is a common function. For example, performed by
measurement activities, QoS classification, firewalls, Denial of
Service, DOS, prevention. It becomes more complex and less easily
achieved when multiplexing is used at or above the transport layer.
2.1.2. Metrics derived from Transport Layer Headers 2.1.2. Metrics derived from Transport Layer Headers
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:
skipping to change at page 11, line 8 skipping to change at page 11, line 8
sequence number) and has been used as a metric for performance sequence number) and has been used as a metric for performance
assessment and to characterise transport behaviour. Understanding assessment and to characterise transport behaviour. Understanding
the root cause of loss can help an operator determine whether this the root cause of loss can help an operator determine whether this
requires corrective action. Network operators have used the requires corrective action. Network operators have used the
variation in patterns of loss as a key performance metric, variation in patterns of loss as a key performance metric,
utilising this to detect changes in the offered service. utilising this to detect changes in the 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), inadequate management (e.g., Active Queue Management, AQM [RFC7567]),
provision of traffic preemption. Understanding flow loss rate inadequate provision of traffic preemption. Understanding flow
requires either maintaining per flow packet counters or by loss rate requires either maintaining per flow packet counters or
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 important 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), TCP SACK) can increase reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK)
understanding of the impact of loss and help identify cases where can increase understanding of the impact of loss and help identify
loss may have been wrongly identified, or the transport did not cases where loss may have been wrongly identified, or the
require the lost packet. It is sometimes more important to transport did not require the lost packet. It is sometimes more
understand the pattern of loss, than the loss rate, because losses important to understand the pattern of loss, than the loss rate,
can often occur as bursts, rather than randomly-timed events. because losses can often occur as bursts, rather than randomly-
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 Protocol, RTP, headers numbers in the TCP or the Real Time Protocol, RTP, headers
[RFC3550]). [RFC3550]).
skipping to change at page 12, line 49 skipping to change at page 12, line 49
to a reduction in the requirements for preserving ordering. These to a reduction in the requirements for preserving ordering. These
have promise to simplify network equipment design as well as the have promise to simplify network equipment design as well as the
potential to improve robustness of the transport service. potential to improve robustness of the transport service.
Measurements of reordering can help understand the present level Measurements of reordering can help understand the present level
of reordering within deployed infrastructure, and inform decisions of reordering within deployed infrastructure, and inform decisions
about how to progress such mechanisms. about how to progress such mechanisms.
Operational tools to detect mis-ordered packet flows and quantify the Operational tools to detect mis-ordered packet flows and quantify the
degree or reordering. Key performance indicators are retransmission degree or reordering. Key performance indicators are retransmission
rate, packet drop rate, sector utilisation level, a measure of rate, packet drop rate, sector utilisation level, a measure of
reordering, peak rate, the CE-marking rate, etc. reordering, peak rate, the ECN congestion experienced (CE) marking
rate, etc.
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
skipping to change at page 13, line 27 skipping to change at page 13, line 27
2.1.3. Metrics derived from Network Layer Headers 2.1.3. Metrics derived from Network Layer Headers
Some transport information is made visible in the network-layer Some transport information is made visible in the network-layer
protocol header. These header fields are not encrypted and have been protocol header. These header fields are not encrypted and have been
utilised to make flow observations. utilised to make flow observations.
Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose
flow information in the IPv6 Flow Label field of the network-layer flow information in the IPv6 Flow Label field of the network-layer
header (e.g., [RFC8085]). This can be used to inform network-layer header (e.g., [RFC8085]). This can be used to inform network-layer
queuing, forwarding (e.g., for equal cost multi-path, ECMP, queuing, forwarding (e.g., for Equal Cost Multi-Path, ECMP,
routing, and Link Aggregation, LAG). This can provide useful routing, and Link Aggregation, LAG). This can provide useful
information to assign packets to flows in the data collected by information to assign packets to flows in the data collected by
measurement campaigns. Although important to characterising a measurement campaigns. Although important to characterising a
path, it does not directly provide performance data. path, it does not directly provide performance data.
Use Network-Layer Differentiated Services Code Point Point: Applicati Use Network-Layer Differentiated Services Code Point Point: Applicati
ons can expose their delivery expectations to the network by ons can expose their delivery expectations to the network by
setting the Differentiated Services Code Point (DSCP) field of setting the Differentiated Services Code Point (DSCP) field of
IPv4 and IPv6 packets. This can be used to inform network-layer IPv4 and IPv6 packets. This can be used to inform network-layer
queuing and forwarding, and can also provide information on the queuing and forwarding, and can also provide information on the
skipping to change at page 16, line 27 skipping to change at page 16, line 27
protocols (e.g., the impact of changes in introducing a new transport protocols (e.g., the impact of changes in introducing a new transport
protocol mechanism). This increases the dependency on other indirect protocol mechanism). This increases the dependency on other indirect
sources of information to inform planning and provisioning. sources of information to inform planning and provisioning.
2.2.3. Service Performance Measurement 2.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 measurements While active measurements may be used in-network, passive
can have advantages in terms of eliminating unproductive traffic, measurements can have advantages in terms of eliminating unproductive
reducing the influence of test traffic on the overall traffic mix, test traffic, reducing the influence of test traffic on the overall
and the ability to choose the point of measurement Section 2.2.1. traffic mix, and the ability to choose the point of measurement
However, passive measurements may rely on observing transport Section 2.2.1. However, passive measurements may rely on observing
headers. transport headers.
2.2.4. Measuring Transport to Support Network Operations 2.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
transport circuit breakers [RFC8084]. transport circuit breakers [RFC8084].
skipping to change at page 25, line 17 skipping to change at page 25, line 17
information may also need to be collected to manage denial of service information may also need to be collected to manage denial of service
attacks against the infrastructure. attacks against the infrastructure.
5.3. Accountability and Internet Transport Protocols 5.3. Accountability and Internet Transport Protocols
Information provided by tools observing transport headers can be used Information provided by tools observing transport headers can be used
to classify traffic, and to limit the network capacity used by to classify traffic, and to limit the network capacity used by
certain flows. Operators can potentially use this information to certain flows. Operators can potentially use this information to
prioritise or de-prioritise certain flows or classes of flow, with prioritise or de-prioritise certain flows or classes of flow, with
potential implications for network neutrality, or to rate limit potential implications for network neutrality, or to rate limit
malicious or otherwise undesirable flows (e.g., for DDoS protection, malicious or otherwise undesirable flows (e.g., for Distributed
or to ensure compliance with a traffic profile Section 2.2.4). Denial of Service, DDOS, protection, or to ensure compliance with a
Equally, operators could use analysis of transport headers and traffic profile Section 2.2.4). Equally, operators could use analysis
transport flow state to demonstrate that they are not providing of transport headers and transport flow state to demonstrate that
differential treatment to certain flows. Obfuscating or hiding this they are not providing differential treatment to certain flows.
information using encryption is expected to lead operators and Obfuscating or hiding this information using encryption is expected
maintainers of middleboxes (firewalls, etc.) to seek other methods to to lead operators and maintainers of middleboxes (firewalls, etc.) to
classify, and potentially other mechanisms to condition, network seek other methods to classify, and potentially other mechanisms to
traffic. condition, network traffic.
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].
5.4. Impact on Research, Development and Deployment 5.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
skipping to change at page 29, line 42 skipping to change at page 29, line 42
particular, there is a possibility that designs could evolve to particular, there is a possibility that designs could evolve to
significantly benefit of customers for a specific vendor, and that significantly benefit of customers for a specific vendor, and that
communities with very different network, applications or platforms communities with very different network, applications or platforms
could then suffer at the expense of benefits to their vendors own could then suffer at the expense of benefits to their vendors own
customer base. In such a scenario, there could be no incentive to customer base. In such a scenario, there could be no incentive to
support other applications/products or to work in other networks support other applications/products or to work in other networks
leading to reduced access for new approaches. leading to reduced access for new approaches.
7. Acknowledgements 7. Acknowledgements
The author would like to thank all who have talked to him face-to- The authors would like to thank all who have talked to him face-to-
face or via email. ... face or via email. ...
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 688421.The research and innovation programme under grant agreement No 688421.The
opinions expressed and arguments employed reflect only the authors' opinions expressed and arguments employed reflect only the authors'
view. The European Commission is not responsible for any use that view. The European Commission is not responsible for any use that
may be made of that information. may be made of that information.
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. Authentication, confidentiality protection, and transport protocols. Issues relating to security are discussed in
integrity protection are identified as Transport Features by the various sections of the document.
RFC8095". As currently deployed in the Internet, these features are
generally provided by a protocol or layer on top of the transport
protocol; no current full-featured standards-track transport protocol
provides these features on its own. Therefore, these features are
not considered in this document, with the exception of native
authentication capabilities of TCP and SCTP for which the security
considerations in RFC4895.
Open data, and accessibility to tools that can help understand trends Authentication, confidentiality protection, and integrity protection
in application deployment, network traffic and usage patterns can all are identified as Transport Features by [RFC8095]. As currently
contribute to understanding security challenges. Standard protocols deployed in the Internet, these features are generally provided by a
and understanding of the interactions between mechanisms and traffic protocol or layer on top of the transport protocol [I-D.ietf-taps-
patterns can also provide valuable insight into appropriate security transport-security].
design. Like congestion control mechanisms, security mechanisms are
difficult to design and implement correctly. It is hence recommended Confidentiality and strong integrity checks have properties that can
that applications employ well-known standard security mechanisms such also be incorporated into the deisgn of a transport protocol.
as DTLS, TLS or IPsec, rather than inventing their own. Integrity checks can protect an endpoint from undetected modification
of protocol fields by network devices, whereas encryption and
obfuscation can further prevent these headers being utilised by
network devices. Hiding headers can therefore provide the
opportunity for greater freedom to update the protocols and can ease
experimentation with new techniques and their final deployment in
endpoints. A protocol specification needs to weigh the benefits of
ossifying common headers, versus the potential demerits of exposing
specific information that could be observed along the network path to
provide tools to manage new variants of protocols.
A protocol design that uses header encryption can provide
confidentiality of some or all of the protocol header information.
This prevents an on-path device from knowledge of the header field.
It therefore prevents mechanisms being built that directly rely on
the information or seeks to imply semantics of an exposed header
field. Hiding headers can limit the ability to measure and
characterise traffic.
Exposed transport headers are sometimes utilised as a part of the
information to detect anomalies in network traffic. This can be used
as the first line of defence yo identify potential threats from DOS
or malware and redirect suspect traffic to dedicated nodes
responsible for DOS analysis, malware detection, or to perform packet
scrubbing "Scrubbing" (the normalization of packets so that there are
no ambiguities in interpretation by the ultimate destination of the
packet). These techniques are currently used by some operators to
also defend from distributed DOS attacks.
Exposed transport headers are sometimes also utilised as a part of
the information used by the receiver of a transport protocol to
protect the transport layer from data injection by an attacker. In
evaluating this use of exposed header information, it is important to
consider whether it introduces a significant DOS threat. For
example, an attacker could construct a DOS attack by sending packets
with a sequence number that falls within the currently accepted range
of sequence numbers at the receiving endpoint, this would then
introduce additional work at the receiving endpoint, even though the
data in the attacking packet may not finally be delivered by the
transport layer. This is sometimes known as a "shadowing attack".
An attack can, for example, disrupt receiver processing, trigger loss
and retransmission, or make a receiving endpoint perform unproductive
decryption of packets that cannot be successfully decrypted (forcing
a receiver to commit decryption resources, or to update and then
restore protocol state).
One mitigation to off-path attack is to deny knowledge of what header
information is accepted by a receiver or obfusticate the accepted
header information, e.g., setting a non-predictable initial value for
a sequence number during a protocol handshake, as in [RFC3550] and
[RFC6056], or a port value that can not be predicted (see section 5.1
of [RFC8085]). A receiver could also require additional information
to be used as a part of check before accepting packets at the
transport layer (e.g., utilising a part of the sequence number space
that is encrypted; or by verifying an encrypted token not visible to
an attacker). This would also mitigate on-path attacks. An
additional processing cost can be incurred when decryption needs to
be attempted before a receiver is able to discard injected packets.
Open standards motivate a desire for this evaluation to include
independent observation and evaluation of performance data, which in
turn suggests control over where and when measurement samples are
collected. This requires consideration of the appropriate balance
between encrypting all and no transport information. Open data, and
accessibility to tools that can help understand trends in application
deployment, network traffic and usage patterns can all contribute to
understanding security challenges.
9. IANA Considerations 9. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 31, line 45 skipping to change at page 32, line 45
Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of
Transport Security Protocols", Internet-Draft draft-ietf- Transport Security Protocols", Internet-Draft draft-ietf-
taps-transport-security-01, May 2018. taps-transport-security-01, May 2018.
[I-D.ietf-tcpinc-tcpcrypt] [I-D.ietf-tcpinc-tcpcrypt]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q. and E. Smith, "Cryptographic protection of TCP Streams Q. and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11, (tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11,
November 2017. November 2017.
[I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-
tcpm-accurate-ecn-06, March 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", Internet-Draft draft-ietf-tsvwg-l4s- Architecture", Internet-Draft draft-ietf-tsvwg-l4s-
arch-01, October 2017. arch-01, October 2017.
[I-D.mm-wg-effect-encrypt] [I-D.mm-wg-effect-encrypt]
Moriarty, K. and A. Morton, "Effects of Pervasive Moriarty, K. and A. Morton, "Effects of Pervasive
Encryption on Operators", Internet-Draft draft-mm-wg- Encryption on Operators", Internet-Draft draft-mm-wg-
effect-encrypt-24, March 2018. effect-encrypt-24, March 2018.
skipping to change at page 34, line 22 skipping to change at page 35, line 17
March 2009, <https://www.rfc-editor.org/info/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,
<http://www.rfc-editor.org/info/rfc5559>. <http://www.rfc-editor.org/info/rfc5559>.
[RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>. June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, DOI
10.17487/RFC6056, January 2011, <https://www.rfc-
editor.org/info/rfc6056>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, DOI Roberts, "Issues with IP Address Sharing", RFC 6269, DOI
10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/ 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/
info/rfc6269>. info/rfc6269>.
[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, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://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,
skipping to change at page 35, line 39 skipping to change at page 36, line 39
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in-
UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March
2017, <http://www.rfc-editor.org/info/rfc8086>. 2017, <http://www.rfc-editor.org/info/rfc8086>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, DOI Explicit Congestion Notification (ECN)", RFC 8087, DOI
10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/ 10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/
info/rfc8087>. info/rfc8087>.
[RFC8095] Fairhurst, G., Ed., Trammell, B.Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, DOI 10.17487/
RFC8095, March 2017, <https://www.rfc-editor.org/info/
rfc8095>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>. October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[Tor] The Tor Project, ., "https://www.torproject.org", June [Tor] The Tor Project, ., "https://www.torproject.org", June
2017. 2017.
Appendix A. Revision information Appendix A. Revision information
skipping to change at page 36, line 25 skipping to change at page 37, line 32
email. Added a draft conclusion section to sketch some strawman email. Added a draft conclusion section to sketch some strawman
scenarios that could emerge. scenarios that could emerge.
-07 Updated following comments from Al Morton, Chris Seal, and other -07 Updated following comments from Al Morton, Chris Seal, and other
feedback via email. feedback via email.
-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 11/05/ Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 11/05/
2018, and Spencer Dawkins. 2018, and Spencer Dawkins.
-09 Updated security considerations.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Scotland Scotland
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 24 change blocks. 
105 lines changed or deleted 181 lines changed or added

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