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