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