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