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