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/ |