idnits 2.17.1 draft-ietf-tsvwg-transport-encrypt-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 645: '... IPv6 "source nodes SHOULD assign each...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2019) is 1708 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-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-08 -- Obsolete informational reference (is this intentional?): RFC 4995 (Obsoleted by RFC 5795) -- 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C. Perkins 5 Expires: February 24, 2020 University of Glasgow 6 August 23, 2019 8 The Impact of Transport Header Confidentiality on Network Operation and 9 Evolution of the Internet 10 draft-ietf-tsvwg-transport-encrypt-08 12 Abstract 14 This document describes some implications of applying end-to-end 15 encryption at the transport layer. It first identifies in-network 16 uses of transport layer header information. Then, it reviews some 17 implications of developing end-to-end transport protocols that use 18 encryption to provide confidentiality of the transport protocol 19 headers, or that use authentication to protect the integrity of 20 transport header information. Since measurement and analysis of the 21 impact of network characteristics on transport protocols has been 22 important to the design of current transports, it also considers the 23 impact of transport encryption on transport and application 24 evolution. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 24, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 2.1. Use of Transport Header Information in the Network . . . 4 63 2.2. Encryption of Transport Header Information . . . . . . . 5 64 2.3. Encryption tradeoffs . . . . . . . . . . . . . . . . . . 6 65 3. Current uses of Transport Headers within the Network . . . . 8 66 3.1. Observing Transport Information in the Network . . . . . 9 67 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15 68 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 19 69 3.4. Header Compression . . . . . . . . . . . . . . . . . . . 20 70 4. Encryption and Authentication of Transport Headers . . . . . 21 71 5. Addition of Transport Information to Network-Layer Protocol 72 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 73 6. Implications of Protecting the Transport Headers . . . . . . 25 74 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 26 75 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 28 76 6.3. Accountability and Internet Transport Protocols . . . . . 28 77 6.4. Impact on Operational Cost . . . . . . . . . . . . . . . 28 78 6.5. Impact on Research, Development and Deployment . . . . . 29 79 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 83 11. Informative References . . . . . . . . . . . . . . . . . . . 36 84 Appendix A. Revision information . . . . . . . . . . . . . . . . 43 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 87 1. Introduction 89 There is increased interest in, and deployment of, protocols that 90 employ end-to-end encryption at the transport layer, including the 91 transport layer headers. An example of such a transport is the QUIC 92 transport protocol [I-D.ietf-quic-transport], currently being 93 standardised in the IETF. Encryption of transport layer headers and 94 payload data has many benefits in terms of protecting user privacy. 95 These benefits have been widely discussed [RFC7258], [RFC7624], and 96 this document strongly supports the increased use of encryption in 97 transport protocols. Encryption and authentication can also be used 98 to prevent unwanted modification of transport header information by 99 middleboxes. There are also, however, some costs, in that the 100 widespread use of transport encryption requires changes to network 101 operations, and complicates network measurement for research, 102 operational, and standardisation purposes. The direction in which 103 the use of transport header confidentiality evolves could have 104 significant implications on the way the Internet architecture 105 develops, and therefore needs to be considered as a part of protocol 106 design. 108 The remainder of this document discusses some consequences of 109 applying end-to-end encryption at the transport layer. It reviews 110 the implications of developing end-to-end transport protocols that 111 use encryption to provide confidentiality of the transport protocol 112 headers, and considers the effect of such changes on transport 113 protocol design and network operations. It also considers some 114 anticipated implications on transport and application evolution. 116 Transports are also increasingly encrypting and authenticating the 117 payload (i.e., the application data carried within the transport 118 connection) end-to-end. Such protection is encouraged, and the 119 implications of protecting the payload are not further discussed in 120 this document. 122 2. Context and Rationale 124 The transport layer provides end-to-end interactions between 125 endpoints (processes) using an Internet path. Transport protocols 126 layer directly over the network-layer service, and are sent in the 127 payload of network-layer packets. They support end-to-end 128 communication between applications, supported by higher-layer 129 protocols, running on the end systems (transport endpoints). This 130 simple architectural view hides one of the core functions of the 131 transport: to discover and adapt to the Internet path that is 132 currently used. The design of Internet transport protocols is as 133 much about trying to avoid the unwanted side effects of congestion on 134 a flow and other capacity-sharing flows, avoiding congestion 135 collapse, adapting to changes in the path characteristics, etc., as 136 it is about end-to-end feature negotiation, flow control, and 137 optimising for performance of a specific application. 139 To achieve stable Internet operations, the IETF transport community 140 has to date relied heavily on the results of measurements and the 141 insights of the network operations community to understand the trade- 142 offs, and to inform selection of appropriate mechanisms to ensure a 143 safe, reliable, and robust Internet (e.g., [RFC1273]). In turn, the 144 network operator and access provider community has relied on being 145 able to understand the pattern and requirements of traffic passing 146 over the Internet, both in aggregate and at the flow level. The 147 widespread use of transport header encryption may change this. 149 2.1. Use of Transport Header Information in the Network 151 In-network measurement of transport flow characteristics can be used 152 to enhance performance, and control cost and service reliability. 153 Some operators have deployed functionality in middleboxes to both 154 support network operations and enhance performance. This reliance on 155 the presence and semantics of specific header information leads to 156 ossification, where an endpoint could be required to supply a 157 specific header to receive the network service that it desires. In 158 some cases, this could be benign or advantageous to the protocol 159 (e.g., recognising the start of a connection, or explicitly exposing 160 protocol information can be expected to provide more consistent 161 decisions by on-path devices than the use of diverse methods to infer 162 semantics from other flow properties). In other cases, the 163 ossification could frustrate the evolution of the protocol (e.g., a 164 mechanism implemented in a network device, such as a firewall, that 165 required a header field to have only a specific known set of values 166 would prevent the device from forwarding packets using a different 167 version of a protocol that introduces a feature that changes the 168 value of this field). 170 As an example of ossification, consider the experience of developing 171 Transport Layer Security (TLS) 1.3 [RFC8446]. This required a design 172 that recognised that deployed middleboxes relied on the presence of 173 certain header filed exposed in TLS 1.2, and failed if those headers 174 were changed. Other examples of the impact of ossification can be 175 found in the development of Multipath TCP (MPTCP) and the TCP Fast 176 Open option. The design of MPTCP had to be revised to account for 177 middleboxes, so called "TCP Normalizers", that monitor the evolution 178 of the window advertised in the TCP headers and that reset 179 connections if the window does not grow as expected. Similarly, TCP 180 Fast Open has had issues with middleboxes that remove unknown TCP 181 options, that drop segments with unknown TCP options, that drop 182 segments that contain data and have the SYN bit set, that drop 183 packets with SYN/ACK that acknowledge data, or that disrupt 184 connections that send data before the three-way handshake completes. 186 In all these cases, the issue was caused by middleboxes that had a 187 hard-coded understanding of transport behaviour, and that interacted 188 poorly with transports that tried to change that behaviour. Other 189 examples have included middleboxes that rewrite TCP sequence and 190 acknowledgement numbers but are unaware of the (newer) SACK option 191 and don't correctly rewrite selective acknowledgements to match the 192 changes made to the fixed TCP header. 194 2.2. Encryption of Transport Header Information 196 Encryption is expected to form a basis for many future transport 197 protocol designs. These can be in the form of encrypted transport 198 protocols (i.e., transport protocols that use encryption to provide 199 confidentiality of some or all of the transport-layer header 200 information), and/or the encryption of transport payloads (i.e., 201 confidentiality of the payload data). There are many motivations for 202 deploying such transports, and increasing public concerns about 203 interference with Internet traffic [RFC7624] have led to a rapidly 204 expanding deployment of encrypted transport protocols such as QUIC 205 [I-D.ietf-quic-transport]. Using encryption to provide 206 confidentiality of the transport layer therefore brings some well- 207 known privacy and security benefits. 209 Authentication and the introduction of cryptographic integrity checks 210 for header fields can prevent undetected manipulation of transport 211 headers by network devices. This does not prevent inspection of the 212 information by devices on path, and it is possible that such devices 213 could develop mechanisms that rely on the presence of such a field or 214 a known value in the field. In this context, specification of a non- 215 encrypted transport header field explicitly allows protocol designers 216 to make the certain header information observable by the network. 217 This supports use of this information by on-path devices, but at the 218 same time can be expected to lead to ossification of the transport 219 header, because network forwarding could evolve to depend on the 220 presence and/or value of these fields. To avoid unwanted inspection, 221 a protocol could intentionally vary the format or value of exposed 222 header fields [I-D.ietf-tls-grease]. 224 A protocol design that uses header encryption with secure key 225 distribution can provide confidentiality for some, or all, of the 226 protocol header information. This prevents an on-path device from 227 observing the transport headers, and stops mechanisms being built 228 that directly rely on transport header information, or that seek to 229 infer semantics of exposed header fields. Transport header 230 encryption can therefore help reduce ossification of the transport 231 layer. 233 While encryption can hide transport header information, it does not 234 prevent ossification of the network service. People seeking to 235 understand network traffic could come to rely on pattern inferences 236 and other heuristics as the basis for network decision and to derive 237 measurement data. This can create new dependencies on the transport 238 protocol, or the patterns of traffic it can generate. This use of 239 machine-learning methods usually demands large data sets, presenting 240 it own requirements for collecting and distributing the data. 242 2.3. Encryption tradeoffs 244 The are architectural challenges and considerations in the way 245 transport protocols are designed, and the ability to characterise and 246 compare different transport solutions [Measure]. The decision about 247 which transport headers fields are made observable offers trade-offs 248 around authentication and confidentiality versus observability, 249 network operations and management, and ossification. The impact 250 differs depending on the activity, for example: 252 Network Operations and Research: Observable transport headers enable 253 explicit measure and analysis protocol performance, network 254 anomalies, and failure pathologies at any point along the Internet 255 path. In many cases, it is important to relate observations to 256 specific equipment/configurations or network segments. 258 Concealing transport header information makes performance/ 259 behaviour unavailable to passive observers along the path, 260 Operators will be unable to use this information directly and may 261 turn to more ambitious ways to collect, estimate, or infer that 262 data. Operational practices aimed at guessing transport 263 parameters are out of scope for this document, and are only 264 mentioned here to recognize that encryption does not prevent 265 operators from attempting to apply practices that were used with 266 unencrypted transport headers. 268 Confidentiality of the transport payload could be provided while 269 leaving some, or all, transport headers unencrypted (or providing 270 this information in a network-layer extension), possibly with 271 authentication. This provides many of the privacy and security 272 benefits while supporting operations and research, but at the cost 273 of ossifying the exposed headers. 275 Protection from Denial of Service: Observable transport headers 276 currently provide useful input to classify and detect anomalous 277 events, such as changes in application behaviour or distributed 278 denial of service attacks. For this application to be effective, 279 it needs to be possible for an operator to uniquely disambiguate 280 unwanted traffic. Concealing transport header information would 281 prevent disambiguation based on transport information. This could 282 result in less-efficient identification of unwanted traffic, the 283 use of heuristics to identify anomalous flows, or the introduction 284 of rate limits for uncharacterised traffic. 286 Network Troubleshooting and Diagnostics: Observable transport 287 headers can be utilised by operators for network troubleshooting 288 and diagnostics. Flows experiencing packet loss or jitter are 289 hard to distinguish from unaffected flows when only observing 290 network layer headers. Effective troubleshooting often requires 291 visibility into the transport layer behaviour. 293 Concealing transport header information reduces the incentive for 294 operators to troubleshoot, since they cannot interpret the data. 295 It can limit understanding of transport dynamics, such as the 296 impact of packet loss or latency on the flows, or make it harder 297 to localise the network segment intoducing the packet loss or 298 latency. Additional mechanisms will be needed to help reconstruct 299 or replace transport-level metrics for troubleshooting and 300 diagnostics. These can add complexity and operational costs 301 (e.g., in deploying additional functions in equipment or adding 302 traffic overhead). 304 Network Traffic Analysis: Observable transport headers can support 305 network traffic analysis to determine which transport protocols 306 and features are being used across a network segment and to 307 measure trends in the pattern of usage. For some applications 308 end-to-end measurements/traces are sufficient, but in other 309 applications it is important to relate observations to specific 310 equipment/configurations or particular network segments. 312 Concealing transport header information can make analysis harder 313 or impossible. This could impact the ability for an operator to 314 anticipate the need for network upgrades and roll-out. It can 315 also impact the on-going traffic engineering activities performed 316 by operators, such as determining which parts of the path 317 contribute delay, jitter or loss. While this impact could, in 318 many cases, be small, there are scenarios where operators directly 319 support particular services and need visibility to explore issues 320 relating to Quality of Service (QoS), the ability to perform fast 321 re-routing of critical traffic, or to mitigate the characteristics 322 of specific radio links, and so on. 324 Open and Verifiable Network Data: Observable transport headers can 325 provide open and verifiable measurement data. The ability of 326 other stake holders to review transport header traces helps 327 develop insight into performance and traffic contribution of 328 specific variants of a protocol. Independently observed data is 329 important to help ensure the health of the research and 330 development communities. 332 Concealing transport header information can reduce the range of 333 actors that can observe useful data. This would limit the 334 information sources available to the Internet community to 335 understand the operation of new transport protocols, reducing 336 information to inform design decisions and standardisation of the 337 new protocols and related operational practices. 339 Compliance: Observable transport headers coupled with published 340 transport specifications allow operators and regulators to check 341 compliance. Independently verifiable performance metrics can also 342 be utilised to demonstrate regulatory compliance in some 343 jurisdictions, and as a basis for informing design decisions. 344 This can bring assurance to those operating networks, often 345 avoiding the need to deploy complex techniques that routinely 346 monitor and manage Internet traffic flows (e.g., avoiding the 347 capital and operational costs of deploying flow rate-limiting and 348 network circuit-breaker methods [RFC8084]). 350 When transport header information is concealed, it is not possible 351 to observe transport header information. Methods are still needed 352 to confirm that the traffic produced conforms to the expectations 353 of the operator or developer. 355 Different parties will view the relative importance of these issues 356 differently. For some, the benefits of encrypting some, or all, of 357 the transport headers may outweigh the impact of doing so; others 358 might make a different trade-off. The purpose of highlighting the 359 trade-offs is to make such analysis possible. 361 3. Current uses of Transport Headers within the Network 363 Despite transport headers having end-to-end meaning, some of these 364 transport headers have come to be used in various ways within the 365 Internet. In response to pervasive monitoring [RFC7624] revelations 366 and the IETF consensus that "Pervasive Monitoring is an Attack" 367 [RFC7258], efforts are underway to increase encryption of Internet 368 traffic. Applying confidentiality to transport header fields affects 369 how protocol information is used [RFC8404], requiring consideration 370 of the trade-offs discussed in Section 2.3. To understand the 371 implications, it is necessary to understand how transport layer 372 headers are currently observed and/or modified by middleboxes within 373 the network. 375 We review some current uses in the following section. This does not 376 consider the intentional modification of transport headers by 377 middleboxes (such as in Network Address Translation, NAT, or 378 Firewalls). Common issues concerning IP address sharing are 379 described in [RFC6269]. 381 3.1. Observing Transport Information in the Network 383 If in-network observation of transport protocol headers is needed, 384 this requires knowledge of the format of the transport header: 386 o Flows need to be identified at the level required to perform the 387 observation; 389 o The protocol and version of the header need to be visible, e.g., 390 by defining the wire image [RFC8546]. As protocols evolve over 391 time and there could be a need to introduce new transport headers. 392 This could require interpretation of protocol version information 393 or connection setup information; 395 o The location and syntax of any observed transport headers need to 396 be known. IETF transport protocols can specify this information. 398 The following subsections describe various ways that observable 399 transport information has been utilised. 401 3.1.1. Flow Identification Using Transport Layer Headers 403 Flow identification is a common function. For example, performed by 404 measurement activities, QoS classification, firewalls, Denial of 405 Service, DOS, prevention. This becomes more complex and less easily 406 achieved when multiplexing is used at or above the transport layer. 408 Observable transport header information, together with information in 409 the network header, has been used to identify flows and their 410 connection state, together with the protocol options being used. 411 Transport protocols, such as TCP and the Stream Control Transport 412 Protocol (SCTP), specify a standard base header that includes 413 sequence number information and other data. They also have the 414 possibility to negotiate additional headers at connection setup, 415 identified by an option number in the transport header. 417 In some uses, a low-numbered (well-known) transport port number can 418 be used to identify the protocol, although port information alone is 419 not sufficient to guarantee identification of a protocol since 420 applications can use arbitrary ports, multiple sessions can be 421 multiplexed on a single port, and ports can be re-used by subsequent 422 sessions. 424 UDP-based protocols often do not use well-known port numbers. Some 425 flows can instead be identified by observing signalling protocol data 426 (e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of 427 magic numbers placed in the first byte(s) of the datagram payload 428 [RFC7983]. 430 Concealing transport header information can remove information used 431 to classify flows by passive observers along the path, so operators 432 will be unable to use this information directly. Careful use of the 433 network layer features can help address provide similar information 434 in the case where the network is unable to inspect transport protocol 435 headers. Operators could also turn to more ambitious ways to 436 collect, estimate, or infer that data, including heuristics based on 437 the analysis of traffic patterns. For example, an operator that no 438 longer has access to Session Description Protocol (SDP) session 439 descriptions to classify a flow carry as audio traffic might instead 440 use heuristics to infer that short UDP packets with regular spacing 441 carry audio traffic. Operational practices aimed at inferring 442 transport parameters are out of scope for this document, and are only 443 mentioned here to recognize that encryption does not prevent 444 operators from attempting to apply practices that were used with 445 unencrypted transport headers. 447 Confidentiality of the transport payload could be provided while 448 leaving some, or all, transport headers unencrypted, or providing 449 this information in a network-layer extension, possibly with 450 authentication. This provides many of the privacy and security 451 benefits while supporting operations and research, but at the cost of 452 ossifying the exposed headers. 454 3.1.2. Metrics derived from Transport Layer Headers 456 Observable transport headers enable explicit measurement and analysis 457 of protocol performance, network anomalies, and failure pathologies 458 at any point along the Internet path. Some operators manage their 459 portion of the Internet by characterizing the performance of link/ 460 network segments. Passive monitoring can observe traffic that does 461 not encrypt the transport header information, and make inferences 462 from transport headers to derive performance metrics. 464 A variety of open source and commercial tools have been deployed that 465 utilise transport header information in this way. The following 466 metrics can be derived: 468 Traffic Rate and Volume: Header information (e.g., sequence number 469 and packet size) allows derivation of volume measures per- 470 application, to characterise the traffic that uses a network 471 segment or the pattern of network usage. This can be measured per 472 endpoint or for an aggregate of endpoints (e.g., to assess 473 subscriber usage). It can also be used to trigger measurement- 474 based traffic shaping, and to implement QoS support within the 475 network and lower layers. Volume measures can be valuable for 476 capacity planning and providing detail of trends, rather than the 477 volume per subscriber. 479 Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., 480 from transport sequence numbers) and has been used as a metric for 481 performance assessment and to characterise transport behaviour. 482 Understanding the location and root cause of loss can help an 483 operator determine whether this requires corrective action. 484 Network operators have used the variation in patterns of loss as a 485 key performance metric, utilising this to detect changes in the 486 offered service. 488 There are various causes of loss, including corruption of link 489 frames (e.g., interference on a radio link), buffer overflow 490 (e.g., due to congestion), policing (traffic management), buffer 491 management (e.g., Active Queue Management, AQM [RFC7567]), and 492 inadequate provision of traffic pre-emption. Understanding flow 493 loss rates requires either observing sequence numbers in transport 494 headers, or maintaining per-flow packet counters (but note that 495 flow identification often requires transport header information). 496 Per-hop loss can be monitored at the interface level by devices in 497 the network. It is often valuable to understand the conditions 498 under which packet loss occurs. This usually requires relating 499 per-flow loss to the traffic flowing on the network node/segment 500 at the time of loss. 502 Observation of transport feedback information (e.g., RTP Control 503 Protocol (RTCP) reception reports [RFC3550], TCP SACK blocks) can 504 increase understanding of the impact of loss and help identify 505 cases where loss could have been wrongly identified, or where the 506 transport did not require the lost packet. It is sometimes more 507 helpful to understand the pattern of loss, than the loss rate, 508 because losses can often occur as bursts, rather than randomly- 509 timed events. 511 Throughput and Goodput: Throughput is the amount of data sent by a 512 flow per time interval. Goodput [RFC7928] is a measure of useful 513 data exchanged (the ratio of useful data to total volume of 514 traffic sent by a flow). The throughput achieved by a flow can be 515 determined even when transport header information is concealed, 516 providing the individual flow can be identified. Goodput requires 517 ability to differentiate loss and retransmission of packets, for 518 example by observing packet sequence numbers in the TCP or the 519 Real-time Transport Protocol (RTP) headers [RFC3550]. 521 Latency: Latency is a key performance metric that impacts 522 application and user-perceived response times. It often 523 indirectly impacts throughput and flow completion time. Latency 524 determines the reaction time of the transport protocol itself, 525 impacting flow setup, congestion control, loss recovery, and other 526 transport mechanisms. The observed latency can have many 527 components [Latency]. Of these, unnecessary/unwanted queuing in 528 network buffers has often been observed as a significant factor 529 [bufferbloat]. Once the cause of unwanted latency has been 530 identified, this can often be eliminated. 532 To measure latency across a part of a path, an observation point 533 [RFC7799] can measure the experienced round trip time (RTT) using 534 packet sequence numbers, and acknowledgements, or by observing 535 header timestamp information. Such information allows an 536 observation point in the network to determine not only the path 537 RTT, but also to measure the upstream and downstream contribution 538 to the RTT. This could be used to locate a source of latency, 539 e.g., by observing cases where the median RTT is much greater than 540 the minimum RTT for a part of a path. 542 The service offered by network operators can benefit from latency 543 information to understand the impact of configuration changes and 544 to tune deployed services. Latency metrics are key to evaluating 545 and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit 546 Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements 547 could identify excessively large buffers, indicating where to 548 deploy or configure AQM. An AQM method is often deployed in 549 combination with other techniques, such as scheduling [RFC7567] 550 [RFC8290] and although parameter-less methods are desired 551 [RFC7567], current methods [RFC8290] [RFC8289] [RFC8033] often 552 cannot scale across all possible deployment scenarios. 554 Variation in delay: Some network applications are sensitive to 555 (small) changes in packet timing (jitter). Short and long-term 556 delay variation can impact on the latency of a flow and hence the 557 perceived quality of applications using the network. For example, 558 jitter metrics are often cited when characterising paths 559 supporting real-time traffic. To assess the performance of such 560 applications, it can be necessary to measure the variation in 561 delay observed along a portion of the path [RFC3393] [RFC5481]. 562 The requirements for observable transport headers resemble those 563 for the measurement of latency. 565 Flow Reordering: Significant packet reordering within a flow can 566 impact time-critical applications and can be interpreted as loss 567 by reliable transports. Many transport protocol techniques are 568 impacted by reordering (e.g., triggering TCP retransmission or re- 569 buffering of real-time applications). Packet reordering can occur 570 for many reasons, from equipment design to misconfiguration of 571 forwarding rules. Since this impacts transport performance, 572 network tools are needed to detect and measure unwanted/excessive 573 reordering. 575 There have been initiatives in the IETF transport area to reduce 576 the impact of reordering within a transport flow, possibly leading 577 to a reduction in the requirements for preserving ordering. These 578 have potential to simplify network equipment design as well as the 579 potential to improve robustness of the transport service. 580 Measurements of reordering can help understand the present level 581 of reordering within deployed infrastructure, and inform decisions 582 about how to progress such mechanisms. Key performance indicators 583 are retransmission rate, packet drop rate, sector utilisation 584 level, a measure of reordering, peak rate, the ECN congestion 585 experienced (CE) marking rate, etc. 587 Metrics have been defined that evaluate whether a network has 588 maintained packet order on a packet-by-packet basis [RFC4737] and 589 [RFC5236]. 591 Techniques for measuring reordering typically observe packet 592 sequence numbers. Some protocols provide in-built monitoring and 593 reporting functions. Transport fields in the RTP header [RFC3550] 594 [RFC4585] can be observed to derive traffic volume measurements 595 and provide information on the progress and quality of a session 596 using RTP. As with other measurement, metadata is often needed to 597 understand the context under which the data was collected, 598 including the time, observation point [RFC7799], and way in which 599 metrics were accumulated. The RTCP protocol directly reports some 600 of this information in a form that can be directly visible in the 601 network. A user of summary measurement data needs to trust the 602 source of this data and the method used to generate the summary 603 information. 605 This information can support network operations, inform capacity 606 planning, and assist in determining the need for equipment and/or 607 configuration changes by network operators. It can also inform 608 Internet engineering activities by informing the development of new 609 protocols, methodologies, and procedures. 611 3.1.3. Transport use of Network Layer Header Fields 613 Information from the transport protocol can be used by a multi-field 614 classifier as a part of policy framework. Policies are commonly used 615 for management of the QoS or Quality of Experience (QoE) in resource- 616 constrained networks, and by firewalls to implement access rules (see 617 also section 2.2.2 of [RFC8404]). Network-layer classification 618 methods that rely on a multi-field classifier (e.g., inferring QoS 619 from the 5-tuple or choice of application protocol) are incompatible 620 with transport protocols that encrypt the transport information. 621 Traffic that cannot be classified will typically receive a default 622 treatment. 624 Transport information can also be explicitly set in network-layer 625 header fields that are not encrypted. This can provide information 626 to enable a different forwarding treatment by the network, even when 627 a transport employs encryption to protect other header information. 629 The user of a transport that multiplexes multiple sub-flows might 630 want to hide the presence and characteristics of these sub-flows. On 631 the other hand, an encrypted transport could set the network-layer 632 information to indicate the presence of sub-flows, and to reflect the 633 network needs of individual sub-flows. There are several ways this 634 could be done: 636 IP Address: Applications expose the addresses used by endpoints, and 637 this is used in the forwarding decisions in network devices. 638 Address and other protocol information can be used by a Multi- 639 Field (MF) classifier to determine how traffic is treated 640 [RFC2475], and hence the quality of experience for a flow. 642 Using the IPv6 Network-Layer Flow Label: A number of Standards Track 643 and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], 644 [RFC6438]) encourage endpoints to set the IPv6 Flow label field of 645 the network-layer header. IPv6 "source nodes SHOULD assign each 646 unrelated transport connection and application data stream to a 647 new flow" [RFC6437]. A multiplexing transport could choose to use 648 multiple Flow labels to allow the network to independently forward 649 subflows. RFC6437 provides further guidance on choosing a flow 650 label value, stating these "should be chosen such that their bits 651 exhibit a high degree of variability", and chosen so that "third 652 parties should be unlikely to be able to guess the next value that 653 a source of flow labels will choose". To promote privacy, the 654 Flow Label assignment needs to avoid introducing linkability that 655 a network device may observe. Once set, a flow label can provide 656 information that can help inform network-layer queuing and 657 forwarding [RFC6438], for example with Equal Cost Multi-Path 658 routing and Link Aggregation [RFC6294]. Considerations when using 659 IPsec are further described in [RFC6438]. 661 Using the Network-Layer Differentiated Services Code Point: 662 Applications can expose their delivery expectations to the network 663 by setting the Differentiated Services Code Point (DSCP) field of 664 IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications 665 identify different forwarding treatments for individual sub-flows 666 (audio vs. video) based on the value of the DSCP field 667 [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information 668 to inform network-layer queuing and forwarding, rather than an 669 operator inferring traffic requirements from transport and 670 application headers via a multi-field classifier. 672 Since the DSCP value can impact the quality of experience for a 673 flow, observations of service performance need to consider this 674 field when a network path has support for differentiated service 675 treatment. 677 Using Explicit Congestion Marking: ECN [RFC3168] is a transport 678 mechanism that utilises the ECN field in the network-layer header. 679 Use of ECN explicitly informs the network-layer that a transport 680 is ECN-capable, and requests ECN treatment of the flow. An ECN- 681 capable transport can offer benefits when used over a path with 682 equipment that implements an AQM method with CE marking of IP 683 packets [RFC8087], since it can react to congestion without also 684 having to recover from lost packets. 686 ECN exposes the presence of congestion. The reception of CE- 687 marked packets can be used to estimate the level of incipient 688 congestion on the upstream portion of the path from the point of 689 observation (Section 2.5 of [RFC8087]). Interpreting the marking 690 behaviour (i.e., assessing congestion and diagnosing faults) 691 requires context from the transport layer, such as path RTT. 693 AQM and ECN offer a range of algorithms and configuration options. 694 Tools therefore need to be available to network operators and 695 researchers to understand the implication of configuration choices 696 and transport behaviour as the use of ECN increases and new 697 methods emerge [RFC7567]. 699 When transport headers are concealed, operators will be unable to use 700 this information directly. Careful use of the network layer features 701 can help address provide similar information in the case where the 702 network is unable to inspect transport protocol headers. 704 3.2. Transport Measurement 706 The common language between network operators and application/content 707 providers/users is packet transfer performance at a layer that all 708 can view and analyse. For most packets, this has been the transport 709 layer, until the emergence of QUIC, with the obvious exception of 710 Virtual Private Networks (VPNs) and IPsec. 712 When encryption conceals more layers in each packet, people seeking 713 understanding of the network operation rely more on pattern inference 714 and other heuristics. It remains to be seen whether more complex 715 inferences can be mastered to produce the same monitoring accuracy 716 (see section 2.1.1 of [RFC8404]). 718 When measurement datasets are made available by servers or client 719 endpoints, additional metadata, such as the state of the network, is 720 often required to interpret this data to answer questions about 721 network performance or understand a pathology. Collecting and 722 coordinating such metadata is more difficult when the observation 723 point is at a different location to the bottleneck/device under 724 evaluation [RFC7799]. 726 Packet sampling techniques are used to scale the processing involved 727 in observing packets on high rate links. This exports only the 728 packet header information of (randomly) selected packets. The 729 utility of these measurements depends on the type of bearer and 730 number of mechanisms used by network devices. Simple routers are 731 relatively easy to manage, a device with more complexity demands 732 understanding of the choice of many system parameters. This level of 733 complexity exists when several network methods are combined. 735 This section discusses topics concerning observation of transport 736 flows, with a focus on transport measurement. 738 3.2.1. Point of Observation 740 On-path measurements are particularly useful for locating the source 741 of problems, or to assess the performance of a network segment or a 742 particular device configuration. Often issues can only be understood 743 in the context of the other flows that share a particular path, 744 common network device, interface port, etc. A simple example is 745 monitoring of a network device that uses a scheduler or active queue 746 management technique [RFC7567], where it could be desirable to 747 understand whether the algorithms are correctly controlling latency, 748 or if overload protection is working. This understanding implies 749 knowledge of how traffic is assigned to any sub-queues used for flow 750 scheduling, but can also require information about how the traffic 751 dynamics impact active queue management, starvation prevention 752 mechanisms, and circuit-breakers. 754 Sometimes multiple on-path observation points are needed. By 755 correlating observations of headers at multiple points along the path 756 (e.g., at the ingress and egress of a network segment), an observer 757 can determine the contribution of a portion of the path to an 758 observed metric, to locate a source of delay, jitter, loss, 759 reordering, congestion marking, etc. 761 3.2.2. Use by Operators to Plan and Provision Networks 763 Traffic measurements (e.g., traffic volume, loss, latency) are used 764 by operators to help plan deployment of new equipment and 765 configuration in their networks. Data is also valuable to equipment 766 vendors who want to understand traffic trends and patterns of usage 767 as inputs to decisions about planning products and provisioning for 768 new deployments. This measurement information can also be correlated 769 with billing information when this is also collected by an operator. 771 A network operator supporting traffic that uses transport header 772 encryption might not have access to per-flow measurement data. 773 Trends in aggregate traffic can be observed and can be related to the 774 endpoint addresses being used, but it may be impossible to correlate 775 patterns in measurements with changes in transport protocols (e.g., 776 the impact of changes in introducing a new transport protocol 777 mechanism). This increases the dependency on other indirect sources 778 of information to inform planning and provisioning. 780 3.2.3. Service Performance Measurement 782 Traffic measurements (e.g., traffic volume, loss, latency) can be 783 used by various actors to help analyse the performance offered to the 784 users of a network segment, and to inform operational practice. 786 While active measurements (see section 3.4 of [RFC7799]) may be used 787 within a network, passive measurements (see section 3.6 of [RFC7799]) 788 can have advantages in terms of eliminating unproductive test 789 traffic, reducing the influence of test traffic on the overall 790 traffic mix, and the ability to choose the point of observation (see 791 Section 3.2.1). However, passive measurements can rely on observing 792 transport headers which is not possible if those headers are 793 encrypted. 795 3.2.4. Measuring Transport to Support Network Operations 797 Information provided by tools observing transport headers can help 798 determine whether mechanisms are needed in the network to prevent 799 flows from acquiring excessive network capacity. Operators can 800 implement operational practices to manage traffic flows (e.g., to 801 prevent flows from acquiring excessive network capacity under severe 802 congestion) by deploying rate-limiters, traffic shaping or network 803 transport circuit breakers [RFC8084]. 805 Congestion Control Compliance of Traffic: Congestion control is a 806 key transport function [RFC2914]. Many network operators 807 implicitly accept that TCP traffic complies with a behaviour that 808 is acceptable for use in the shared Internet. TCP algorithms have 809 been continuously improved over decades and they have reached a 810 level of efficiency and correctness that custom application-layer 811 mechanisms will struggle to easily duplicate [RFC8085]. 813 A standards-compliant TCP stack provides congestion control that 814 may therefore be judged safe for use across the Internet. 815 Applications developed on top of well-designed transports can be 816 expected to appropriately control their network usage, reacting 817 when the network experiences congestion, by back-off and reduce 818 the load placed on the network. This is the normal expected 819 behaviour for IETF-specified transport (e.g., TCP and SCTP). 821 However, when anomalies are detected, tools can interpret the 822 transport protocol header information to help understand the 823 impact of specific transport protocols (or protocol mechanisms) on 824 the other traffic that shares a network. An observation in the 825 network can gain an understanding of the dynamics of a flow and 826 its congestion control behaviour. Analysing observed flows can 827 help to build confidence that an application flow backs-off its 828 share of the network load in the face of persistent congestion, 829 and hence to understand whether the behaviour is appropriate for 830 sharing limited network capacity. For example, it is common to 831 visualise plots of TCP sequence numbers versus time for a flow to 832 understand how a flow shares available capacity, deduce its 833 dynamics in response to congestion, etc. 835 The ability to identify sources that contribute to persistent 836 congestion is important to safe operation of network 837 infrastructure, and mechanisms can inform configuration of network 838 devices to complement the endpoint congestion avoidance mechanisms 839 [RFC7567] [RFC8084] to avoid a portion of the network being driven 840 into congestion collapse [RFC2914]. 842 Congestion Control Compliance for UDP traffic: UDP provides a 843 minimal message-passing datagram transport that has no inherent 844 congestion control mechanisms. Because congestion control is 845 critical to the stable operation of the Internet, applications and 846 other protocols that choose to use UDP as a transport are required 847 to employ mechanisms to prevent congestion collapse, avoid 848 unacceptable contributions to jitter/latency, and to establish an 849 acceptable share of capacity with concurrent traffic [RFC8085]. 851 A network operator needs tools to understand if datagram flows 852 (e.g., using UDP) comply with congestion control expectations and 853 therefore whether there is a need to deploy methods such as rate- 854 limiters, transport circuit breakers, or other methods to enforce 855 acceptable usage for the offered service. 857 UDP flows that expose a well-known header by specifying the format 858 of header fields can allow information to be observed to gain 859 understanding of the dynamics of a flow and its congestion control 860 behaviour. For example, tools exist to monitor various aspects of 861 RTP and RTCP header information for real-time flows (see 862 Section 3.1.2). The Secure RTP extensions [RFC3711] were 863 explicitly designed to expose some header information to enable 864 such observation, while protecting the payload data. 866 3.3. Use for Network Diagnostics and Troubleshooting 868 Transport header information can be useful for a variety of 869 operational tasks [RFC8404]: to diagnose network problems, assess 870 network provider performance, evaluate equipment/protocol 871 performance, capacity planning, management of security threats 872 (including denial of service), and responding to user performance 873 questions. Section 3.1.2 and Section 5 of [RFC8404] provide further 874 examples. These tasks seldom involve the need to determine the 875 contents of the transport payload, or other application details. 877 A network operator supporting traffic that uses transport header 878 encryption can see only encrypted transport headers. This prevents 879 deployment of performance measurement tools that rely on transport 880 protocol information. Choosing to encrypt all the information 881 reduces the ability of an operator to observe transport performance 882 and could limit the ability of network operators to trace problems, 883 make appropriate QoS decisions, or response to other queries about 884 the network service. For some this will be blessing, for others it 885 may be a curse. For example, operational performance data about 886 encrypted flows needs to be determined by traffic pattern analysis, 887 rather than relying on traditional tools. This can impact the 888 ability of the operator to respond to faults, it could require 889 reliance on endpoint diagnostic tools or user involvement in 890 diagnosing and troubleshooting unusual use cases or non-trivial 891 problems. A key need here is for tools to provide useful information 892 during network anomalies (e.g., significant reordering, high or 893 intermittent loss). 895 Measurements can be used to monitor the health of a portion of the 896 Internet, to provide early warning of the need to take action. They 897 can assist in setting buffer sizes, debugging and diagnosing the root 898 causes of faults that concern a particular user's traffic. They can 899 also be used to support post-mortem investigation after an anomaly to 900 determine the root cause of a problem. 902 In some cases, measurements could involve active injection of test 903 traffic to perform a measurement. However, most operators do not 904 have access to user equipment, therefore the point of test is 905 normally different from the transport endpoint. Injection of test 906 traffic can incur an additional cost in running such tests (e.g., the 907 implications of capacity tests in a mobile network are obvious). 908 Some active measurements [RFC7799] (e.g., response under load or 909 particular workloads) perturb other traffic, and could require 910 dedicated access to the network segment. An alternative approach is 911 to use in-network techniques that observe transport packet headers 912 added while traffic traverses an operational network to make the 913 measurements. These measurements do not require the cooperation of 914 an endpoint. 916 In other cases, measurement involves dissecting network traffic 917 flows. The observed transport layer information can help identify 918 whether the link/network tuning is effective and alert to potential 919 problems that can be hard to derive from link or device measurements 920 alone. The design trade-offs for radio networks are often very 921 different from those of wired networks. A radio-based network (e.g., 922 cellular mobile, enterprise WiFi, satellite access/back-haul, point- 923 to-point radio) has the complexity of a subsystem that performs radio 924 resource management, with direct impact on the available capacity, 925 and potentially loss/reordering of packets. The impact of the 926 pattern of loss and congestion, differs for different traffic types, 927 correlation with propagation and interference can all have 928 significant impact on the cost and performance of a provided service. 929 The need for this type of information is expected to increase as 930 operators bring together heterogeneous types of network equipment and 931 seek to deploy opportunistic methods to access radio spectrum. 933 A flow that conceals its transport header information could imply 934 "don't touch" to some operators. This could limit a trouble-shooting 935 response to "can't help, no trouble found". 937 3.4. Header Compression 939 Header compression saves link capacity by compressing network and 940 transport protocol headers on a per-hop basis. It was widely used 941 with low bandwidth dial-up access links, and still finds application 942 on wireless links that are subject to capacity constraints. Header 943 compression has been specified for use with TCP/IP and RTP/UDP/IP 944 flows [RFC2507], [RFC2508], [RFC4995]. 946 While it is possible to compress only the network layer headers, 947 significant savings can be made if both the network and transport 948 layer headers are compressed together as a single unit. The Secure 949 RTP extensions [RFC3711] were explicitly designed to leave the 950 transport protocol headers unencrypted, but authenticated, since 951 support for header compression was considered important. Encrypting 952 the transport protocol headers does not break such header 953 compression, but does cause it to fall back to compressing only the 954 network layer headers, with a significant reduction in efficiency. 955 This can impact the efficiency of a link/path. 957 4. Encryption and Authentication of Transport Headers 959 End-to-end encryption can be applied at various protocol layers. It 960 can be applied above the transport to encrypt the transport payload. 961 Encryption methods can hide information from an eavesdropper in the 962 network. Encryption can also help protect the privacy of a user, by 963 hiding data relating to user/device identity or location. Neither an 964 integrity check nor encryption methods prevent traffic analysis, and 965 usage needs to reflect that profiling of users, identification of 966 location and fingerprinting of behaviour can take place even on 967 encrypted traffic flows. Any header information that has a clear 968 definition in the protocol's message format(s), or is implied by that 969 definition, and is not cryptographically confidentiality-protected 970 can be unambiguously interpreted by on-path observers [RFC8546]. 972 There are several motivations for encryption: 974 o One motive to use encryption is a response to perceptions that the 975 network has become ossified by over-reliance on middleboxes that 976 prevent new protocols and mechanisms from being deployed. This 977 has lead to a perception that there is too much "manipulation" of 978 protocol headers within the network, and that designing to deploy 979 in such networks is preventing transport evolution. In the light 980 of this, a method that authenticates transport headers could help 981 improve the pace of transport development, by eliminating the need 982 to always consider deployed middleboxes 983 [I-D.trammell-plus-abstract-mech], or potentially to only 984 explicitly enable use by middleboxes for particular paths with 985 particular middleboxes that are deliberately deployed to realise a 986 useful function for the network and/or users[RFC3135]. 988 o Another motivation stems from increased concerns about privacy and 989 surveillance. Some Internet users have valued the ability to 990 protect identity, user location, and defend against traffic 991 analysis, and have used methods such as IPsec Encapsulated 992 Security Payload (ESP), VPNs and other encrypted tunnel 993 technologies. Revelations about the use of pervasive surveillance 994 [RFC7624] have, to some extent, eroded trust in the service 995 offered by network operators, and following the Snowden revelation 996 in the USA in 2013 has led to an increased desire for people to 997 employ encryption to avoid unwanted "eavesdropping" on their 998 communications. Concerns have also been voiced about the addition 999 of information to packets by third parties to provide analytics, 1000 customization, advertising, cross-site tracking of users, to bill 1001 the customer, or to selectively allow or block content. Whatever 1002 the reasons, there are now activities in the IETF to design new 1003 protocols that could include some form of transport header 1004 encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement 1005 the already widespread payload encryption. 1007 Authentication methods that provide integrity checks of protocols 1008 fields have also been specified at the network layer, and this also 1009 protects transport header fields. The network layer itself carries 1010 protocol header fields that are increasingly used to help forwarding 1011 decisions reflect the need of transport protocols, such as the IPv6 1012 Flow Label [RFC6437], DSCP, and ECN fields. 1014 The use of transport layer authentication and encryption exposes a 1015 tussle between middlebox vendors, operators, applications developers 1016 and users: 1018 o On the one hand, future Internet protocols that enable large-scale 1019 encryption assist in the restoration of the end-to-end nature of 1020 the Internet by returning complex processing to the endpoints, 1021 since middleboxes cannot modify what they cannot see. 1023 o On the other hand, encryption of transport layer header 1024 information has implications for people who are responsible for 1025 operating networks and researchers and analysts seeking to 1026 understand the dynamics of protocols and traffic patterns. 1028 Whatever the motives, a decision to use pervasive transport header 1029 encryption will have implications on the way in which design and 1030 evaluation is performed. This can, in turn, impact the direction of 1031 evolution of the transport protocol stack. While the IETF can 1032 specify protocols, the success in actual deployment is often 1033 determined by many factors [RFC5218] that are not always clear at the 1034 time when protocols are being defined. 1036 The following briefly reviews some security design options for 1037 transport protocols. A Survey of Transport Security Protocols 1038 [I-D.ietf-taps-transport-security] provides more details concerning 1039 commonly used encryption methods at the transport layer. 1041 Authenticating the Transport Protocol Header: Transport layer header 1042 information can be authenticated. An integrity check that 1043 protects the immutable transport header fields, but can still 1044 expose the transport protocol header information in the clear, 1045 allows in-network devices to observe these fields. An integrity 1046 check is not able to prevent in-network modification, but can 1047 prevent a receiving from accepting changes and avoid impact on the 1048 transport protocol operation. 1050 An example transport authentication mechanism is TCP- 1051 Authentication (TCP-AO) [RFC5925]. This TCP option authenticates 1052 the IP pseudo header, TCP header, and TCP data. TCP-AO protects 1053 the transport layer, preventing attacks from disabling the TCP 1054 connection itself and provides replay protection. TCP-AO may 1055 interact with middleboxes, depending on their behaviour [RFC3234]. 1057 The IPsec Authentication Header (AH) [RFC4302] was designed to 1058 work at the network layer and authenticate the IP payload. This 1059 approach authenticates all transport headers, and verifies their 1060 integrity at the receiver, preventing in-network modification. 1061 Secure RTP [RFC3711] is another example of a transport protocol 1062 that allows header authentication. 1064 Greasing: Protocols often provide extensibility features, reserving 1065 fields or values for use by future versions of a specification. 1066 The specification of receivers has traditionally ignored 1067 unspecified values, however in-network devices have emerged that 1068 ossify to require a certain value in a field, or re-use a field 1069 for another purpose. When the specification is later updated, it 1070 is impossible to deploy the new use of the field, and forwarding 1071 of the protocol could even become conditional on a specific header 1072 field value. 1074 A protocol can intentionally vary the value, format, and/or 1075 presence of observable transport header fields. This behaviour, 1076 known as GREASE (Generate Random Extensions And Sustain 1077 Extensibility) is designed to avoid a network device ossifying the 1078 use of a specific observable field. Greasing seeks to ease 1079 deployment of new methods. It can also prevent in-network devices 1080 utilising the information in a transport header, or can make an 1081 observation robust to a set of changing values, rather than a 1082 specific set of values. 1084 Encrypting the Transport Payload: The transport layer payload can be 1085 encrypted to protect the content of transport segments. This 1086 leaves transport protocol header information in the clear. The 1087 integrity of immutable transport header fields could be protected 1088 by combining this with an integrity check. 1090 Examples of encrypting the payload include Transport Layer 1091 Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS) 1092 over UDP [RFC6347] [RFC7525], Secure RTP [RFC3711], and TCPcrypt 1093 [RFC8548] which permits opportunistic encryption of the TCP 1094 transport payload. 1096 Encrypting the Transport Headers and Payload: The network layer 1097 payload could be encrypted (including the entire transport header 1098 and the payload). This method provides confidentiality of the 1099 entire transport packet. It therefore does not expose any 1100 transport information to devices in the network, which also 1101 prevents modification along a network path. 1103 One example of encryption at the network layer is the use of IPsec 1104 Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. 1105 This encrypts and authenticates all transport headers, preventing 1106 visibility of the transport headers by in-network devices. Some 1107 VPN methods also encrypt these headers. 1109 Selectively Encrypting Transport Headers and Payload: A transport 1110 protocol design can encrypt selected header fields, while also 1111 choosing to authenticate the entire transport header. This allows 1112 specific transport header fields to be made observable by network 1113 devices. End-to end integrity checks can prevent an endpoint from 1114 undetected modification of the immutable transport headers. 1116 Mutable fields in the transport header provide opportunities for 1117 middleboxes to modify the transport behaviour (e.g., the extended 1118 headers described in [I-D.trammell-plus-abstract-mech]). This 1119 considers only immutable fields in the transport headers, that is, 1120 fields that can be authenticated End-to-End across a path. 1122 An example of a method that encrypts some, but not all, transport 1123 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 1125 Optional Encryption of Header Information: There are implications to 1126 the use of optional header encryption in the design of a transport 1127 protocol, where support of optional mechanisms can increase the 1128 complexity of the protocol and its implementation and in the 1129 management decisions that are required to use variable format 1130 fields. Instead, fields of a specific type ought to always be 1131 sent with the same level of confidentiality or integrity 1132 protection. 1134 As seen, different transports use encryption to protect their header 1135 information to varying degrees. There is, however, a trend towards 1136 increased protection with newer transport protocols. 1138 5. Addition of Transport Information to Network-Layer Protocol Headers 1140 An on-path device can make measurements by appending additional 1141 protocol headers carrying operations, administration and management 1142 (OAM) information to packets at the ingress to a maintenance domain 1143 (e.g., an Ethernet protocol header with timestamps and sequence 1144 number information using a method such as 802.11ag or in-situ OAM 1145 [I-D.ietf-ippm-ioam-data]) and removing the additional header at the 1146 egress of the maintenance domain. This approach enables some types 1147 of measurements, but does not cover the entire range of measurements 1148 described in this document. In some cases, it can be difficult to 1149 position measurement tools at the required segments/nodes and there 1150 can be challenges in correlating the downsream/upstream information 1151 when in-band OAM data is inserted by an on-path device. This has the 1152 advantage that a single header can support all transport protocols, 1153 but there could also be less desirable implications of separating the 1154 operation of the transport protocol from the measurement framework. 1156 Another example of a network-layer approach is the IPv6 Performance 1157 and Diagnostic Metrics (PDM) Destination Option [RFC8250]. This 1158 allows a sender to optionally include a destination option that 1159 caries header fields that can be used to observe timestamps and 1160 packet sequence numbers. This information could be authenticated by 1161 receiving transport endpoints when the information is added at the 1162 sender and visible at the receiving endpoint, although methods to do 1163 this have not currently been proposed. This method needs to be 1164 explicitly enabled at the sender. 1166 Current measurement results suggest that it can be undesirable to 1167 rely on methods requiring end to end support of network options or 1168 extension headers across the Internet. IPv4 network options are 1169 often not supported (or are carried on a slower processing path) and 1170 some IPv6 networks have been observed to drop packets that set an 1171 IPv6 header extension (e.g., results from 2016 in [RFC7872]). 1172 Another possibility is that protocols that separately expose header 1173 information do not necessarily have an incentive to expose the actual 1174 information that is utilised by the protocol itself and could 1175 therefore manipulate the exposed header information to gain an 1176 advantage from the network. The incentive to reflect actual 1177 transport information needs to be considered when proposing a method 1178 that selectively exposes header information. 1180 6. Implications of Protecting the Transport Headers 1182 The choice of which fields to expose and which to encrypt is a design 1183 choice for the transport protocol. Any selective encryption method 1184 requires trading two conflicting goals for a transport protocol 1185 designer to decide which header fields to encrypt. Security work 1186 typically employs a design technique that seeks to expose only what 1187 is needed. This approach provides incentives to not reveal any 1188 information that is not necessary for the end-to-end communication. 1189 However, there can be performance and operational benefits in 1190 exposing selected information to network tools. 1192 This section explores key implications of working with encrypted 1193 transport protocols. 1195 6.1. Independent Measurement 1197 Independent observation by multiple actors is important if the 1198 transport community is to maintain an accurate understanding of the 1199 network. Encrypting transport header encryption changes the ability 1200 to collect and independently analyse data. Internet transport 1201 protocols employ a set of mechanisms. Some of these need to work in 1202 cooperation with the network layer for loss detection and recovery, 1203 congestion detection and congestion control. Others need to work 1204 only end-to-end (e.g., parameter negotiation, flow-control). 1206 The majority of present Internet applications use two well-known 1207 transport protocols, TCP and UDP. Although TCP represents the 1208 majority of current traffic, many real-time applications use UDP, and 1209 much of this traffic utilises RTP format headers in the payload of 1210 the UDP datagram. Since these protocol headers have been fixed for 1211 decades, a range of tools and analysis methods have became common and 1212 well-understood. 1214 Protocols that expose the state information used by the transport 1215 protocol in their header information (e.g., timestamps used to 1216 calculate the RTT, packet numbers used to asses congestion and 1217 requests for retransmission) provide an incentive for the sending 1218 endpoint to provide correct information, since the protocol will not 1219 work otherwise. This increases confidence that the observer 1220 understands the transport interaction with the network. For example, 1221 when TCP is used over an unencrypted network path (i.e., one that 1222 does not use IPsec or other encryption below the transport), it 1223 implicitly exposes header information that can be used for 1224 measurement at any point along the path. This information is 1225 necessary for the protocol's correct operation, therefore there is no 1226 incentive for a TCP implementation to put incorrect information in 1227 this transport header. A network device can have confidence that the 1228 well-known (and ossified) transport information represents the actual 1229 state of the endpoints. 1231 When encryption is used to conceal some or all of the transport 1232 headers, the transport protocol choose what information to reveal to 1233 the network about its internal state, what information to leave 1234 encrypted, and what fields to grease to protect against future 1235 ossification. Such a transport could be designed, for example, to 1236 provide summary data regarding its performance, congestion control 1237 state, etc., or to make an explicit measurement signal available. 1238 For example, a QUIC endpoint could set the spin bit to reflect to 1239 explicitly reveal a session's RTT [I-D.ietf-quic-spin-exp]). 1241 When providing or using such information, it becomes important to 1242 consider the privacy of the user and their incentive for providing 1243 accurate and detailed information. Protocols that selectively reveal 1244 some transport state or measurement signals are choosing to establish 1245 a trust relationship with the network operators. There is no 1246 protocol mechanism that can guarantee that the information provided 1247 represents the actual transport state of the endpoints, since those 1248 endpoints can always send additional information in the encrypted 1249 part of the header, to update or replace whatever they reveal. This 1250 reduces the ability to independently measure and verify that a 1251 protocol is behaving as expected. Some operational uses need the 1252 information to contain sufficient detail to understand, and possibly 1253 reconstruct, the network traffic pattern for further testing; such 1254 operators must gain the trust of transport protocol implementers if 1255 they are to correctly reveal such information. 1257 OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a 1258 variety of encapsulation methods at different layers to support the 1259 goals of a specific operational domain. OAM-related metadata can 1260 support functions such as performance evaluation, path-tracing, path 1261 verification information, classification and a diversity of other 1262 uses. When encryption is used to conceal some or all of the 1263 transport headers, analysis will require coordination between actors 1264 at different layers to successfully characterise flows and correlate 1265 the performance or behaviour of a specific mechanism with the 1266 configuration and traffic using operational equipment (e.g., 1267 combining transport and network measurements to explore congestion 1268 control dynamics, the implications of designs for active queue 1269 management or circuit breakers). 1271 For some usage a standardised endpoint-based logging format (e.g., 1272 based on Quic-Trace [Quic-Trace]) could offer an alternative for some 1273 in-network measurement. Such information will have a diversity of 1274 uses, including developers wishing to debug/understand the transport/ 1275 application protocols with which they work, researchers seeking to 1276 spot trends and anomalies, and to characterise variants of protocols. 1277 Measurments based on logging will need to establish the validity and 1278 provenance of the logged information to establish how and when traces 1279 were captured. 1281 However, endpoint logs do not provide equivalent information to in- 1282 network measurements. In particular, endpoint logs contain only a 1283 part of the information needed to understand the operation of network 1284 devices and identify issues such as link performance or capacity 1285 sharing between multiple flows. Additional information is needed to 1286 determine which equipment/links are used and the configuration of 1287 equipment along the network paths being measured. 1289 6.2. Characterising "Unknown" Network Traffic 1291 The patterns and types of traffic that share Internet capacity change 1292 over time as networked applications, usage patterns and protocols 1293 continue to evolve. 1295 If "unknown" or "uncharacterised" traffic patterns form a small part 1296 of the traffic aggregate passing through a network device or segment 1297 of the network the path, the dynamics of the uncharacterised traffic 1298 may not have a significant collateral impact on the performance of 1299 other traffic that shares this network segment. Once the proportion 1300 of this traffic increases, the need to monitor the traffic and 1301 determine if appropriate safety measures need to be put in place. 1303 Tracking the impact of new mechanisms and protocols requires traffic 1304 volume to be measured and new transport behaviours to be identified. 1305 This is especially true of protocols operating over a UDP substrate. 1306 The level and style of encryption needs to be considered in 1307 determining how this activity is performed. On a shorter timescale, 1308 information may also need to be collected to manage denial of service 1309 attacks against the infrastructure. 1311 6.3. Accountability and Internet Transport Protocols 1313 Information provided by tools observing transport headers can be used 1314 to classify traffic, and to limit the network capacity used by 1315 certain flows, as discussed in Section 3.2.4). Equally, operators 1316 could use analysis of transport headers and transport flow state to 1317 demonstrate that they are not providing differential treatment to 1318 certain flows. Obfuscating or hiding this information using 1319 encryption may lead operators and maintainers of middleboxes 1320 (firewalls, etc.) to seek other methods to classify, and potentially 1321 other mechanisms to condition, network traffic. 1323 A lack of data that reduces the level of precision with which flows 1324 can be classified also reduces the design space for conditioning 1325 mechanisms (e.g., rate limiting, circuit breaker techniques 1326 [RFC8084], or blocking of uncharacterised traffic), and this needs to 1327 be considered when evaluating the impact of designs for transport 1328 encryption [RFC5218]. 1330 6.4. Impact on Operational Cost 1332 Many network operators currently utilise observed transport 1333 information as a part of their operational practice, and have 1334 developed tools and operational practices based around currently 1335 deployed transports and their applications. Encryption of the 1336 transport information prevents tools from directly observing this 1337 information. A variety of open source and commercial tools have been 1338 deployed that utilise this information for a variety of short and 1339 long term measurements. 1341 The network will not break just because transport headers are 1342 encrypted, although alternative diagnostic and troubleshooting tools 1343 would need to be developed and deployed. Introducing a new protocol 1344 or application can require these tool chains and practice to be 1345 updated, and may in turn impact operational mechanisms, and policies. 1346 Each change can introduce associated costs, including the cost of 1347 collecting data, and the tooling needed to handle multiple formats 1348 (possibly as these co-exist in the network, when measurements need to 1349 span time periods during which changes are deployed, or to compare 1350 with historical data). These costs are incurred by an operator to 1351 manage the service and debug network issues. 1353 At the time of writing, the additional operational cost of using 1354 encrypted transports is not yet well understood. Design trade-offs 1355 could mitigate these costs by explicitly choosing to expose selected 1356 information (e.g., header invariants and the spin-bit in QUIC 1357 [I-D.ietf-quic-transport]), the specification of common log formats, 1358 and development of alternative approaches. 1360 6.5. Impact on Research, Development and Deployment 1362 Evolution and the ability to understand (measure) the impact need to 1363 proceed hand-in-hand. Observable transport headers can provide open 1364 and verifiable measurement data. Observation of pathologies has a 1365 critical role in the design of transport protocol mechanisms and 1366 development of new mechanisms and protocols. This helps 1367 understanding the interactions between cooperating protocols and 1368 network mechanism, the implications of sharing capacity with other 1369 traffic and the impact of different patterns of usage. The ability 1370 of other stake holders to review transport header traces helps 1371 develop insight into performance and traffic contribution of specific 1372 variants of a protocol. 1374 In development of new transport protocol mechanisms, attention needs 1375 to be paid to the expected scale of deployment. Whatever the 1376 mechanism, experience has shown that it is often difficult to 1377 correctly implement combinations of mechanisms [RFC8085]. Mechanisms 1378 often evolve as a protocol matures, or in response to changes in 1379 network conditions, changes in network traffic, or changes to 1380 application usage. Analysis is especially valuable when based on the 1381 behaviour experienced across a range of topologies, vendor equipment, 1382 and traffic patterns. 1384 New transport protocol formats are expected to facilitate an 1385 increased pace of transport evolution, and with it the possibility to 1386 experiment with and deploy a wide range of protocol mechanisms. 1387 There has been recent interest in a wide range of new transport 1388 methods, e.g., Larger Initial Window, Proportional Rate Reduction 1389 (PRR), congestion control methods based on measuring bottleneck 1390 bandwidth and round-trip propagation time, the introduction of AQM 1391 techniques and new forms of ECN response (e.g., Data Centre TCP, 1392 DCTP, and methods proposed for L4S).The growth and diversity of 1393 applications and protocols using the Internet also continues to 1394 expand. For each new method or application it is desirable to build 1395 a body of data reflecting its behaviour under a wide range of 1396 deployment scenarios, traffic load, and interactions with other 1397 deployed/candidate methods. 1399 Concealing transport header information could reduce the range of 1400 actors that can observe useful data. This would limit the 1401 information sources available to the Internet community to understand 1402 the operation of new transport protocols, reducing information to 1403 inform design decisions and standardisation of the new protocols and 1404 related operational practices. The cooperating dependence of 1405 network, application, and host to provide communication performance 1406 on the Internet is uncertain when only endpoints (i.e., at user 1407 devices and within service platforms) can observe performance, and 1408 when performance cannot be independently verified by all parties. 1410 Independently observed data is also important to ensure the health of 1411 the research and development communities and can help promote 1412 acceptance of proposed specifications by the wider community (e.g., 1413 as a method to judge the safety for Internet deployment) and provides 1414 valuable input during standardisation. Open standards motivate a 1415 desire to include independent observation and evaluation of 1416 performance data, which in turn demands control over where and when 1417 measurement samples are collected. This requires consideration of 1418 the methods used to observe data and the appropriate balance between 1419 encrypting all and no transport information. 1421 7. Conclusions 1423 Confidentiality and strong integrity checks have properties that are 1424 being incorporated into new protocols and that have important 1425 benefits. The pace of development of transports using the WebRTC 1426 data channel, and the rapid deployment of the QUIC transport 1427 protocol, can both be attributed to using the combination of UDP as a 1428 substrate while providing confidentiality and authentication of the 1429 encapsulated transport headers and payload. 1431 To achieve stable Internet operations, the IETF transport community 1432 has, to date, relied heavily on measurement and insights of the 1433 network operations community to understand the trade-offs, and to 1434 inform selection of appropriate mechanisms, to ensure a safe, 1435 reliable, and robust Internet (e.g., [RFC1273],[RFC2914]). 1437 The traffic that can be observed by on-path network devices is a 1438 function of transport protocol design/options, network use, 1439 applications, and user characteristics. In general, when only a 1440 small proportion of the traffic has a specific (different) 1441 characteristic, such traffic seldom leads to operational concern, 1442 although the ability to measure and monitor it is less. The desire 1443 to understand the traffic and protocol interactions typically grows 1444 as the proportion of traffic increases in volume. The challenges 1445 increase when multiple instances of an evolving protocol contribute 1446 to the traffic that share network capacity. 1448 An increased pace of evolution therefore needs to be accompanied by 1449 methods that can be successfully deployed and used across operational 1450 networks. This leads to a need for network operators at various 1451 levels (ISPs, enterprises, firewall maintainer, etc.) to identify 1452 appropriate operational support functions and procedures. 1454 Protocols that change their transport header format (wire format) or 1455 their behaviour (e.g., algorithms that are needed to classify and 1456 characterise the protocol), will require new tooling to be developed 1457 to catch-up with the change. If the currently deployed tools and 1458 methods are no longer relevant, then it may no longer be possible to 1459 correctly measure performance. This can increase the response-time 1460 after faults, and can impact the ability to manage the network 1461 resulting in traffic causing traffic to be treated inappropriately 1462 (e.g., rate limiting because of being incorrectly classified/ 1463 monitored). 1465 There are benefits in exposing consistent information to the network 1466 that avoids traffic being inappropriately classified and then 1467 receiving a default treatment by the network. The flow label and 1468 DSCP fields provide examples of how transport information can be made 1469 available for network-layer decisions. Extension headers could also 1470 be used to carry transport information that can inform network-layer 1471 decisions. Other information may also be useful to various 1472 stakeholders, however this document does not make recommendations 1473 about what information should be exposed, to whom it should be 1474 observable, or how this will be achieved. 1476 There are trade-offs and implications of increased use of encryption 1477 when designing a protocol. Transport protocol designers have often 1478 ignored the implications of whether the information in transport 1479 header fields can or will be used by in-network devices, and the 1480 implications this places on protocol evolution. This motivates a 1481 design that provides confidentiality of header information. This 1482 lack of visibility of transport header information can be expected to 1483 impact the ways that protocols are deployed, standardised, and their 1484 operational support. The impact of hiding transport headers 1485 therefore needs to be considered in the specification and development 1486 of protocols and standards. This has a potential impact on the way 1487 in which the IRTF and IETF develop new protocols, specifications, and 1488 guidelines: 1490 o Coexistence of Transport and Network Device Protocols/ 1491 Configuration: Transmission Control Protocol (TCP) is currently 1492 the predominant transport protocol used over Internet paths. Its 1493 many variants have broadly consistent approaches to avoiding 1494 congestion collapse, and to ensuring the stability of the 1495 Internet. Increased use of transport layer encryption can 1496 overcome ossification, allowing deployment of new transports and 1497 different types of congestion control. This flexibility can be 1498 beneficial, but it could come at the cost of fragmenting the 1499 ecosystem. There is little doubt that developers will try to 1500 produce high quality transports for their intended target uses, 1501 but it is not yet clear there are sufficient incentives to ensure 1502 good practice that benefits the wide diversity of requirements for 1503 the Internet community as a whole. 1505 o Supporting Common Specifications: Common open specifications can 1506 stimulate engagement by developers, users, and researchers. 1507 Increased diversity, and the ability to innovate without public 1508 scrutiny, risks point solutions that optimise for specific needs, 1509 but accidentally disrupt operations of/in different parts of the 1510 network. The social contract that maintains the stability of the 1511 Internet relies on accepting common interworking specifications. 1513 o Benchmarking and Understanding Feature Interactions: An 1514 appropriate vantage point for observation, coupled with timing 1515 information about traffic flows, provides a valuable tool for 1516 benchmarking network devices, endpoint stacks, functions, and/or 1517 configurations. This can also help understand complex feature 1518 interactions. An inability to observe transport protocol 1519 information can limit the ability to diagnose and explore 1520 interactions between features at different protocol layers, a 1521 side-effect of not allowing a choice of vantage point from which 1522 this information is observed. New approaches need to be 1523 developed. 1525 o Operational Practice: The network operations community relies on 1526 being able to understand the pattern and requirements of traffic 1527 passing over the Internet, both in aggregate and at the flow 1528 level. These operational practices have developed based on the 1529 information available from unencrypted transport headers. The 1530 IETF supports this activity by developing operations and 1531 management specifications, interface specifications, and 1532 associated Best Current Practice (BCP) specifications. Concealing 1533 transport header information impacts current practice and demand 1534 new specifications. 1536 o Research and Development: Concealing transport information can 1537 impede independent research into new mechanisms, measurement of 1538 behaviour, and development initiatives. Experience shows that 1539 transport protocols are complicated to design and complex to 1540 deploy, and that individual mechanisms need to be evaluated while 1541 considering other mechanisms, across a broad range of network 1542 topologies and with attention to the impact on traffic sharing the 1543 capacity. If this results in reduced availability of open data, 1544 it could eliminate the independent self-checks to the 1545 standardisation process that have previously been in place from 1546 research and academic contributors (e.g., the role of the IRTF 1547 Internet Congestion Control Research Groups (ICCRG) and research 1548 publications in reviewing new transport mechanisms and assessing 1549 the impact of their experimental deployment). 1551 The choice of whether future transport protocols encrypt their 1552 protocol headers needs to be taken based not solely on security and 1553 privacy considerations, but also taking into account the impact on 1554 operations, standards and research. As [RFC7258] notes: "Making 1555 networks unmanageable to mitigate (pervasive monitoring) is not an 1556 acceptable outcome, but ignoring (pervasive monitoring) would go 1557 against the consensus documented here." 1559 As part of a protocol's design, the community therefore needs to 1560 weigh the benefits of ossifying common headers versus the potential 1561 demerits of exposing specific information that could be observed 1562 along the network path, to ensure network operators, researchers and 1563 other stakeholders have appropriate tools to manage their networks 1564 and enable stable operation of the Internet as new protocols are 1565 deployed. An appropriate balance will emerge over time as real 1566 instances of this tension are analysed [RFC7258]. This balance 1567 between information exposed and information concealed ought to be 1568 carefully considered when specifying new transport protocols. 1570 8. Security Considerations 1572 This document is about design and deployment considerations for 1573 transport protocols. Issues relating to security are discussed 1574 throughout this document. 1576 Authentication, confidentiality protection, and integrity protection 1577 are identified as Transport Features by [RFC8095]. As currently 1578 deployed in the Internet, these features are generally provided by a 1579 protocol or layer on top of the transport protocol 1580 [I-D.ietf-taps-transport-security]. 1582 Confidentiality and strong integrity checks have properties that can 1583 also be incorporated into the design of a transport protocol. 1584 Integrity checks can protect an endpoint from undetected modification 1585 of protocol fields by network devices, whereas encryption and 1586 obfuscation or greasing can further prevent these headers being 1587 utilised by network devices. Hiding headers can therefore provide 1588 the opportunity for greater freedom to update the protocols and can 1589 ease experimentation with new techniques and their final deployment 1590 in endpoints. A protocol specification needs to weigh the benefits 1591 of ossifying common headers, versus the potential demerits of 1592 exposing specific information that could be observed along the 1593 network path to provide tools to manage new variants of protocols. 1595 A protocol design that uses header encryption can provide 1596 confidentiality of some or all of the protocol header information. 1597 This prevents an on-path device from knowledge of the header field. 1598 It therefore prevents mechanisms being built that directly rely on 1599 the information or seeks to infer semantics of an exposed header 1600 field. Hiding headers can limit the ability to measure and 1601 characterise traffic. 1603 Exposed transport headers are sometimes utilised as a part of the 1604 information to detect anomalies in network traffic. This can be used 1605 as the first line of defence to identify potential threats from DOS 1606 or malware and redirect suspect traffic to dedicated nodes 1607 responsible for DOS analysis, malware detection, or to perform packet 1608 "scrubbing" (the normalization of packets so that there are no 1609 ambiguities in interpretation by the ultimate destination of the 1610 packet). These techniques are currently used by some operators to 1611 also defend from distributed DOS attacks. 1613 Exposed transport header fields are sometimes also utilised as a part 1614 of the information used by the receiver of a transport protocol to 1615 protect the transport layer from data injection by an attacker. In 1616 evaluating this use of exposed header information, it is important to 1617 consider whether it introduces a significant DOS threat. For 1618 example, an attacker could construct a DOS attack by sending packets 1619 with a sequence number that falls within the currently accepted range 1620 of sequence numbers at the receiving endpoint, this would then 1621 introduce additional work at the receiving endpoint, even though the 1622 data in the attacking packet may not finally be delivered by the 1623 transport layer. This is sometimes known as a "shadowing attack". 1625 An attack can, for example, disrupt receiver processing, trigger loss 1626 and retransmission, or make a receiving endpoint perform unproductive 1627 decryption of packets that cannot be successfully decrypted (forcing 1628 a receiver to commit decryption resources, or to update and then 1629 restore protocol state). 1631 One mitigation to off-path attack is to deny knowledge of what header 1632 information is accepted by a receiver or obfuscate the accepted 1633 header information, e.g., setting a non-predictable initial value for 1634 a sequence number during a protocol handshake, as in [RFC3550] and 1635 [RFC6056], or a port value that can not be predicted (see section 5.1 1636 of [RFC8085]). A receiver could also require additional information 1637 to be used as a part of a validation check before accepting packets 1638 at the transport layer (e.g., utilising a part of the sequence number 1639 space that is encrypted; or by verifying an encrypted token not 1640 visible to an attacker). This would also mitigate against on-path 1641 attacks. An additional processing cost can be incurred when 1642 decryption needs to be attempted before a receiver is able to discard 1643 injected packets. 1645 Open standards motivate a desire for this evaluation to include 1646 independent observation and evaluation of performance data, which in 1647 turn suggests control over where and when measurement samples are 1648 collected. This requires consideration of the appropriate balance 1649 between encrypting all and no transport information. Open data, and 1650 accessibility to tools that can help understand trends in application 1651 deployment, network traffic and usage patterns can all contribute to 1652 understanding security challenges. 1654 The Security and Privacy Considerations in the Framework for Large- 1655 Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain 1656 considerations for Active and Passive measurement techniques and 1657 supporting material on measurement context. 1659 9. IANA Considerations 1661 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1663 This memo includes no request to IANA. 1665 10. Acknowledgements 1667 The authors would like to thank Mohamed Boucadair, Spencer Dawkins, 1668 Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen 1669 Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris 1670 Wood, Thomas Fossati, and other members of the TSVWG for their 1671 comments and feedback. 1673 This work has received funding from the European Union's Horizon 2020 1674 research and innovation programme under grant agreement No 688421, 1675 and the EU Stand ICT Call 4. The opinions expressed and arguments 1676 employed reflect only the authors' view. The European Commission is 1677 not responsible for any use that may be made of that information. 1679 This work has received funding from the UK Engineering and Physical 1680 Sciences Research Council under grant EP/R04144X/1. 1682 11. Informative References 1684 [bufferbloat] 1685 Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in 1686 the Internet. Communications of the ACM, 55(1):57-65", 1687 January 2012. 1689 [I-D.ietf-ippm-ioam-data] 1690 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1691 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1692 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 1693 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 1694 data-06 (work in progress), July 2019. 1696 [I-D.ietf-quic-spin-exp] 1697 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 1698 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 1699 October 2018. 1701 [I-D.ietf-quic-transport] 1702 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1703 and Secure Transport", draft-ietf-quic-transport-22 (work 1704 in progress), July 2019. 1706 [I-D.ietf-rtcweb-overview] 1707 Alvestrand, H., "Overview: Real Time Protocols for 1708 Browser-based Applications", draft-ietf-rtcweb-overview-19 1709 (work in progress), November 2017. 1711 [I-D.ietf-taps-transport-security] 1712 Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. 1713 Rose, "A Survey of Transport Security Protocols", draft- 1714 ietf-taps-transport-security-08 (work in progress), August 1715 2019. 1717 [I-D.ietf-tls-grease] 1718 Benjamin, D., "Applying GREASE to TLS Extensibility", 1719 draft-ietf-tls-grease-04 (work in progress), August 2019. 1721 [I-D.ietf-tsvwg-rtcweb-qos] 1722 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1723 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 1724 qos-18 (work in progress), August 2016. 1726 [I-D.trammell-plus-abstract-mech] 1727 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1728 Layer under Endpoint Control", draft-trammell-plus- 1729 abstract-mech-00 (work in progress), September 2016. 1731 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1732 Techniques and Their Merits, IEEE Comm. Surveys & 1733 Tutorials. 26;18(3) p2149-2196", November 2014. 1735 [Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- 1736 based Protocol Design, Eur. Conf. on Networks and 1737 Communications, Oulu, Finland.", June 2017. 1739 [Quic-Trace] 1740 "https:QUIC trace utilities //github.com/google/quic- 1741 trace". 1743 [RFC1273] Schwartz, M., "Measurement Study of Changes in Service- 1744 Level Reachability in the Global TCP/IP Internet: Goals, 1745 Experimental Design, Implementation, and Policy 1746 Considerations", RFC 1273, DOI 10.17487/RFC1273, November 1747 1991, . 1749 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1750 "Definition of the Differentiated Services Field (DS 1751 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1752 DOI 10.17487/RFC2474, December 1998, 1753 . 1755 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1756 and W. Weiss, "An Architecture for Differentiated 1757 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1758 . 1760 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1761 Compression", RFC 2507, DOI 10.17487/RFC2507, February 1762 1999, . 1764 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1765 Headers for Low-Speed Serial Links", RFC 2508, 1766 DOI 10.17487/RFC2508, February 1999, 1767 . 1769 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1770 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1771 . 1773 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1774 Shelby, "Performance Enhancing Proxies Intended to 1775 Mitigate Link-Related Degradations", RFC 3135, 1776 DOI 10.17487/RFC3135, June 2001, 1777 . 1779 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1780 of Explicit Congestion Notification (ECN) to IP", 1781 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1782 . 1784 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1785 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1786 . 1788 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1789 A., Peterson, J., Sparks, R., Handley, M., and E. 1790 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1791 DOI 10.17487/RFC3261, June 2002, 1792 . 1794 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1795 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1796 DOI 10.17487/RFC3393, November 2002, 1797 . 1799 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1800 Jacobson, "RTP: A Transport Protocol for Real-Time 1801 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1802 July 2003, . 1804 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1805 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1806 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1807 . 1809 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1810 DOI 10.17487/RFC4302, December 2005, 1811 . 1813 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1814 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1815 . 1817 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1818 "Extended RTP Profile for Real-time Transport Control 1819 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1820 DOI 10.17487/RFC4585, July 2006, 1821 . 1823 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1824 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1825 DOI 10.17487/RFC4737, November 2006, 1826 . 1828 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 1829 Header Compression (ROHC) Framework", RFC 4995, 1830 DOI 10.17487/RFC4995, July 2007, 1831 . 1833 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1834 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1835 . 1837 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 1838 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1839 DOI 10.17487/RFC5236, June 2008, 1840 . 1842 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1843 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1844 March 2009, . 1846 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1847 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1848 June 2010, . 1850 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1851 Protocol Port Randomization", BCP 156, RFC 6056, 1852 DOI 10.17487/RFC6056, January 2011, 1853 . 1855 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1856 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1857 DOI 10.17487/RFC6269, June 2011, 1858 . 1860 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 1861 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 1862 2011, . 1864 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1865 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1866 January 2012, . 1868 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1869 "IPv6 Flow Label Specification", RFC 6437, 1870 DOI 10.17487/RFC6437, November 2011, 1871 . 1873 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1874 for Equal Cost Multipath Routing and Link Aggregation in 1875 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1876 . 1878 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1879 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1880 2014, . 1882 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1883 "Recommendations for Secure Use of Transport Layer 1884 Security (TLS) and Datagram Transport Layer Security 1885 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1886 2015, . 1888 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1889 Recommendations Regarding Active Queue Management", 1890 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1891 . 1893 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1894 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1895 Measurement of Broadband Performance (LMAP)", RFC 7594, 1896 DOI 10.17487/RFC7594, September 2015, 1897 . 1899 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1900 Trammell, B., Huitema, C., and D. Borkmann, 1901 "Confidentiality in the Face of Pervasive Surveillance: A 1902 Threat Model and Problem Statement", RFC 7624, 1903 DOI 10.17487/RFC7624, August 2015, 1904 . 1906 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1907 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1908 May 2016, . 1910 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1911 "Observations on the Dropping of Packets with IPv6 1912 Extension Headers in the Real World", RFC 7872, 1913 DOI 10.17487/RFC7872, June 2016, 1914 . 1916 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 1917 D. Ros, "Characterization Guidelines for Active Queue 1918 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1919 2016, . 1921 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1922 Updates for Secure Real-time Transport Protocol (SRTP) 1923 Extension for Datagram Transport Layer Security (DTLS)", 1924 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1925 . 1927 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 1928 "Proportional Integral Controller Enhanced (PIE): A 1929 Lightweight Control Scheme to Address the Bufferbloat 1930 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 1931 . 1933 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1934 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1935 . 1937 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1938 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1939 March 2017, . 1941 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1942 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1943 March 2017, . 1945 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1946 Explicit Congestion Notification (ECN)", RFC 8087, 1947 DOI 10.17487/RFC8087, March 2017, 1948 . 1950 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1951 Ed., "Services Provided by IETF Transport Protocols and 1952 Congestion Control Mechanisms", RFC 8095, 1953 DOI 10.17487/RFC8095, March 2017, 1954 . 1956 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 1957 Performance and Diagnostic Metrics (PDM) Destination 1958 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 1959 . 1961 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 1962 Iyengar, Ed., "Controlled Delay Active Queue Management", 1963 RFC 8289, DOI 10.17487/RFC8289, January 2018, 1964 . 1966 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1967 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 1968 and Active Queue Management Algorithm", RFC 8290, 1969 DOI 10.17487/RFC8290, January 2018, 1970 . 1972 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 1973 Pervasive Encryption on Operators", RFC 8404, 1974 DOI 10.17487/RFC8404, July 2018, 1975 . 1977 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1978 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1979 . 1981 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 1982 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 1983 2019, . 1985 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1986 Q., and E. Smith, "Cryptographic Protection of TCP Streams 1987 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 1988 . 1990 Appendix A. Revision information 1992 -00 This is an individual draft for the IETF community. 1994 -01 This draft was a result of walking away from the text for a few 1995 days and then reorganising the content. 1997 -02 This draft fixes textual errors. 1999 -03 This draft follows feedback from people reading this draft. 2001 -04 This adds an additional contributor and includes significant 2002 reworking to ready this for review by the wider IETF community Colin 2003 Perkins joined the author list. 2005 Comments from the community are welcome on the text and 2006 recommendations. 2008 -05 Corrections received and helpful inputs from Mohamed Boucadair. 2010 -06 Updated following comments from Stephen Farrell, and feedback via 2011 email. Added a draft conclusion section to sketch some strawman 2012 scenarios that could emerge. 2014 -07 Updated following comments from Al Morton, Chris Seal, and other 2015 feedback via email. 2017 -08 Updated to address comments sent to the TSVWG mailing list by 2018 Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 2019 11/05/2018, and Spencer Dawkins. 2021 -09 Updated security considerations. 2023 -10 Updated references, split the Introduction, and added a paragraph 2024 giving some examples of why ossification has been an issue. 2026 -01 This resolved some reference issues. Updated section on 2027 observation by devices on the path. 2029 -02 Comments received from Kyle Rose, Spencer Dawkins and Tom 2030 Herbert. The network-layer information has also been re-organised 2031 after comments at IETF-103. 2033 -03 Added a section on header compression and rewriting of sections 2034 referring to RTP transport. This version contains author editorial 2035 work and removed duplicate section. 2037 -04 Revised following SecDir Review 2038 o Added some text on TLS story (additional input sought on relevant 2039 considerations). 2041 o Section 2, paragraph 8 - changed to be clearer, in particular, 2042 added "Encryption with secure key distribution prevents" 2044 o Flow label description rewritten based on PS/BCP RFCs. 2046 o Clarify requirements from RFCs concerning the IPv6 flow label and 2047 highlight ways it can be used with encryption. (section 3.1.3) 2049 o Add text on the explicit spin-bit work in the QUIC DT. Added 2050 greasing of spin-bit. (Section 6.1) 2052 o Updated section 6 and added more explanation of impact on 2053 operators. 2055 o Other comments addressed. 2057 -05 Editorial pass and minor corrections noted on TSVWG list. 2059 -06 Updated conclusions and minor corrections. Responded to request 2060 to add OAM discussion to Section 6.1. 2062 -07 Addressed feedback from Ruediger and Thomas. 2064 Section 2 deserved some work to make it easier to read and avoid 2065 repetition. This edit finally gets to this, and eliminates some 2066 duplication. This also moves some of the material from section 2 to 2067 reform a clearer conclusion. The scope remains focussed on the usage 2068 of transport headers and the implications of encryption - not on 2069 proposals for new techniques/specifications to be developed. 2071 -08 Addressed feedback and completed editorial work, including 2072 updating the text referring to RFC7872, in preparation for a WGLC. 2074 Authors' Addresses 2076 Godred Fairhurst 2077 University of Aberdeen 2078 Department of Engineering 2079 Fraser Noble Building 2080 Aberdeen AB24 3UE 2081 Scotland 2083 EMail: gorry@erg.abdn.ac.uk 2084 URI: http://www.erg.abdn.ac.uk/ 2085 Colin Perkins 2086 University of Glasgow 2087 School of Computing Science 2088 Glasgow G12 8QQ 2089 Scotland 2091 EMail: csp@csperkins.org 2092 URI: https://csperkins.org//