idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2018) is 2114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1446, but no explicit reference was found in the text == Unused Reference: 'I-D.dolson-plus-middlebox-benefits' is defined on line 1453, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aqm-codel' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-taps-transport-security' is defined on line 1494, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-plus-statefulness' is defined on line 1526, but no explicit reference was found in the text == Unused Reference: 'RFC3449' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1584, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1625, but no explicit reference was found in the text == Unused Reference: 'RFC6679' is defined on line 1652, but no explicit reference was found in the text == Unused Reference: 'Tor' is defined on line 1717, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-01 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-11 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-01 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-24 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C.S. Perkins 5 Expires: December 14, 2018 University of Glasgow 6 June 14, 2018 8 The Impact of Transport Header Confidentiality on Network Operation and 9 Evolution of the Internet 10 draft-fairhurst-tsvwg-transport-encrypt-09 12 Abstract 14 This document describes implications of applying end-to-end 15 encryption at the transport layer. It identifies in-network uses of 16 transport layer header information. It then reviews the implications 17 of developing end-to-end transport protocols that use authentication 18 to protect the integrity of transport information or encryption to 19 provide confidentiality of the transport protocol header and expected 20 implications of transport protocol design and network operation. 21 Since transport measurement and analysis of the impact of network 22 characteristics have been important to the design of current 23 transport protocols, it also considers the impact on transport and 24 application evolution. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 14, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Current uses of Transport Headers within the Network . . . . . 8 61 2.1. Observing Transport Information in the Network . . . . . . 9 62 2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9 63 2.1.2. Metrics derived from Transport Layer Headers . . . . . 10 64 2.1.3. Metrics derived from Network Layer Headers . . . . . . 13 65 2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14 66 2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 15 67 2.2.2. Use by Operators to Plan and Provision Networks . . . 15 68 2.2.3. Service Performance Measurement . . . . . . . . . . . 16 69 2.2.4. Measuring Transport to Support Network Operations . . 16 70 2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17 71 2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18 72 2.4. Observing Headers to Implement Network Policy . . . . . . 19 73 3. Encryption and Authentication of Transport Headers . . . . . . 19 74 3.1. Authenticating the Transport Protocol Header . . . . . . . 21 75 3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21 76 3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21 77 3.4. Authenticating Transport Information and Selectively 78 Encrypting the Transport Header . . . . . . . . . . . . . 22 79 3.5. Optional Encryption of Header Information . . . . . . . . 22 80 4. Addition of Transport Information to Network-Layer Protocol 81 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5. Implications of Protecting the Transport Headers . . . . . . . 23 83 5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23 84 5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24 85 5.3. Accountability and Internet Transport Protocols . . . . . 25 86 5.4. Impact on Research, Development and Deployment . . . . . . 25 87 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 93 10.2. Informative References . . . . . . . . . . . . . . . . . 31 94 Appendix A. Revision information . . . . . . . . . . . . . . . . . 36 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 97 1. Introduction 98 This document describes implications of applying end-to-end 99 encryption at the transport layer. It reviews the implications of 100 developing end-to-end transport protocols that use encryption to 101 provide confidentiality of the transport protocol header and expected 102 implications of transport protocol design and network operation. It 103 also considers anticipated implications on transport and application 104 evolution. 106 The transport layer provides end-to-end interactions between 107 endpoints (processes) using an Internet path. Transport protocols 108 layer directly over the network-layer service and are sent in the 109 payload of network-layer packets. They support end-to-end 110 communication between applications, supported by higher-layer 111 protocols, running on the end systems (or transport endpoints). This 112 simple architectural view hides one of the core functions of the 113 transport, however, to discover and adapt to the properties of the 114 Internet path that is currently being used. The design of Internet 115 transport protocols is as much about trying to avoid the unwanted 116 side effects of congestion on a flow and other capacity-sharing 117 flows, avoiding congestion collapse, adapting to changes in the path 118 characteristics, etc., as it is about end-to-end feature negotiation, 119 flow control and optimising for performance of a specific 120 application. 122 To achieve stable Internet operations the IETF transport community 123 has to date relied heavily on measurement and insights of the network 124 operations community to understand the trade-offs, and to inform 125 selection of appropriate mechanisms, to ensure a safe, reliable, and 126 robust Internet (e.g., [RFC1273]). In turn, the network operations 127 community relies on being able to understand the pattern and 128 requirements of traffic passing over the Internet, both in aggregate 129 and at the flow level. 131 There are many motivations for deploying encrypted transports 132 [RFC7624] (i.e., transport protocols that use encryption to provide 133 confidentiality of some or all of the transport-layer header 134 information), and encryption of transport payloads (i.e. 135 confidentiality of the payload data). The increasing public concerns 136 about the interference with Internet traffic have led to a rapidly 137 expanding deployment of encryption to protect end-user privacy, in 138 protocols like QUIC [I-D.ietf-quic-transport], but also expected to 139 form a basis of future protocol designs. 141 Some network operators and access providers, have come to rely on the 142 in-network measurement of transport properties and the functionality 143 provided by middleboxes to both support network operations and 144 enhance performance. There can therefore be implications when 145 working with encrypted transport protocols that hide transport header 146 information from the network. These present architectural challenges 147 and considerations in the way transport protocols are designed, and 148 ability to characterise and compare different transport solutions 149 [Measure], Section 2.2. Implementations of network devices are 150 encouraged to avoid side-effects when protocols are updated. 151 Introducing cryptographic integrity checks to header fields can also 152 prevent undetected manipulation of the field by network devices, or 153 undetected addition of information to a packet. However, this does 154 not prevent inspection of the information by a device on path, and it 155 is possible that such devices could develop mechanisms that rely on 156 the presence of such a field, or a known value in the field. 158 Reliance on the presence and semantics of specific header information 159 leads to ossification: An endpoint could be required to supply a 160 specific header to receive the network service that it desires. In 161 some cases, this could be benign or advantageous to the protocol 162 (e.g., recognising the start of a connection, or explicitly exposing 163 protocol information can be expected to provide more consistent 164 decisions by on-path devices than the use of diverse methods to infer 165 semantics from other flow properties). In some cases, this is not 166 beneficial (e.g., a mechanism implemented in a network device, such 167 as a firewall, that required a header field to have only a specific 168 known set of values could prevent the device from forwarding packets 169 using a different version of a protocol that introduces a new feature 170 that changes the value present in this field, preventing evolution of 171 the protocol). 173 A protocol design that uses header encryption can provide 174 confidentiality of some or all of the protocol header information. 175 This prevents an on-path device from knowledge of the header field. 176 It therefore prevents mechanisms being built that directly rely on 177 the information or seeks to imply semantics of an exposed header 178 field. Using encryption to provide confidentiality of the transport 179 layer brings some well-known privacy and security benefits and can 180 therefore help reduce ossification of the transport layer. In 181 particular, it is important that protocols either do not expose 182 information where the usage may change in future protocols, or that 183 methods that utilise the information are robust to potential changes 184 as protocols evolve over time. To avoid unwanted inspection, a 185 protocol could also intentionally vary the format and value of header 186 fields (sometimes known as Greasing [I-D.thomson-quic-grease]). 188 However, while encryption hides the protocol header information, it 189 does not prevent ossification of the network service: People seeking 190 understanding of network traffic could come to rely on pattern 191 inferences and other heuristics as the basis for network decision and 192 to derive measurement data, creating new dependencies on the 193 transport protocol. 195 A level of ossification of the transport header can offer trade-offs 196 around authentication, and confidentiality of transport protocol 197 headers and has the potential to explicitly support for other uses of 198 this header information. For example, a design that provides 199 confidentiality of protocol header information can impact the 200 following activities that rely on measurement and analysis of traffic 201 flows: 203 Network Operations and Research: Observable transport headers enable 204 both operators and the research community to measure and analyse 205 protocol performance, network anomalies, and failure pathologies. 207 This information can help inform capacity planning, and assist in 208 determining the need for equipment and/or configuration changes by 209 network operators. 211 The data can also inform Internet engineering research, and help 212 in the development of new protocols, methodologies, and 213 procedures. Concealing the transport protocol header information 214 makes the stream performance unavailable to passive observers 215 along the path, and likely leads to the development of alternative 216 methods to collect or infer that data. 218 Providing confidentiality of the transport payload, but leaving 219 some, or all, of the transport headers unencrypted, possibly with 220 authentication, can provide the majority of the privacy and 221 security benefits while allowing some measurement. 223 Protection from Denial of Service: Observable transport headers 224 currently provide useful input to classify traffic and detect 225 anomalous events (e.g., changes in application behaviour, 226 distributed denial of service attacks). To be effective, this 227 protection needs to be able to uniquely disambiguate unwanted 228 traffic. An inability to separate this traffic using packet 229 header information may result in less-efficient identification of 230 unwanted traffic or development of different methods (e.g. rate- 231 limiting of uncharacterised traffic). 233 Network Troubleshooting and Diagnostics: Encrypting transport header 234 information eliminates the incentive for operators to troubleshoot 235 what they cannot interpret. A flow experiencing packet loss or 236 jitter looks like an unaffected flow when only observing network 237 layer headers (if transport sequence numbers and flow identifiers 238 are obscured). This limits understanding of the impact of packet 239 loss or latency on the flows, or even localizing the network 240 segment causing the packet loss or latency. Encrypted traffic may 241 imply "don't touch" to some, and could limit a trouble-shooting 242 response to "can't help, no trouble found". The additional 243 mechanisms that will need to be introduced to help reconstruct 244 transport-level metrics add complexity and operational costs 245 (e.g., in deploying additional functions in equipment or adding 246 traffic overhead). 248 Network Traffic Analysis: Hiding transport protocol header 249 information can make it harder to determine which transport 250 protocols and features are being used across a network segment and 251 to measure trends in the pattern of usage. This could impact the 252 ability for an operator to anticipate the need for network 253 upgrades and roll-out. It can also impact the on-going traffic 254 engineering activities performed by operators (such as determining 255 which parts of the path contribute delay, jitter or loss). While 256 the impact may, in many cases, be small there are scenarios where 257 operators directly support particular services (e.g., to 258 troubleshoot issues relating to Quality of Service, QoS; the 259 ability to perform fast re-routing of critical traffic, or support 260 to mitigate the characteristics of specific radio links). The more 261 complex the underlying infrastructure the more important this 262 impact. 264 Open and Verifiable Network Data: Hiding transport protocol header 265 information can reduce the range of actors that can capture useful 266 measurement data. For example, one approach could be to employ an 267 existing transport protocol that reveals little information (e.g., 268 UDP), and perform traditional transport functions at higher layers 269 protecting the confidentiality of transport information. Such a 270 design, limits the information sources available to the Internet 271 community to understand the operation of new transport protocols, 272 so preventing access to the information necessary to inform design 273 decisions and standardisation of the new protocols and related 274 operational practices. 276 The cooperating dependence of network, application, and host to 277 provide communication performance on the Internet is uncertain 278 when only endpoints (i.e., at user devices and within service 279 platforms) can observe performance, and performance cannot be 280 independently verified by all parties. The ability of other 281 stakeholders to review code can help develop deeper insight. In 282 the heterogeneous Internet, this helps extend the range of 283 topologies, vendor equipment, and traffic patterns that are 284 evaluated. 286 Independently captured data is important to help ensure the health 287 of the research and development communities. It can provide input 288 and test scenarios to support development of new transport 289 protocol mechanisms, especially when this analysis can be based on 290 the behaviour experienced in a diversity of deployed networks. 292 Independently verifiable performance metrics might also be 293 important to demonstrate regulatory compliance in some 294 jurisdictions, and provides an important basis for informing 295 design decisions. 297 The last point leads us to consider the impact of hiding transport 298 headers in the specification and development of protocols and 299 standards. This has potential impact on: 301 o Understanding Feature Interactions: An appropriate vantage point, 302 coupled with timing information about traffic flows, provides a 303 valuable tool for benchmarking equipment, functions, and/or 304 configurations, and to understand complex feature interactions. 305 An inability to observe transport protocol information can limit 306 the ability to diagnose and explore interactions between features 307 at different protocol layers, a side-effect of not allowing a 308 choice of vantage point from which this information is observed. 310 o Supporting Common Specifications: Transmission Control Protocol 311 (TCP) is currently the predominant transport protocol used over 312 Internet paths. Its many variants have broadly consistent 313 approaches to avoiding congestion collapse, and to ensuring the 314 stability of the Internet. Increased use of transport layer 315 encryption can overcome ossification, allowing deployment of new 316 transports and different types of congestion control. This 317 flexibility can be beneficial, but it can come at the cost of 318 fragmenting the ecosystem. There is little doubt that developers 319 will try to produce high quality transports for their intended 320 target uses, but it is not clear there are sufficient incentives 321 to ensure good practice that benefits the wide diversity of 322 requirements for the Internet community as a whole. Increased 323 diversity, and the ability to innovate without public scrutiny, 324 risks point solutions that optimise for specific needs, but 325 accidentally disrupt operations of/in different parts of the 326 network. The social contract that maintains the stability of the 327 Internet relies on accepting common specifications, and on the 328 ability to verify that others also conform. 330 o Operational practice: Published transport specifications allow 331 operators to check compliance. This can bring assurance to those 332 operating networks, often avoiding the need to deploy complex 333 techniques that routinely monitor and manage TCP/IP traffic flows 334 (e.g. Avoiding the capital and operational costs of deploying 335 flow rate-limiting and network circuit-breaker methods [RFC8084]). 336 When it is not possible to observe transport header information, 337 methods are still needed to confirm that the traffic produced 338 conforms to the expectations of the operator or developer. 340 o Restricting research and development: Hiding transport information 341 can impede independent research into new mechanisms, measurement 342 of behaviour, and development initiatives. Experience shows that 343 transport protocols are complicated to design and complex to 344 deploy, and that individual mechanisms need to be evaluated while 345 considering other mechanisms, across a broad range of network 346 topologies and with attention to the impact on traffic sharing the 347 capacity. If this results in reduced availability of open data, 348 it could eliminate the independent self-checks to the 349 standardisation process that have previously been in place from 350 research and academic contributors (e.g., the role of the IRTF 351 ICCRG, and research publications in reviewing new transport 352 mechanisms and assessing the impact of their experimental 353 deployment) 355 In summary, there are trade offs. On the one hand, protocol 356 designers have often ignored the implications of whether the 357 information in transport header fields can or will be used by in- 358 network devices, and the implications this places on protocol 359 evolution. This motivates a design that provides confidentiality of 360 the header information. On the other hand, it can be expected that a 361 lack of visibility of transport header information can impact the 362 ways that protocols are deployed, standardised, and their operational 363 support. The choice of whether future transport protocols encrypt 364 their protocol headers therefore needs to be taken based not solely 365 on security and privacy considerations, but also taking into account 366 the impact on operations, standards, and research. Any new Internet 367 transport need to provide appropriate transport mechanisms and 368 operational support to assure the resulting traffic can not result in 369 persistent congestion collapse [RFC2914]. This document suggests 370 that the balance between information exposed and concealed should be 371 carefully considered when specifying new protocols. 373 2. Current uses of Transport Headers within the Network 374 Despite transport headers having end-to-end meaning, some of these 375 transport headers have come to be used in various ways within the 376 Internet. In response to pervasive monitoring [RFC7624] revelations 377 and the IETF consensus that "Pervasive Monitoring is an Attack" 378 [RFC7258], efforts are underway to increase encryption of Internet 379 traffic,. Applying confidentiality to transport header fields would 380 affect how protocol information is used [I-D.mm-wg-effect-encrypt]. 381 To understand these implications, it is first necessary to understand 382 how transport layer headers are currently observed and/or modified by 383 middleboxes within the network. 385 Transport protocols can be designed to encrypt or authenticate 386 transport header fields. Authentication at the transport layer can 387 be used to detect any changes to an immutable header field that were 388 made by a network device along a path. The intentional modification 389 of transport headers by middleboxes (such as Network Address 390 Translation, NAT, or Firewalls) is not considered. Common issues 391 concerning IP address sharing are described in [RFC6269]. 393 2.1. Observing Transport Information in the Network 395 If in-network observation of transport protocol headers is needed, 396 this requires knowledge of the format of the transport header: 398 o Flows need to be identified at the level required to perform the 399 observation; 401 o The protocol and version of the header need to be visible. As 402 protocols evolve over time and there may be a need to introduce 403 new transport headers. This may require interpretation of 404 protocol version information or connection setup information; 406 o The location and syntax of any observed transport headers needs to 407 be known. IETF transport protocols can specify this information. 409 The following subsections describe various ways that observable 410 transport information has been utilised. 412 2.1.1. Flow Identification 414 Transport protocol header information (together with information in 415 the network header), has been used to identify a flow and the 416 connection state of the flow, together with the protocol options 417 being used. In some usages, a low-numbered (well-known) transport 418 port number has been used to identify a protocol (although port 419 information alone is not sufficient to guarantee identification of a 420 protocol, since applications can use arbitrary ports, multiple 421 sessions can be multiplexed on a single port, and ports can be re- 422 used by subsequent sessions). 424 Transport protocols, such as TCP and Stream Control Transport 425 Protocol (SCTP) specify a standard base header that includes sequence 426 number information and other data, with the possibility to negotiate 427 additional headers at connection setup, identified by an option 428 number in the transport header. UDP-based protocols can use, but 429 sometimes do not use, well-known port numbers. Some flows can 430 instead be identified by signalling protocols or through the use of 431 magic numbers placed in the first byte(s) of the datagram payload. 433 Flow identification is a common function. For example, performed by 434 measurement activities, QoS classification, firewalls, Denial of 435 Service, DOS, prevention. It becomes more complex and less easily 436 achieved when multiplexing is used at or above the transport layer. 438 2.1.2. Metrics derived from Transport Layer Headers 440 Some actors manage their portion of the Internet by characterizing 441 the performance of link/network segments. Passive monitoring uses 442 observed traffic to makes inferences from transport headers to derive 443 these measurements. A variety of open source and commercial tools 444 have been deployed that utilise this information. The following 445 metrics can be derived from transport header information: 447 Traffic Rate and Volume: Header information e.g., (sequence number, 448 length) allows derivation of volume measures per-application, to 449 characterise the traffic that uses a network segment or the 450 pattern of network usage. This may be measured per endpoint or 451 for an aggregate of endpoints (e.g., by an operator to assess 452 subscriber usage). It can also be used to trigger measurement- 453 based traffic shaping and to implement QoS support within the 454 network and lower layers. Volume measures can be valuable for 455 capacity planning (providing detail of trends rather than the 456 volume per subscriber). 458 Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from 459 sequence number) and has been used as a metric for performance 460 assessment and to characterise transport behaviour. Understanding 461 the root cause of loss can help an operator determine whether this 462 requires corrective action. Network operators have used the 463 variation in patterns of loss as a key performance metric, 464 utilising this to detect changes in the offered service. 466 There are various causes of loss, including: corruption of link 467 frames (e.g., interference on a radio link), buffer overflow 468 (e.g., due to congestion), policing (traffic management), buffer 469 management (e.g., Active Queue Management, AQM [RFC7567]), 470 inadequate provision of traffic preemption. Understanding flow 471 loss rate requires either maintaining per flow packet counters or 472 by observing sequence numbers in transport headers. Loss can be 473 monitored at the interface level by devices in the network. It is 474 often important to understand the conditions under which packet 475 loss occurs. This usually requires relating loss to the traffic 476 flowing on the network node/segment at the time of loss. 478 Observation of transport feedback information (observing loss 479 reports, e.g., RTP Control Protocol (RTCP) [RFC3550], TCP SACK) 480 can increase understanding of the impact of loss and help identify 481 cases where loss may have been wrongly identified, or the 482 transport did not require the lost packet. It is sometimes more 483 important to understand the pattern of loss, than the loss rate, 484 because losses can often occur as bursts, rather than randomly- 485 timed events. 487 Throughput and Goodput: The throughput achieved by a flow can be 488 determined even when a flow is encrypted, providing the individual 489 flow can be identified. Goodput [RFC7928] is a measure of useful 490 data exchanged (the ratio of useful/total volume of traffic sent 491 by a flow). This requires ability to differentiate loss and 492 retransmission of packets (e.g., by observing packet sequence 493 numbers in the TCP or the Real Time Protocol, RTP, headers 494 [RFC3550]). 496 Latency: Latency is a key performance metric that impacts application 497 response time and user-perceived response time. It often 498 indirectly impacts throughput and flow completion time. Latency 499 determines the reaction time of the transport protocol itself, 500 impacting flow setup, congestion control, loss recovery, and other 501 transport mechanisms. The observed latency can have many 502 components [Latency]. Of these, unnecessary/unwanted queuing in 503 network buffers has often been observed as a significant factor. 504 Once the cause of unwanted latency has been identified, this can 505 often be eliminated. 507 To measure latency across a part of a path, an observation point 508 can measure the experienced round trip time (RTT) using packet 509 sequence numbers, and acknowledgements, or by observing header 510 timestamp information. Such information allows an observation 511 point in the network to determine not only the path RTT, but also 512 to measure the upstream and downstream contribution to the RTT. 514 This has been used to locate a source of latency, e.g., by 515 observing cases where the ratio of median to minimum RTT is large 516 for a part of a path. 518 The service offered by operators can benefit from latency 519 information to understand the impact of deployment and tune 520 deployed services. Latency metrics are key to evaluating and 521 deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit 522 Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements 523 could identify excessively large buffers, indicating where to 524 deploy or configure AQM. An AQM method is often deployed in 525 combination with other techniques, such as scheduling [RFC7567] 526 [I-D.ietf-aqm-fq-codel] and although parameter-less methods are 527 desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D 528 .ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all 529 possible deployment scenarios. 531 Variation in delay: Some network applications are sensitive to small 532 changes in packet timing. To assess the performance of such 533 applications, it can be necessary to measure the variation in 534 delay observed along a portion of the path [RFC3393] [RFC5481]. 535 The requirements resemble those for the measurement of latency. 537 Flow Reordering: Significant flow reordering can impact time-critical 538 applications and can be interpreted as loss by reliable 539 transports. Many transport protocol techniques are impacted by 540 reordering (e.g., triggering TCP retransmission, or re-buffering 541 of real-time applications). Packet reordering can occur for many 542 reasons (from equipment design to misconfiguration of forwarding 543 rules). Since this impacts transport performance, network tools 544 are needed to detect and measure unwanted/excessive reordering. 546 There have been initiatives in the IETF transport area to reduce 547 the impact of reordering within a transport flow, possibly leading 548 to a reduction in the requirements for preserving ordering. These 549 have promise to simplify network equipment design as well as the 550 potential to improve robustness of the transport service. 551 Measurements of reordering can help understand the present level 552 of reordering within deployed infrastructure, and inform decisions 553 about how to progress such mechanisms. 555 Operational tools to detect mis-ordered packet flows and quantify the 556 degree or reordering. Key performance indicators are retransmission 557 rate, packet drop rate, sector utilisation level, a measure of 558 reordering, peak rate, the ECN congestion experienced (CE) marking 559 rate, etc. 561 Metrics have been defined that evaluate whether a network has 562 maintained packet order on a packet-by-packet basis [RFC4737] and 563 [RFC5236]. 565 Techniques for measuring reordering typically observe packet sequence 566 numbers. Some protocols provide in-built monitoring and reporting 567 functions. Transport fields in the RTP header [RFC3550] [RFC4585] 568 can be observed to derive traffic volume measurements and provide 569 information on the progress and quality of a session using RTP. As 570 with other measurement, metadata is often important to understand the 571 context under which the data was collected, including the time, 572 observation point, and way in which metrics were accumulated. The 573 RTCP protocol directly reports some of this information in a form 574 that can be directly visible in the network. A user of summary 575 measurement data needs to trust the source of this data and the 576 method used to generate the summary information. 578 2.1.3. Metrics derived from Network Layer Headers 580 Some transport information is made visible in the network-layer 581 protocol header. These header fields are not encrypted and have been 582 utilised to make flow observations. 584 Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose 585 flow information in the IPv6 Flow Label field of the network-layer 586 header (e.g., [RFC8085]). This can be used to inform network-layer 587 queuing, forwarding (e.g., for Equal Cost Multi-Path, ECMP, 588 routing, and Link Aggregation, LAG). This can provide useful 589 information to assign packets to flows in the data collected by 590 measurement campaigns. Although important to characterising a 591 path, it does not directly provide performance data. 593 Use Network-Layer Differentiated Services Code Point Point: Applicati 594 ons can expose their delivery expectations to the network by 595 setting the Differentiated Services Code Point (DSCP) field of 596 IPv4 and IPv6 packets. This can be used to inform network-layer 597 queuing and forwarding, and can also provide information on the 598 relative importance of packet information collected by measurement 599 campaigns, but does not directly provide performance data. 601 This field provides explicit information that can be used in place 602 of inferring traffic requirements (e.g., by inferring QoS 603 requirements from port information via a multi-field classifier). 604 The DSCP value can therefore impact the quality of experience for 605 a flow. Observations of service performance need to consider this 606 field when a network path has support for differentiated service 607 treatment. 609 Use of Explicit Congestion Marking: ECN [RFC3168] is an optional 610 transport mechanism that uses a code point in the network-layer 611 header. Use of ECN can offer gains in terms of increased 612 throughput, reduced delay, and other benefits when used over a 613 path that includes equipment that supports an AQM method that 614 performs Congestion Experienced (CE) marking of IP packets 615 [RFC8087]. 617 ECN exposes the presence of congestion on a network path to the 618 transport and network layer. The reception of CE-marked packets 619 can therefore be used to monitor the presence and estimate the 620 level of incipient congestion on the upstream portion of the path 621 from the point of observation (Section 2.5 of [RFC8087]). Because 622 ECN marks are carried in the IP protocol header, it is much easier 623 to measure ECN than to measure packet loss. However, interpreting 624 the marking behaviour (i.e., assessing congestion and diagnosing 625 faults) requires context from the transport layer (path RTT, 626 visibility of loss - that could be due to queue overflow, 627 congestion response, etc) [RFC7567]. 629 Some ECN-capable network devices can provide richer (more frequent 630 and fine-grained) indication of their congestion state. Setting 631 congestion marks proportional to the level of congestion (e.g., 632 Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable 633 throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. 635 Use of ECN requires a transport to feed back reception information 636 on the path towards the data sender. Exposure of this Transport 637 ECN feedback provides an additional powerful tool to understand 638 ECN-enabled AQM-based networks [RFC8087]. 640 AQM and ECN offer a range of algorithms and configuration options, 641 it is therefore important for tools to be available to network 642 operators and researchers to understand the implication of 643 configuration choices and transport behaviour as use of ECN 644 increases and new methods emerge [RFC7567] [RFC8087]. ECN- 645 monitoring is expected to become important as AQM is deployed that 646 supports ECN [RFC8087]. 648 2.2. Transport Measurement 650 The common language between network operators and application/content 651 providers/users is packet transfer performance at a layer that all 652 can view and analyse. For most packets, this has been transport 653 layer, until the emergence of QUIC, with the obvious exception of 654 Virtual Private Networks (VPNs) and IPsec. 656 When encryption conceals more layers in each packet, people seeking 657 understanding of the network operation rely more on pattern 658 inferences and other heuristics reliance on pattern inferences and 659 accuracy suffers. For example, the traffic patterns between server 660 and browser are dependent on browser supplier and version, even when 661 the sessions use the same server application (e.g., web e-mail 662 access). It remains to be seen whether more complex inferences can be 663 mastered to produce the same monitoring accuracy (see section 2.1.1 664 of [I-D.mm-wg-effect-encrypt]). 666 When measurement datasets are made available by servers or client 667 endpoints, additional metadata, such as the state of the network, is 668 often required to interpret this data. Collecting and coordinating 669 such metadata is more difficult when the observation point is at a 670 different location to the bottleneck/device under evaluation. 672 Packet sampling techniques can be used to scale the processing 673 involved in observing packets on high rate links. This exports only 674 the packet header information of (randomly) selected packets. The 675 utility of these measurements depends on the type of bearer and 676 number of mechanisms used by network devices. Simple routers are 677 relatively easy to manage, a device with more complexity demands 678 understanding of the choice of many system parameters. This level of 679 complexity exists when several network methods are combined. 681 This section discusses topics concerning observation of transport 682 flows, with a focus on transport measurement. 684 2.2.1. Point of Measurement 686 Often measurements can only be understood in the context of the other 687 flows that share a bottleneck. A simple example is monitoring of 688 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 689 queues (statistically assigned per flow), management of the queue 690 length (CODEL), flow-scheduling, and a starvation prevention 691 mechanism. Usually such algorithms are designed to be self-tuning, 692 but current methods typically employ heuristics that can result in 693 more loss under certain path conditions (e.g., large RTT, effects of 694 multiple bottlenecks [RFC7567]). 696 In-network measurements can distinguish between upstream and 697 downstream metrics with respect to a measurement point. These are 698 particularly useful for locating the source of problems or to assess 699 the performance of a network segment or a particular device 700 configuration. By correlating observations of headers at multiple 701 points along the path (e.g., at the ingress and egress of a network 702 segment), an observer can determine the contribution of a portion of 703 the path to an observed metric (to locate a source of delay, jitter, 704 loss, reordering, congestion marking, etc.). 706 2.2.2. Use by Operators to Plan and Provision Networks 707 Traffic measurements (e.g., traffic volume, loss, latency) is used by 708 operators to help plan deployment of new equipment and configurations 709 in their networks. Data is also important to equipment vendors who 710 need to understand traffic trends and patterns of usage as inputs to 711 decisions about planning products and provisioning for new 712 deployments. This measurement information can also be correlated 713 with billing information when this is also collected by an operator. 715 A network operator supporting traffic that uses transport header 716 encryption may not have access to per-flow measurement data. Trends 717 in aggregate traffic can be observed and can be related to the 718 endpoint addresses being used, but it may not be possible to 719 correlate patterns in measurements with changes in transport 720 protocols (e.g., the impact of changes in introducing a new transport 721 protocol mechanism). This increases the dependency on other indirect 722 sources of information to inform planning and provisioning. 724 2.2.3. Service Performance Measurement 726 Traffic measurements (e.g., traffic volume, loss, latency) can be 727 used by various actors to help analyse the performance offered to the 728 users of a network segment, and inform operational practice. 730 While active measurements may be used in-network, passive 731 measurements can have advantages in terms of eliminating unproductive 732 test traffic, reducing the influence of test traffic on the overall 733 traffic mix, and the ability to choose the point of measurement 734 Section 2.2.1. However, passive measurements may rely on observing 735 transport headers. 737 2.2.4. Measuring Transport to Support Network Operations 739 Information provided by tools observing transport headers can help 740 determine whether mechanisms are needed in the network to prevent 741 flows from acquiring excessive network capacity. Operators can 742 implement operational practices to manage traffic flows (e.g., to 743 prevent flows from acquiring excessive network capacity under severe 744 congestion) by deploying rate-limiters, traffic shaping or network 745 transport circuit breakers [RFC8084]. 747 Congestion Control Compliance of Traffic: Congestion control is a key 748 transport function [RFC2914]. Many network operators implicitly 749 accept that TCP traffic to comply with a behaviour that is 750 acceptable for use in the shared Internet. TCP algorithms have 751 been continuously improved over decades, and they have reached a 752 level of efficiency and correctness that custom application-layer 753 mechanisms will struggle to easily duplicate [RFC8085]. 755 A standards-compliant TCP stack provides congestion control may 756 therefore be judged safe for use across the Internet. 757 Applications developed on top of well-designed transports can be 758 expected to appropriately control their network usage, reacting 759 when the network experiences congestion, by back-off and reduce 760 the load placed on the network. This is the normal expected 761 behaviour for IETF-specified transport (e.g., TCP and SCTP). 763 However, when anomalies are detected, tools can interpret the 764 transport protocol header information to help understand the 765 impact of specific transport protocols (or protocol mechanisms) on 766 the other traffic that shares a network. An observation in the 767 network can gain understanding of the dynamics of a flow and its 768 congestion control behaviour. Analysing observed packet sequence 769 numbers can be used to help build confidence that an application 770 flow backs-off its share of the network load in the face of 771 persistent congestion, and hence to understand whether the 772 behaviour is appropriate for sharing limited network capacity. 773 For example, it is common to visualise plots of TCP sequence 774 numbers versus time for a flow to understand how a flow shares 775 available capacity, deduce its dynamics in response to congestion, 776 etc. 778 Congestion Control Compliance for UDP traffic UDP provides a minimal 779 message-passing datagram transport that has no inherent congestion 780 control mechanisms. Because congestion control is critical to the 781 stable operation of the Internet, applications and other protocols 782 that choose to use UDP as a transport are required to employ 783 mechanisms to prevent congestion collapse, avoid unacceptable 784 contributions to jitter/latency, and to establish an acceptable 785 share of capacity with concurrent traffic [RFC8085]. 787 A network operator needs tools to understand if datagram flows 788 comply with congestion control expectations and therefore whether 789 there is a need to deploy methods such as rate-limiters, transport 790 circuit breakers or other methods to enforce acceptable usage for 791 the offered service. 793 UDP flows that expose a well-known header by specifying the format 794 of header fields can allow information to be observed to gain 795 understanding of the dynamics of a flow and its congestion control 796 behaviour. For example, tools exist to monitor various aspects of 797 the RTP and RTCP header information of real-time flows (see 798 Section 2.1.2. 800 2.3. Use for Network Diagnostics and Troubleshooting 801 Transport header information can be useful for a variety of 802 operational tasks [I-D.mm-wg-effect-encrypt]: to diagnose network 803 problems, assess network provider performance, evaluate equipment/ 804 protocol performance, capacity planning, management of security 805 threats (including denial of service), and responding to user 806 performance questions. Sections 3.1.2 and 5 of [I-D.mm-wg-effect- 807 encrypt] provide further examples. These tasks seldom involve the 808 need to determine the contents of the transport payload, or other 809 application details. 811 A network operator supporting traffic that uses transport header 812 encryption can see only encrypted transport headers. This prevents 813 deployment of performance measurement tools that rely on transport 814 protocol information. Choosing to encrypt all the information 815 reduces the operator's ability to observe transport performance, and 816 may limit the ability of network operators to trace problems, make 817 appropriate QoS decisions, or response to other queries about the 818 network service. For some this will be blessing, for others it may 819 be a curse. For example, operational performance data about 820 encrypted flows needs to be determined by traffic pattern analysis, 821 rather than relying on traditional tools. This can impact the 822 ability of the operator to respond to faults, it could require 823 reliance on endpoint diagnostic tools or user involvement in 824 diagnosing and troubleshooting unusual use cases or non-trivial 825 problems. A key need here is for tools to provide useful information 826 during network anomalies (e.g., significant reordering, high or 827 intermittent loss). Although many network operators utilise transport 828 information as a part of their operational practice, the network will 829 not break because transport headers are encrypted, and this may 830 require alternative tools may need to be developed and deployed. 832 2.3.1. Examples of measurements 834 Measurements can be used to monitor the health of a portion of the 835 Internet, to provide early warning of the need to take action. They 836 can assist in debugging and diagnosing the root causes of faults that 837 concern a particular user's traffic. They can also be used to 838 support post-mortem investigation after an anomaly to determine the 839 root cause of a problem. 841 In some case, measurements may involve active injection of test 842 traffic to complete a measurement. However, most operators do not 843 have access to user equipment, and injection of test traffic may be 844 associated with costs in running such tests (e.g., the implications 845 of bandwidth tests in a mobile network are obvious). Some active 846 measurements (e.g., response under load or particular workloads) 847 perturb other traffic, and could require dedicated access to the 848 network segment. An alternative approach is to use in-network 849 techniques that observe transport packet headers in operational 850 networks to make the measurements. 852 In other cases, measurement involves dissecting network traffic 853 flows. The observed transport layer information can help identify 854 whether the link/network tuning is effective and alert to potential 855 problems that can be hard to derive from link or device measurements 856 alone. The design trade-offs for radio networks are often very 857 different to those of wired networks. A radio-based network (e.g., 858 cellular mobile, enterprise WiFi, satellite access/back-haul, point- 859 to-point radio) has the complexity of a subsystem that performs radio 860 resource management,s with direct impact on the available capacity, 861 and potentially loss/reordering of packets. The impact of the 862 pattern of loss and congestion, differs for different traffic types, 863 correlation with propagation and interference can all have 864 significant impact on the cost and performance of a provided service. 865 The need for this type of information is expected to increase as 866 operators bring together heterogeneous types of network equipment and 867 seek to deploy opportunistic methods to access radio spectrum. 869 2.4. Observing Headers to Implement Network Policy 871 Information from the transport protocol can be used by a multi-field 872 classifier as a part of policy framework. Policies are commonly used 873 for management of the QoS or Quality of Experience (QoE) in resource- 874 constrained networks and by firewalls that use the information to 875 implement access rules (see also section 2.2.2 of [I-D.mm-wg-effect- 876 encrypt]). Traffic that cannot be classified, will typically receive 877 a default treatment. 879 3. Encryption and Authentication of Transport Headers 881 End-to-end encryption can be applied at various protocol layers. It 882 can be applied above the transport to encrypt the transport payload. 883 Encryption methods can hide information from an eavesdropper in the 884 network. Encryption can also help protect the privacy of a user, by 885 hiding data relating to user/device identity or location. Neither an 886 integrity check nor encryption methods prevent traffic analysis, and 887 usage needs to reflect that profiling of users, identification of 888 location and fingerprinting of behaviour can take place even on 889 encrypted traffic flows. 891 There are several motivations: 893 o One motive to use encryption is a response to perceptions that the 894 network has become ossified by over-reliance on middleboxes that 895 prevent new protocols and mechanisms from being deployed. This 896 has lead to a perception that there is too much "manipulation" of 897 protocol headers within the network, and that designing to deploy 898 in such networks is preventing transport evolution. In the light 899 of this, a method that authenticates transport headers may help 900 improve the pace of transport development, by eliminating the need 901 to always consider deployed middleboxes [I-D.trammell-plus- 902 abstract-mech], or potentially to only explicitly enable middlebox 903 use for particular paths with particular middleboxes that are 904 deliberately deployed to realise a useful function for the network 905 and/or users[RFC3135]. 907 o Another motivation stems from increased concerns about privacy and 908 surveillance. Some Internet users have valued the ability to 909 protect identity, user location, and defend against traffic 910 analysis, and have used methods such as IPsec Encapsulated 911 Security Payload (ESP), Virtual Private Networks (VPNs) and other 912 encrypted tunnel technologies. Revelations about the use of 913 pervasive surveillance [RFC7624] have, to some extent, eroded 914 trust in the service offered by network operators, and following 915 the Snowden revelation in the USA in 2013 has led to an increased 916 desire for people to employ encryption to avoid unwanted 917 "eavesdropping" on their communications. Concerns have also been 918 voiced about the addition of information to packets by third 919 parties to provide analytics, customization, advertising, cross- 920 site tracking of users, to bill the customer, or to selectively 921 allow or block content. Whatever the reasons, there are now 922 activities in the IETF to design new protocols that may include 923 some form of transport header encryption (e.g., QUIC [I-D.ietf- 924 quic-transport]). 926 Authentication methods (that provide integrity checks of protocols 927 fields) have also been specified at the network layer, and this also 928 protects transport header fields. The network layer itself carries 929 protocol header fields that are increasingly used to help forwarding 930 decisions reflect the need of transport protocols, such as the IPv6 931 Flow Label [RFC6437], the DSCP and ECN. 933 The use of transport layer authentication and encryption exposes a 934 tussle between middlebox vendors, operators, applications developers 935 and users. 937 o On the one hand, future Internet protocols that enable large-scale 938 encryption assist in the restoration of the end-to-end nature of 939 the Internet by returning complex processing to the endpoints, 940 since middleboxes cannot modify what they cannot see. 942 o On the other hand, encryption of transport layer header 943 information has implications for people who are responsible for 944 operating networks and researchers and analysts seeking to 945 understand the dynamics of protocols and traffic patterns. 947 Whatever the motives, a decision to use pervasive of transport header 948 encryption will have implications on the way in which design and 949 evaluation is performed, and which can in turn impact the direction 950 of evolution of the TCP/IP stack. While the IETF can specify 951 protocols, the success in actual deployment is often determined by 952 many factors [RFC5218] that are not always clear at the time when 953 protocols are being defined. 955 The next subsections briefly review some security design options for 956 transport protocols. A Survey of Transport Security Protocols [I-D 957 .ietf-taps-transport-security] provides more details concerning 958 commonly used encryption methods at the transport layer. 960 3.1. Authenticating the Transport Protocol Header 962 Transport layer header information can be authenticated. An 963 integrity check that protects the immutable transport header fields, 964 but can still expose the transport protocol header information in the 965 clear, allowing in-network devices to observes these fields. An 966 integrity check can not prevent in-network modification, but can 967 avoid a receiving accepting changes and avoid impact on the transport 968 protocol operation. 970 An example transport authentication mechanism is TCP-Authentication 971 (TCP-AO) [RFC5925]. This TCP option authenticates the IP pseudo 972 header, TCP header, and TCP data. TCP-AO protects the transport 973 layer, preventing attacks from disabling the TCP connection itself 974 and provides replay protection. TCP-AO may interact with 975 middleboxes, depending on their behaviour [RFC3234]. 977 The IPsec Authentication Header (AH) [RFC4302] was designed to work 978 at the network layer and authenticate the IP payload. This approach 979 authenticates all transport headers, and verifies their integrity at 980 the receiver, preventing in-network modification. 982 3.2. Encrypting the Transport Payload 984 The transport layer payload can be encrypted to protect the content 985 of transport segments. This leaves transport protocol header 986 information in the clear. The integrity of immutable transport 987 header fields could be protected by combining this with an integrity 988 check (Section 3.1). 990 Examples of encrypting the payload include Transport Layer Security 991 (TLS) over TCP [RFC5246] [RFC7525], Datagram TLS (DTLS) over UDP 992 [RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which 993 permits opportunistic encryption of the TCP transport payload. 995 3.3. Encrypting the Transport Header 996 The network layer payload could be encrypted (including the entire 997 transport header and the payload). This method provides 998 confidentiality of the entire transport packet. It therefore does 999 not expose any transport information to devices in the network, which 1000 also prevents modification along a network path. 1002 One example of encryption at the network layer is use of IPsec 1003 Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This 1004 encrypts and authenticates all transport headers, preventing 1005 visibility of the transport headers by in-network devices. Some 1006 Virtual Private Network (VPN) methods also encrypt these headers. 1008 3.4. Authenticating Transport Information and Selectively Encrypting 1009 the Transport Header 1011 A transport protocol design can encrypt selected header fields, while 1012 also choosing to authenticate fields in the transport header. This 1013 allows specific transport header fields to be made observable by 1014 network devices. End-to end integrity checks can prevent an endpoint 1015 from undetected modification of the immutable transport headers. 1017 Mutable fields in the transport header provide opportunities for 1018 middleboxes to modify the transport behaviour (e.g., the extended 1019 headers described in [I-D.trammell-plus-abstract-mech]). This 1020 considers only immutable fields in the transport headers, that is, 1021 fields that may be authenticated End-to-End across a path. 1023 An example of a method that encrypts some, but not all, transport 1024 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 1026 3.5. Optional Encryption of Header Information 1028 There are implications to the use of optional header encryption in 1029 the design of a transport protocol, where support of optional 1030 mechanisms can increase the complexity of the protocol and its 1031 implementation and in the management decisions that are required to 1032 use variable format fields. Instead, fields of a specific type ought 1033 to always be sent with the same level of confidentiality or integrity 1034 protection. 1036 4. Addition of Transport Information to Network-Layer Protocol Headers 1038 Transport protocol information can be made visible in a network-layer 1039 header. This has the advantage that this information can then be 1040 observed by in-network devices. This has the advantage that a single 1041 header can support all transport protocols, but there may also be 1042 less desirable implications of separating the operation of the 1043 transport protocol from the measurement framework. 1045 Some measurements may be made by adding additional protocol headers 1046 carrying operations, administration and management (OAM) information 1047 to packets at the ingress to a maintenance domain (e.g., an Ethernet 1048 protocol header with timestamps and sequence number information using 1049 a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) 1050 and removing the additional header at the egress of the maintenance 1051 domain. This approach enables some types of measurements, but does 1052 not cover the entire range of measurements described in this 1053 document. In some cases, it can be difficult to position measurement 1054 tools at the required segments/nodes and there can be challenges in 1055 correlating the downsream/upstream information when in-band OAM data 1056 is inserted by an on-path device. 1058 Another example of a network-layer approach is the IPv6 Performance 1059 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 1060 pdm-option]. This allows a sender to optionally include a 1061 destination option that caries header fields that can be used to 1062 observe timestamps and packet sequence numbers. This information 1063 could be authenticated by receiving transport endpoints when the 1064 information is added at the sender and visible at the receiving 1065 endpoint, although methods to do this have not currently been 1066 proposed. This method needs to be explicitly enabled at the sender. 1068 It can be undesirable to rely on methods requiring the presence of 1069 network options or extension headers. IPv4 network options are often 1070 not supported (or are carried on a slower processing path) and some 1071 IPv6 networks are also known to drop packets that set an IPv6 header 1072 extension (e.g., [RFC7872]). Another disadvantage is that protocols 1073 that separately expose header information do not necessarily have an 1074 advantage to expose the information that is utilised by the protocol 1075 itself, and could manipulate this header information to gain an 1076 advantage from the network. 1078 5. Implications of Protecting the Transport Headers 1080 The choice of which fields to expose and which to encrypt is a design 1081 choice for the transport protocol. Any selective encryption method 1082 requires trading two conflicting goals for a transport protocol 1083 designer to decide which header fields to encrypt. Security work 1084 typically employs a design technique that seeks to expose only what 1085 is needed. However, there can be performance and operational 1086 benefits in exposing selected information to network tools. 1088 This section explores key implications of working with encrypted 1089 transport protocols. 1091 5.1. Independent Measurement 1092 Independent observation by multiple actors is important for 1093 scientific analysis. Encrypting transport header encryption changes 1094 the ability for other actors to collect and independently analyse 1095 data. Internet transport protocols employ a set of mechanisms. Some 1096 of these need to work in cooperation with the network layer - loss 1097 detection and recovery, congestion detection and congestion control, 1098 some of these need to work only End-to-End (e.g., parameter 1099 negotiation, flow-control). 1101 When encryption conceals information in the transport header, it 1102 could be possible for an applications to provide summary data on 1103 performance and usage of the network. This data could be made 1104 available to other actors. However, this data needs to contain 1105 sufficient detail to understand (and possibly reconstruct the network 1106 traffic pattern for further testing) and to be correlated with the 1107 configuration of the network paths being measured. 1109 Sharing information between actors needs also to consider the privacy 1110 of the user and the incentives for providing accurate and detailed 1111 information. Protocols that expose the state information used by the 1112 transport protocol in their header information (e.g., timestamps used 1113 to calculate the RTT, packet numbers used to asses congestion and 1114 requests for retransmission) provide an incentive for the sending 1115 endpoint to provide correct information, increasing confidence that 1116 the observer understands the transport interaction with the network. 1117 This becomes important when considering changes to transport 1118 protocols, changes in network infrastructure, or the emergence of new 1119 traffic patterns. 1121 5.2. Characterising "Unknown" Network Traffic 1123 The patterns and types of traffic that share Internet capacity 1124 changes with time as networked applications, usage patterns and 1125 protocols continue to evolve. 1127 If "unknown" or "uncharacterised" traffic patterns form a small part 1128 of the traffic aggregate passing through a network device or segment 1129 of the network the path, the dynamics of the uncharacterised traffic 1130 may not have a significant collateral impact on the performance of 1131 other traffic that shares this network segment. Once the proportion 1132 of this traffic increases, the need to monitor the traffic and 1133 determine if appropriate safety measures need to be put in place. 1135 Tracking the impact of new mechanisms and protocols requires traffic 1136 volume to be measured and new transport behaviours to be identified. 1137 This is especially true of protocols operating over a UDP substrate. 1139 The level and style of encryption needs to be considered in 1140 determining how this activity is performed. On a shorter timescale, 1141 information may also need to be collected to manage denial of service 1142 attacks against the infrastructure. 1144 5.3. Accountability and Internet Transport Protocols 1146 Information provided by tools observing transport headers can be used 1147 to classify traffic, and to limit the network capacity used by 1148 certain flows. Operators can potentially use this information to 1149 prioritise or de-prioritise certain flows or classes of flow, with 1150 potential implications for network neutrality, or to rate limit 1151 malicious or otherwise undesirable flows (e.g., for Distributed 1152 Denial of Service, DDOS, protection, or to ensure compliance with a 1153 traffic profile Section 2.2.4). Equally, operators could use analysis 1154 of transport headers and transport flow state to demonstrate that 1155 they are not providing differential treatment to certain flows. 1156 Obfuscating or hiding this information using encryption is expected 1157 to lead operators and maintainers of middleboxes (firewalls, etc.) to 1158 seek other methods to classify, and potentially other mechanisms to 1159 condition, network traffic. 1161 A lack of data reduces the level of precision with which flows can be 1162 classified and conditioning mechanisms are applied (e.g., rate 1163 limiting, circuit breaker techniques [RFC8084], or blocking of 1164 uncharacterised traffic), and this needs to be considered when 1165 evaluating the impact of designs for transport encryption [RFC5218]. 1167 5.4. Impact on Research, Development and Deployment 1169 The majority of present Internet applications use two well-known 1170 transport protocols: e.g., TCP and UDP. Although TCP represents the 1171 majority of current traffic, some important real-time applications 1172 use UDP, and much of this traffic utilises RTP format headers in the 1173 payload of the UDP datagram. Since these protocol headers have been 1174 fixed for decades, a range of tools and analysis methods have became 1175 common and well-understood. Over this period, the transport protocol 1176 headers have mostly changed slowly, and so also the need to develop 1177 tools track new versions of the protocol. 1179 Looking ahead, there will be a need to update these protocols and to 1180 develop and deploy new transport mechanisms and protocols. There are 1181 both opportunities and also challenges to the design, evaluation and 1182 deployment of new transport protocol mechanisms. 1184 Integrity checks can protect an endpoint from undetected modification 1185 of protocol fields by network devices, whereas encryption and 1186 obfuscation can further prevent these headers being utilised by 1187 network devices. Hiding headers can therefore provide the 1188 opportunity for greater freedom to update the protocols and can ease 1189 experimentation with new techniques and their final deployment in 1190 endpoints. 1192 Hiding headers can limit the ability to measure and characterise 1193 traffic. Measurement data is increasingly being used to inform 1194 design decisions in networking research, during development of new 1195 mechanisms and protocols and in standardisation. Measurement has a 1196 critical role in the design of transport protocol mechanisms and 1197 their acceptance by the wider community (e.g., as a method to judge 1198 the safety for Internet deployment). Observation of pathologies are 1199 also important in understanding the interactions between cooperating 1200 protocols and network mechanism, the implications of sharing capacity 1201 with other traffic and the impact of different patterns of usage. 1203 Evolution and the ability to understand (measure) the impact need to 1204 proceed hand-in-hand. Attention needs to be paid to the expected 1205 scale of deployment of new protocols and protocol mechanisms. 1206 Whatever the mechanism, experience has shown that it is often 1207 difficult to correctly implement combination of mechanisms [RFC8085]. 1208 These mechanisms therefore typically evolve as a protocol matures, or 1209 in response to changes in network conditions, changes in network 1210 traffic or changes to application usage. 1212 New transport protocol formats are expected to facilitate an 1213 increased pace of transport evolution, and with it the possibility to 1214 experiment with and deploy a wide range of protocol mechanisms. 1215 There has been recent interest in a wide range of new transport 1216 methods, e.g., Larger Initial Window, Proportional Rate Reduction 1217 (PRR), congestion control methods based on measuring bottleneck 1218 bandwidth and round-trip propagation time, the introduction of AQM 1219 techniques and new forms of ECN response (e.g., Data Centre TCP, 1220 DCTP, and methods proposed for L4S).The growth and diversity of 1221 applications and protocols using the Internet also continues to 1222 expand. For each new method or application it is desirable to build 1223 a body of data reflecting its behaviour under a wide range of 1224 deployment scenarios, traffic load, and interactions with other 1225 deployed/candidate methods. 1227 Open standards motivate a desire for this evaluation to include 1228 independent observation and evaluation of performance data, which in 1229 turn suggests control over where and when measurement samples are 1230 collected. This requires consideration of the appropriate balance 1231 between encrypting all and no transport information. 1233 6. Conclusions 1235 The majority of present Internet applications use two well-known 1236 transport protocols: e.g., TCP and UDP. Although TCP represents the 1237 majority of current traffic, some important real-time applications 1238 have used UDP, and much of this traffic utilises RTP format headers 1239 in the payload of the UDP datagram. Since these protocol headers 1240 have been fixed for decades, a range of tools and analysis methods 1241 have became common and well-understood. Over this period, the 1242 transport protocol headers have mostly changed slowly, and so also 1243 the need to develop tools track new versions of the protocol. 1245 Confidentiality and strong integrity checks have properties that are 1246 being incorporated into new protocols and which have important 1247 benefits. The pace of development of transports using the WebRTC 1248 data channel and the rapid deployment of QUIC prototype transports 1249 can both be attributed to using a combination of UDP transport and 1250 confidentiality of the UDP payload. 1252 The traffic that can be observed by on-path network devices is a 1253 function of transport protocol design/options, network use, 1254 applications and user characteristics. In general, when only a small 1255 proportion of the traffic has a specific (different) characteristic. 1256 Such traffic seldom leads to an operational issue although the 1257 ability to measure and monitor it is less. The desire to understand 1258 the traffic and protocol interactions typically grows as the 1259 proportion of traffic increases in volume. The challenges increase 1260 when multiple instances of an evolving protocol contribute to the 1261 traffic that share network capacity. 1263 An increased pace of evolution therefore needs to be accompanied by 1264 methods that can be successfully deployed and used across operational 1265 networks. This leads to a need for network operators (at various 1266 level (ISPs, enterprises, firewall maintainer, etc) to identify 1267 appropriate operational support functions and procedures. 1269 Protocols that change their transport header format (wire format) or 1270 their behaviour (e.g., algorithms that are needed to classify and 1271 characterise the protocol), will require new tooling needs to be 1272 developed to catch-up with the changes. If the currently deployed 1273 tools and methods are no longer relevant and performance may not be 1274 correctly measured. This can increase the response-time after 1275 faults, and can impact the ability to manage the network resulting in 1276 traffic causing traffic to be treated inappropriately (e.g., rate 1277 limiting because of being incorrectly classified/monitored). There 1278 are benefits in exposing consistent information to the network that 1279 avoids traffic being mis-classified and then receiving a default 1280 treatment by the network. 1282 As a part of its design a new protocol specification therefore needs 1283 to weigh the benefits of ossifying common headers, versus the 1284 potential demerits of exposing specific information that could be 1285 observed along the network path to provide tools to manage new 1286 variants of protocols. Several scenarios to illustrate different 1287 ways this could evolve are provided below: 1289 o One scenario is when transport protocols provide consistent 1290 information to the network by intentionally exposing a part of the 1291 transport header. The design fixes the format of this information 1292 between versions of the protocol. This ossification of the 1293 transport header allows an operator to establish tooling and 1294 procedures that enable it to provide consistent traffic management 1295 as the protocol evolves. In contrast to TCP (where all protocol 1296 information is exposed), evolution of the transport is facilitated 1297 by providing cryptographic integrity checks of the transport 1298 header fields (preventing undetected middlebox changes) and 1299 encryption of other protocol information (preventing observation 1300 within the network, or incentivising the use of the exposed 1301 information, rather than inferring information from other 1302 characteristics of the flow traffic). The exposed transport 1303 information can be used by operators to provide troubleshooting, 1304 measurement and any necessary functions appropriate to the class 1305 of traffic (priority, retransmission, reordering, circuit 1306 breakers, etc). 1308 o An alternative scenario adopts different design goals, with a 1309 different outcome. A protocol that encrypts all header 1310 information forces network operators to act independently from 1311 apps/transport developments to provide the transport information 1312 they need. A range of approaches may proliferate, as in current 1313 networks, operators can add a shim header to each packet as a flow 1314 as it crosses the network; other operators/managers could develop 1315 heuristics and pattern recognition to derive information that 1316 classifies flows and estimates quality metrics for the service 1317 being used; some could decide to rate-limit or block traffic until 1318 new tooling is in place. In many cases, the derived information 1319 can be used by operators to provide necessary functions 1320 appropriate to the class of traffic (priority, retransmission, 1321 reordering, circuit breakers, etc). Troubleshooting, and 1322 measurement becomes more difficult, and more diverse. This could 1323 require additional information beyond that visible in the packet 1324 header and when this information is used to inform decisions by 1325 on-path devices it can lead to dependency on other characteristics 1326 of the flow. In some cases, operators might need access to keying 1327 information to interpret encrypted data that they observe. Some 1328 use cases could demand use of transports that do not use 1329 encryption. 1331 The outcome could have significant implications on the way the 1332 Internet architecture develops. It exposes a risk that significant 1333 actors (e.g., developers and transport designers) achieve more 1334 control of the way in which the Internet architecture develops.In 1335 particular, there is a possibility that designs could evolve to 1336 significantly benefit of customers for a specific vendor, and that 1337 communities with very different network, applications or platforms 1338 could then suffer at the expense of benefits to their vendors own 1339 customer base. In such a scenario, there could be no incentive to 1340 support other applications/products or to work in other networks 1341 leading to reduced access for new approaches. 1343 7. Acknowledgements 1345 The authors would like to thank all who have talked to him face-to- 1346 face or via email. ... 1348 This work has received funding from the European Union's Horizon 2020 1349 research and innovation programme under grant agreement No 688421.The 1350 opinions expressed and arguments employed reflect only the authors' 1351 view. The European Commission is not responsible for any use that 1352 may be made of that information. 1354 8. Security Considerations 1356 This document is about design and deployment considerations for 1357 transport protocols. Issues relating to security are discussed in 1358 the various sections of the document. 1360 Authentication, confidentiality protection, and integrity protection 1361 are identified as Transport Features by [RFC8095]. As currently 1362 deployed in the Internet, these features are generally provided by a 1363 protocol or layer on top of the transport protocol [I-D.ietf-taps- 1364 transport-security]. 1366 Confidentiality and strong integrity checks have properties that can 1367 also be incorporated into the deisgn of a transport protocol. 1368 Integrity checks can protect an endpoint from undetected modification 1369 of protocol fields by network devices, whereas encryption and 1370 obfuscation can further prevent these headers being utilised by 1371 network devices. Hiding headers can therefore provide the 1372 opportunity for greater freedom to update the protocols and can ease 1373 experimentation with new techniques and their final deployment in 1374 endpoints. A protocol specification needs to weigh the benefits of 1375 ossifying common headers, versus the potential demerits of exposing 1376 specific information that could be observed along the network path to 1377 provide tools to manage new variants of protocols. 1379 A protocol design that uses header encryption can provide 1380 confidentiality of some or all of the protocol header information. 1381 This prevents an on-path device from knowledge of the header field. 1382 It therefore prevents mechanisms being built that directly rely on 1383 the information or seeks to imply semantics of an exposed header 1384 field. Hiding headers can limit the ability to measure and 1385 characterise traffic. 1387 Exposed transport headers are sometimes utilised as a part of the 1388 information to detect anomalies in network traffic. This can be used 1389 as the first line of defence yo identify potential threats from DOS 1390 or malware and redirect suspect traffic to dedicated nodes 1391 responsible for DOS analysis, malware detection, or to perform packet 1392 scrubbing "Scrubbing" (the normalization of packets so that there are 1393 no ambiguities in interpretation by the ultimate destination of the 1394 packet). These techniques are currently used by some operators to 1395 also defend from distributed DOS attacks. 1397 Exposed transport headers are sometimes also utilised as a part of 1398 the information used by the receiver of a transport protocol to 1399 protect the transport layer from data injection by an attacker. In 1400 evaluating this use of exposed header information, it is important to 1401 consider whether it introduces a significant DOS threat. For 1402 example, an attacker could construct a DOS attack by sending packets 1403 with a sequence number that falls within the currently accepted range 1404 of sequence numbers at the receiving endpoint, this would then 1405 introduce additional work at the receiving endpoint, even though the 1406 data in the attacking packet may not finally be delivered by the 1407 transport layer. This is sometimes known as a "shadowing attack". 1408 An attack can, for example, disrupt receiver processing, trigger loss 1409 and retransmission, or make a receiving endpoint perform unproductive 1410 decryption of packets that cannot be successfully decrypted (forcing 1411 a receiver to commit decryption resources, or to update and then 1412 restore protocol state). 1414 One mitigation to off-path attack is to deny knowledge of what header 1415 information is accepted by a receiver or obfusticate the accepted 1416 header information, e.g., setting a non-predictable initial value for 1417 a sequence number during a protocol handshake, as in [RFC3550] and 1418 [RFC6056], or a port value that can not be predicted (see section 5.1 1419 of [RFC8085]). A receiver could also require additional information 1420 to be used as a part of check before accepting packets at the 1421 transport layer (e.g., utilising a part of the sequence number space 1422 that is encrypted; or by verifying an encrypted token not visible to 1423 an attacker). This would also mitigate on-path attacks. An 1424 additional processing cost can be incurred when decryption needs to 1425 be attempted before a receiver is able to discard injected packets. 1427 Open standards motivate a desire for this evaluation to include 1428 independent observation and evaluation of performance data, which in 1429 turn suggests control over where and when measurement samples are 1430 collected. This requires consideration of the appropriate balance 1431 between encrypting all and no transport information. Open data, and 1432 accessibility to tools that can help understand trends in application 1433 deployment, network traffic and usage patterns can all contribute to 1434 understanding security challenges. 1436 9. IANA Considerations 1438 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1440 This memo includes no request to IANA. 1442 10. References 1444 10.1. Normative References 1446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1447 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1448 RFC2119, March 1997, . 1451 10.2. Informative References 1453 [I-D.dolson-plus-middlebox-benefits] 1454 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1455 "Beneficial Functions of Middleboxes", Internet-Draft 1456 draft-dolson-plus-middlebox-benefits-03, March 2017. 1458 [I-D.ietf-aqm-codel] 1459 Nichols, K., Jacobson, V., McGregor, A. and J. Iyengar, 1460 "Controlled Delay Active Queue Management", Internet-Draft 1461 draft-ietf-aqm-codel-10, October 2017. 1463 [I-D.ietf-aqm-fq-codel] 1464 Hoeiland-Joergensen, T., McKenney, P., 1465 dave.taht@gmail.com, d., Gettys, J. and E. Dumazet, "The 1466 FlowQueue-CoDel Packet Scheduler and Active Queue 1467 Management Algorithm", Internet-Draft draft-ietf-aqm-fq- 1468 codel-06, March 2016. 1470 [I-D.ietf-aqm-pie] 1471 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1472 Lightweight Control Scheme To Address the Bufferbloat 1473 Problem", Internet-Draft draft-ietf-aqm-pie-10, September 1474 2016. 1476 [I-D.ietf-ippm-6man-pdm-option] 1477 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1478 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1479 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1480 option-13, June 2017. 1482 [I-D.ietf-ippm-ioam-data] 1483 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1484 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1485 P., Chang, R., daniel.bernier@bell.ca, d. and J. Lemon, 1486 "Data Fields for In-situ OAM", Internet-Draft draft-ietf- 1487 ippm-ioam-data-02, March 2018. 1489 [I-D.ietf-quic-transport] 1490 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1491 and Secure Transport", Internet-Draft draft-ietf-quic- 1492 transport-03, May 2017. 1494 [I-D.ietf-taps-transport-security] 1495 Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of 1496 Transport Security Protocols", Internet-Draft draft-ietf- 1497 taps-transport-security-01, May 2018. 1499 [I-D.ietf-tcpinc-tcpcrypt] 1500 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1501 Q. and E. Smith, "Cryptographic protection of TCP Streams 1502 (tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11, 1503 November 2017. 1505 [I-D.ietf-tsvwg-l4s-arch] 1506 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1507 Low Loss, Scalable Throughput (L4S) Internet Service: 1508 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1509 arch-01, October 2017. 1511 [I-D.mm-wg-effect-encrypt] 1512 Moriarty, K. and A. Morton, "Effects of Pervasive 1513 Encryption on Operators", Internet-Draft draft-mm-wg- 1514 effect-encrypt-24, March 2018. 1516 [I-D.thomson-quic-grease] 1517 Thomson, M., "More Apparent Randomization for QUIC", 1518 Internet-Draft draft-thomson-quic-grease-00, December 1519 2017. 1521 [I-D.trammell-plus-abstract-mech] 1522 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1523 Layer under Endpoint Control", Internet-Draft draft- 1524 trammell-plus-abstract-mech-00, September 2016. 1526 [I-D.trammell-plus-statefulness] 1527 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1528 "Transport-Independent Path Layer State Management", 1529 Internet-Draft draft-trammell-plus-statefulness-02, 1530 December 2016. 1532 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1533 Techniques and Their Merits", November 2014. 1535 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1536 based Protocol Design", June 2017. 1538 [RFC1273] Schwartz, M.F., "Measurement Study of Changes in Service- 1539 Level Reachability in the Global TCP/IP Internet: Goals, 1540 Experimental Design, Implementation, and Policy 1541 Considerations", RFC 1273, DOI 10.17487/RFC1273, November 1542 1991, . 1544 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1545 "Definition of the Differentiated Services Field (DS 1546 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1547 10.17487/RFC2474, December 1998, . 1550 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1551 2914, DOI 10.17487/RFC2914, September 2000, . 1554 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1555 Shelby, "Performance Enhancing Proxies Intended to 1556 Mitigate Link-Related Degradations", RFC 3135, DOI 1557 10.17487/RFC3135, June 2001, . 1560 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1561 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1562 DOI 10.17487/RFC3168, September 2001, . 1565 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1566 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1567 . 1569 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1570 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1571 10.17487/RFC3393, November 2002, . 1574 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1575 Sooriyabandara, "TCP Performance Implications of Network 1576 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1577 December 2002, . 1579 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1580 Jacobson, "RTP: A Transport Protocol for Real-Time 1581 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1582 July 2003, . 1584 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1585 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1586 December 2005, . 1588 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1589 10.17487/RFC4302, December 2005, . 1592 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1593 4303, DOI 10.17487/RFC4303, December 2005, . 1596 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1597 "Extended RTP Profile for Real-time Transport Control 1598 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1599 10.17487/RFC4585, July 2006, . 1602 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1603 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1604 10.17487/RFC4737, November 2006, . 1607 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1608 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1609 . 1611 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1612 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1613 DOI 10.17487/RFC5236, June 2008, . 1616 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1617 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1618 RFC5246, August 2008, . 1621 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1622 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1623 March 2009, . 1625 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1626 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1627 . 1629 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1630 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1631 June 2010, . 1633 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1634 Protocol Port Randomization", BCP 156, RFC 6056, DOI 1635 10.17487/RFC6056, January 2011, . 1638 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. 1639 Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 1640 10.17487/RFC6269, June 2011, . 1643 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1644 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1645 January 2012, . 1647 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1648 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1649 RFC6437, November 2011, . 1652 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1653 and K. Carlberg, "Explicit Congestion Notification (ECN) 1654 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1655 2012, . 1657 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1658 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1659 2014, . 1661 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1662 for Secure Use of Transport Layer Security (TLS) and 1663 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1664 7525, DOI 10.17487/RFC7525, May 2015, . 1667 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1668 Recommendations Regarding Active Queue Management", BCP 1669 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1672 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1673 Trammell, B., Huitema, C. and D. Borkmann, 1674 "Confidentiality in the Face of Pervasive Surveillance: A 1675 Threat Model and Problem Statement", RFC 7624, DOI 1676 10.17487/RFC7624, August 2015, . 1679 [RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations 1680 on the Dropping of Packets with IPv6 Extension Headers in 1681 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 1682 2016, . 1684 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1685 Ros, "Characterization Guidelines for Active Queue 1686 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1687 2016, . 1689 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1690 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1693 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1694 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1695 March 2017, . 1697 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1698 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1699 2017, . 1701 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1702 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1703 10.17487/RFC8087, March 2017, . 1706 [RFC8095] Fairhurst, G., Ed., Trammell, B.Ed., and M. Kuehlewind, 1707 Ed., "Services Provided by IETF Transport Protocols and 1708 Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ 1709 RFC8095, March 2017, . 1712 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1713 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 1714 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 1715 October 2017, . 1717 [Tor] The Tor Project, ., "https://www.torproject.org", June 1718 2017. 1720 Appendix A. Revision information 1722 -00 This is an individual draft for the IETF community. 1724 -01 This draft was a result of walking away from the text for a few 1725 days and then reorganising the content. 1727 -02 This draft fixes textual errors. 1729 -03 This draft follows feedback from people reading this draft. 1731 -04 This adds an additional contributor and includes significant 1732 reworking to ready this for review by the wider IETF community Colin 1733 Perkins joined the author list. 1735 Comments from the community are welcome on the text and 1736 recommendations. 1738 -05 Corrections received and helpful inputs from Mohamed Boucadair. 1740 -06 Updated following comments from Stephen Farrell, and feedback via 1741 email. Added a draft conclusion section to sketch some strawman 1742 scenarios that could emerge. 1744 -07 Updated following comments from Al Morton, Chris Seal, and other 1745 feedback via email. 1747 -08 Updated to address comments sent to the TSVWG mailing list by 1748 Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 11/05/ 1749 2018, and Spencer Dawkins. 1751 -09 Updated security considerations. 1753 Authors' Addresses 1755 Godred Fairhurst 1756 University of Aberdeen 1757 Department of Engineering 1758 Fraser Noble Building 1759 Aberdeen, AB24 3UE 1760 Scotland 1762 Email: gorry@erg.abdn.ac.uk 1763 URI: http://www.erg.abdn.ac.uk/ 1765 Colin Perkins 1766 University of Glasgow 1767 School of Computing Science 1768 Glasgow, G12 8QQ 1769 Scotland 1771 Email: csp@csperkins.org 1772 URI: https://csperkins.org//