idnits 2.17.1 draft-ietf-tsvwg-transport-encrypt-16.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 875: '... IPv6 "source nodes SHOULD assign each...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1376 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 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4995 (Obsoleted by RFC 5795) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C. Perkins 5 Expires: January 14, 2021 University of Glasgow 6 July 13, 2020 8 Considerations around Transport Header Confidentiality, Network 9 Operations, and the Evolution of Internet Transport Protocols 10 draft-ietf-tsvwg-transport-encrypt-16 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. 23 This document discusses the possible impact when network traffic uses 24 a protocol with an encrypted transport header. It suggests issues to 25 consider when designing new transport protocols or features. These 26 considerations arise from concerns such as network operations, 27 prevention of network ossification, enabling transport protocol 28 evolution and respect for user privacy. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 14, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Use of Transport Header Information in the Network . . . 6 67 2.2. Authentication of Transport Header Information . . . . . 8 68 2.3. Perspectives on Observable Transport Header Fields . . . 8 69 3. Current uses of Transport Headers within the Network . . . . 12 70 3.1. To Identify Transport Protocols and Flows . . . . . . . . 13 71 3.2. To Understand Transport Protocol Performance . . . . . . 14 72 3.3. To Support Network Operations . . . . . . . . . . . . . . 21 73 3.4. To Support Network Diagnostics and Troubleshooting . . . 24 74 3.5. To Support Header Compression . . . . . . . . . . . . . . 25 75 4. Encryption and Authentication of Transport Headers . . . . . 26 76 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 26 77 4.2. Approaches to Transport Header Protection . . . . . . . . 27 78 5. Addition of Transport OAM Information to Network-Layer 79 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 80 5.1. Use of OAM within a Maintenance Domain . . . . . . . . . 29 81 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29 82 6. Intentionally Exposing Transport Information to the Network . 30 83 6.1. Exposing Transport Information in Extension Headers . . . 30 84 6.2. Common Exposed Transport Information . . . . . . . . . . 31 85 6.3. Considerations for Exposing Transport Information . . . . 31 86 7. Implications of Protecting the Transport Headers . . . . . . 31 87 7.1. Independent Measurement . . . . . . . . . . . . . . . . . 32 88 7.2. Characterising "Unknown" Network Traffic . . . . . . . . 34 89 7.3. Accountability and Internet Transport Protocols . . . . . 34 90 7.4. Impact on Network Operations . . . . . . . . . . . . . . 35 91 7.5. Impact on Research, Development and Deployment . . . . . 35 92 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 96 12. Informative References . . . . . . . . . . . . . . . . . . . 42 97 Appendix A. Revision information . . . . . . . . . . . . . . . . 51 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 100 1. Introduction 102 Transport protocols have supported end-to-end encryption of payload 103 data for many years. Examples include Transport Layer Security (TLS) 104 over TCP [RFC8446], Datagram TLS [RFC6347][I-D.ietf-tls-dtls13], 105 Secure Real-time Transport Protocol (SRTP) [RFC3711], and tcpcrypt 106 [RFC8548]. Some of these specifications also provide integrity 107 protection of all, or part, of the transport header. 109 This end-to-end transport payload encryption brings many benefits in 110 terms of providing confidentiality and protecting user privacy. The 111 benefits have been widely discussed, for example in [RFC7624]. This 112 document supports and encourages increased use of end-to-end payload 113 encryption in transport protocols. The implications of protecting 114 the transport payload data are therefore not further discussed in 115 this document. 117 A further level of protection can be achieved by encrypting the 118 entire network layer payload, including both the transport headers 119 and the transport payload data. This does not expose any transport 120 header information to devices in the network, and therefore also 121 prevents modification along a network path. An example of encryption 122 at the network layer is the IPsec Encapsulating Security Payload 123 (ESP) [RFC4303] in tunnel mode. Virtual Private Networks (VPNs) 124 typically also operate in this way. This form of encryption is not 125 further discussed in this document. 127 There is also a middle ground, comprising transport protocols that 128 encrypt some, or all, of the transport layer header information, in 129 addition to encrypting the transport payload data. An example of 130 such a protocol, that is now seeing widespread interest and 131 deployment, is the QUIC transport protocol [I-D.ietf-quic-transport]. 132 The encryption and authentication of transport header information can 133 prevent unwanted modification of transport header information by 134 network devices, reducing the risk of protocol ossification. It also 135 reduces the amount of metadata about the progress of the transport 136 connection that is visible to the network [RFC8558]. 138 In this document, the term "transport header information" is used to 139 describe transport layer information concerning the operation of the 140 transport protocol (i.e., information used by the transport protocol 141 that might be carried in a protocol header). This does not refer to 142 transport payload data (i.e., information transferred by the 143 transport service), which itself could be encrypted. 145 The direction in which the use of transport header encryption evolves 146 could have significant implications on the way the Internet 147 architecture develops, and therefore needs to be considered as a part 148 of protocol design and evolution. This includes considering whether 149 the endpoints permit (or are able to permit) network devices to 150 observe specific information by explicitly exposing a transport 151 header field (or a field derived from transport header information) 152 to the network; whether it is intended that a network device can 153 modify a transport header field; and whether any modification along 154 the network path can be detected by the receiving endpoint. This can 155 require changes to network operations and other practises and could 156 drive changes to the design of network measurement for research, 157 operational, and standardisation purposes. 159 As discussed in [RFC7258], the IETF has concluded that Pervasive 160 Monitoring (PM) is a technical attack that needs to be mitigated in 161 the design of IETF protocols, but RFC7258 also notes that "Making 162 networks unmanageable to mitigate PM is not an acceptable outcome, 163 but ignoring PM would go against the consensus documented here. An 164 appropriate balance will emerge over time as real instances of this 165 tension are considered". In support of achieving that balance, this 166 document discusses design and deployment considerations for use of 167 transport header encryption to protect against pervasive monitoring. 169 The transport protocols developed for the Internet are used across a 170 wide range of paths across network segments with many different 171 regulatory, commercial, and engineering considerations. This 172 document considers some of the costs and changes to network 173 management and research that are implied by widespread use of 174 transport protocols that encrypt their transport header information. 175 It reviews the implications of developing transport protocols that 176 use end-to-end encryption to provide confidentiality of their 177 transport layer headers, and considers the effect of such changes on 178 transport protocol design, transport protocol evolution, and network 179 operations. It also considers some anticipated implications on 180 application evolution. This provides considerations relating to the 181 design of transport protocols and features where the transport 182 protocol encrypts some or all of their header information. 184 2. Context and Rationale 186 The transport layer provides end-to-end interactions between 187 endpoints (processes) using a network path. Transport protocols 188 layer over the network-layer service, and are usually sent in the 189 payload of network-layer packets. Transport protocols support end- 190 to-end communication between applications, using higher-layer 191 protocols running on the end systems (i.e., transport endpoints). 193 This simple architectural view does not present one of the core 194 functions of an Internet transport: to discover and adapt to the 195 characteristics of the network path that is currently being used. 196 The design of Internet transport protocols is as much about trying to 197 avoid the unwanted side effects of congestion on a flow and other 198 capacity-sharing flows, avoiding congestion collapse, adapting to 199 changes in the path characteristics, etc., as it is about end-to-end 200 feature negotiation, flow control, and optimising for performance of 201 a specific application. 203 Transport headers have end-to-end meaning, but have often been 204 observed by equipment within the network. Transport protocol 205 specifications have not tended to consider this. Designs have often 206 failed to: 208 o specify what parts of the transport header can be modified by the 209 network to signal to the transport, and in what way; 211 o indicate what parts of the transport header are intended to be 212 invariant across protocol versions and visible to the network; 214 o indicate what parts of the transport header are intended expected 215 to change in future and might need to be protected to prevent 216 protocol ossification; 218 o and have often not defined which parts of the header need to be 219 protected for privacy. 221 This motivates a need to change the way transport protocols are 222 designed, modified, and specified. 224 Increasing concern about pervasive network monitoring 225 [RFC7258][RFC7624], and growing awareness of the problem of protocol 226 ossification caused by middlebox interference with Internet traffic, 227 has motivated a shift in transport protocol design. For example, 228 transport protocols, such as QUIC [I-D.ietf-quic-transport], encrypt 229 the majority of their transport headers to prevent observation and 230 protect against modification by the network, and to make explicit 231 their invariants and what is intended to be visible to the network. 233 Transport header encryption is expected to form a core part of future 234 transport protocol designs. It can help to protect against pervasive 235 monitoring, improve privacy, and reduce protocol ossification. 236 Transport protocols that use header encryption with secure key 237 distribution can provide confidentiality and protection for some, or 238 all, of the transport header, controlling what is visible to, and can 239 be modified by the network. 241 The increased use of transport header encryption has benefits, but 242 also has implications for the broader ecosystem. The transport 243 community has, to date, relied on measurements and insights from the 244 network operations community to understand protocol behaviour, and to 245 inform the selection of appropriate mechanisms to ensure a safe, 246 reliable, and robust Internet. In turn, network operators and access 247 providers have relied upon being able to observe traffic patterns and 248 requirements, both in aggregate and at the flow level, to help 249 understand and optimise the behaviour of their networks. 251 Transport header encryption can be used to intentionally limit the 252 information available to network observers. The widespread use would 253 therefore limit such observations, unless transport protocols are 254 modified to selectively expose transport header information outside 255 of the encrypted transport header. 257 It is important to understand how transport header information is 258 used by networks, to allow future protocol designs to make an 259 informed choice on what, if any, transport layer information to 260 expose to the network. 262 2.1. Use of Transport Header Information in the Network 264 In-network measurement of transport flow characteristics can be used 265 to enhance performance, control cost and improve service reliability. 266 To support network operations and enhance performance, some operators 267 have deployed functionality that utilises on-path observations of the 268 transport headers of packets passing through their network ([RFC8517] 269 gives an operator perspective on such use). 271 When network devices rely on the presence of a header field or the 272 semantics of specific header information, this can lead to 273 ossification where an endpoint has to supply a specific header to 274 receive the network service that it desires. 276 In some cases, network-layer use of transport layer information can 277 be benign or advantageous to the protocol (e.g., recognising the 278 start of a TCP connection, providing header compression for an SRTP 279 flow [RFC3711], or explicitly using exposed protocol information to 280 provide consistent decisions by on-path devices). Header compression 281 (e.g., [RFC5795]) depends on understanding of transport header and 282 the way fields change packet-by-packet; as also do techniques to 283 improve TCP performance by transparent modification of 284 acknowledgement traffic [RFC3449]. Introducing a new transport 285 protocol or changes to existing transport header information prevent 286 these methods being used or require the network devices to be 287 updated. 289 However, in other cases, ossification can have unwanted outcomes. 290 Ossification can frustrate the evolution of a transport protocol. A 291 mechanism implemented in a network device, such as a firewall, that 292 requires a header field to have only a specific known set of values 293 can prevent the device from forwarding packets using a different 294 version of the protocol that introduces a feature that changes to a 295 new value for the observed field. 297 An example of this type ossification was observed in the development 298 of TLS 1.3 [RFC8446], where the design needed to function in the 299 presence of deployed middleboxes that relied on the presence of 300 certain header fields exposed in TLS 1.2 [RFC5426]. The design of 301 Multipath TCP (MPTCP) [RFC8684] also had to be revised to account for 302 middleboxes (known as "TCP Normalizers") that monitor the evolution 303 of the window advertised in the TCP header and then reset connections 304 when the window did not grow as expected. Similarly, issues have 305 been reported using TCP. For example, TCP Fast Open [RFC7413] can 306 experience middleboxes that modify the transport header of packets by 307 removing "unknown" TCP options, segments with unrecognised TCP 308 options can be dropped, segments that contain data and set the SYN 309 bit can be dropped, or middleboxes that disrupt connections that send 310 data before completion of the three-way handshake. 312 Other examples of ossification have included middleboxes that modify 313 transport headers by rewriting TCP sequence and acknowledgement 314 numbers, but are unaware of the (newer) TCP selective acknowledgement 315 (SACK) option and therefore fail to correctly rewrite the SACK 316 information to match the changes that were made to the fixed TCP 317 header, preventing SACK from operating correctly. 319 In all these cases, middleboxes with a hard-coded, but incomplete, 320 understanding of transport behaviour, interacted poorly with 321 transport protocols after the transport behaviour was changed. In 322 some case, the middleboxes modified or replaced information in the 323 transport protocol header. 325 Transport header encryption prevents an on-path device from observing 326 the transport headers, and therefore stops mechanisms being built 327 that directly rely on or infer semantics of the transport header 328 information. Encryption is normally combined with authentication of 329 the protected information. RFC 8546 summarises this approach, 330 stating that it is "The wire image, not the protocol's specification, 331 determines how third parties on the network paths among protocol 332 participants will interact with that protocol" (Section 1 of 334 [RFC8546]), and it can be expected that header information that is 335 not encrypted will become ossified. 337 While encryption can reduce ossification of the transport protocol, 338 it does not itself prevent ossification of the network service. 339 People seeking to understand network traffic could still come to rely 340 on pattern inferences and other heuristics or machine learning to 341 derive measurement data and as the basis for network forwarding 342 decisions [RFC8546]. This can also create dependencies on the 343 transport protocol, or the patterns of traffic it can generate, also 344 in time resulting in ossification of the service. 346 2.2. Authentication of Transport Header Information 348 The designers of a transport protocol have to decide whether to 349 encrypt all, or a part of, the transport layer information. 350 Section 4 of [RFC8558] states: "Anything exposed to the path should 351 be done with the intent that it be used by the network elements on 352 the path". 354 Protocol designers can decide not to encrypt certain transport header 355 fields, making those fields observable in the network, or can define 356 new fields designed to explicitly expose observable transport layer 357 information to the network. Where exposed fields are intended to be 358 immutable (i.e., can be observed, but not modified by a network 359 device), the endpoints are encouraged to use authentication to 360 provide a cryptographic integrity check that can detect if these 361 immutable fields have been modified by network devices. 362 Authentication can also help to prevent attacks that rely on sending 363 packets that fake exposed control signals in transport headers (e.g., 364 TCP RST spoofing). 366 Making a part of a transport header observable or exposing new header 367 fields can lead to ossification of that part of a header as network 368 devices come to rely on observations of the exposed fields. A 369 protocol design that provides an observable field might want to 370 restrict the choice of usable values in a field by intentionally 371 varying the format and/or value of the field to reduce the chance of 372 ossification (see Section 4). 374 2.3. Perspectives on Observable Transport Header Fields 376 Transport header fields have been observed within the network for a 377 variety of purposes. Some purposes are related to network management 378 and operations. Use cases where the network devices intentionally 379 modify mutable transport layer information are out of scope and are 380 not described further in this document. More information may be 381 found in other RFCs (e.g., [RFC3449], [RFC3135], [RFC8404], 382 [RFC8462]), and [RFC8517]. 384 The list below provides an overview with different uses of exposed 385 immutable information. 387 Network Operations: A transport protocol with observable header 388 information can enable explicit measurement and 389 analysis of protocol performance, network 390 anomalies, and failure pathologies at any point 391 along the Internet path. In many cases, it is 392 important to relate observations to specific 393 equipment/configurations, to a specific network 394 segment, or sometimes to a specific protocol or 395 application. 397 When transport header information is not 398 observable, it cannot be used by network 399 operators. Some operators might work without 400 that information, or some might turn to more 401 ambitious ways to collect, estimate, or infer 402 this data. (Operational practises aimed at 403 guessing transport parameters are out of scope 404 for this document, and are only mentioned here to 405 recognise that encryption does not stop operators 406 from attempting to apply practises that have been 407 used with unencrypted transport headers.) 409 See also Section 3, Section 5, Section 7.4 and 410 Section 7.5. 412 Analysis of Aggregate Traffic: Observable transport headers have 413 been utilised to determine which transport 414 protocols and features are being used across a 415 network segment, and to measure trends in the 416 pattern of usage. For some use cases, end-to-end 417 measurements/traces are sufficient and can assist 418 in developing and debugging new transports and 419 analysing their deployment. In other uses, it is 420 important to relate observations to specific 421 equipment/configurations or particular network 422 segments. 424 This information can help anticipate the demand 425 for network upgrades and roll-out, or affect on- 426 going traffic engineering activities performed by 427 operators such as determining which parts of the 428 path contribute delay, jitter, or loss. 430 Tools that rely upon observing specific headers, 431 could fail to produce useful data when those 432 headers are encrypted. While this impact could, 433 in many cases, be small, there are scenarios 434 where operators have actively monitored and 435 supported particular services, e.g., to explore 436 issues relating to Quality of Service (QoS), to 437 perform fast re-routing of critical traffic, to 438 mitigate the characteristics of specific radio 439 links, and so on. 441 Troubleshooting: Observable transport headers have been utilised 442 by operators as a part of network troubleshooting 443 and diagnostics. Metrics derived from this 444 observed header information can help localise the 445 network segment introducing the loss or latency. 446 Effective troubleshooting often requires 447 understanding of transport behaviour. Flows 448 experiencing packet loss or jitter are hard to 449 distinguish from unaffected flows when only 450 observing network layer headers. 452 Observable transport feedback information (e.g., 453 RTP Control Protocol (RTCP) reception reports 454 [RFC3550]) can explicitly make loss metrics 455 visible to operators. Loss metrics can also be 456 deduced with more complexity from other header 457 information (e.g., by observing TCP SACK blocks). 458 When the transport header information is 459 encrypted, explicit observable fields could also 460 be made available at the network or transport 461 layers to provide these functions. [RFC8558] 462 motivates the design of signals to focus on their 463 usage, decoupled from the internal design of the 464 protocol state machine. This could avoid 465 ossifying the protocol around the design of a 466 specific protocol mechanism. 468 See also Section 3.4 and Section 5. 470 Network Protection: Observable transport headers currently provide 471 information that is useful input to classify and 472 detect anomalous events, such as changes in 473 application behaviour or distributed DoS attacks. 474 Operators often seek to uniquely disambiguate 475 unwanted traffic. 477 Where flows cannot be disambiguated based on 478 transport header information, this could result 479 in less-efficient identification of unwanted 480 traffic, the introduction of rate limits for 481 uncharacterised traffic, or the use of heuristics 482 to identify anomalous flows. 484 See also Section 7.2 and Section 7.3. 486 Verifiable Data: Observable transport headers can be used to 487 provide open and verifiable measurements to 488 support operations, research, and protocol 489 development. The ability of multiple stake 490 holders to review transport header traces helps 491 develop insight into performance and traffic 492 contribution of specific variants of a protocol. 493 Independently observed data is important to help 494 ensure the health of the research and development 495 communities. 497 When transport header information can not be 498 observed, this can reduce the range of actors 499 that can observe data. This limits the 500 information sources available to the Internet 501 community to understand the operation of 502 transport protocols, reducing information to 503 inform design decisions and standardisation of 504 the new protocols/features and related 505 operational practises 507 See also Section 7. 509 SLA Compliance: Observable transport headers coupled with 510 published transport specifications allow 511 operators and regulators to explore the 512 compliance with Service Level Agreements (SLAs). 514 When transport header information can not be 515 observed, other methods have to be found to 516 confirm that the traffic produced conforms to the 517 expectations of the operator or developer. 519 Independently verifiable performance metrics can 520 be utilised to demonstrate regulatory compliance 521 in some jurisdictions, and as a basis for 522 informing design decisions. This can bring 523 assurance to those operating networks, often 524 avoiding deployment of complex techniques that 525 routinely monitor and manage Internet traffic 526 flows (e.g., avoiding the capital and operational 527 costs of deploying flow rate-limiting and network 528 circuit-breaker methods [RFC8084]). 530 See also Section 5 and Section 7.1 to 531 Section 7.4. 533 This analysis does not judge whether specific practises are 534 necessary. It is not an endorsement of any particular practice. 536 3. Current uses of Transport Headers within the Network 538 In response to pervasive monitoring [RFC7624] revelations and the 539 IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], 540 efforts are underway to increase encryption of Internet traffic. 541 Applying confidentiality to transport header fields can improve 542 privacy, and can help to mitigate certain attacks, but can also 543 affect network operations [RFC8404]. 545 When considering what parts of the transport headers should be 546 encrypted to provide confidentiality, and what parts should be 547 visible to the network (including non-encrypted but authenticated 548 headers), it is necessary to consider both the impact on network 549 operations and management, and the implications for ossification and 550 user privacy [Measurement]. Different parties will view the relative 551 importance of these concerns differently. For some, the benefits of 552 encrypting all the transport headers outweigh the impact of doing so; 553 others might analyse the security, privacy, and ossification impacts 554 and arrive at a different trade-off. 556 This section reviews examples of the observation of transport layer 557 headers within the network. Unencrypted transport headers provide 558 information can support network operations and management, and this 559 section notes some ways in which this has been done. Unencrypted 560 transport header information also contributes metadata that can be 561 exploited for purposes unrelated to network transport measurement, 562 diagnostics or troubleshooting (e.g., to block or to throttle traffic 563 from a specific content provider), and this section also notes some 564 threats relating to unencrypted transport headers. 566 Exposed transport information also provides a source of information 567 that contributes to linked data sets, which could be exploited to 568 deduce private information, e.g., user patterns, user location, 569 tracking behaviour, etc. This might reveal information the parties 570 did not intend to be revealed. [RFC6973] aims to make designers, 571 implementers, and users of Internet protocols aware of privacy- 572 related design choices in IETF protocols. 574 This section does not consider intentional modification of transport 575 headers by middleboxes, such as in Network Address Translation (NAT) 576 or Firewalls. Common issues concerning IP address sharing are 577 described in [RFC6269]. 579 3.1. To Identify Transport Protocols and Flows 581 Information in exposed transport layer headers can be used by the 582 network to identify transport protocols and flows [RFC8558]. The 583 ability to identify transport protocols, flows, and sessions is a 584 common function performed, for example, by measurement activities, 585 QoS classifiers, and firewalls. These functions can be beneficial, 586 and performed with the consent of, and in support of, the end user. 587 Alternatively, a network operator could use the same mechanisms to 588 support practises that are adversarial to the end user, including 589 blocking, de-prioritising, and monitoring traffic without consent. 591 Observable transport header information, together with information in 592 the network header, has been used to identify flows and their 593 connection state, together with the set of protocol options being 594 used. Transport protocols, such as TCP and the Stream Control 595 Transport Protocol (SCTP), specify a standard base header that 596 includes sequence number information and other data. They also have 597 the possibility to negotiate additional headers at connection setup, 598 identified by an option number in the transport header. 600 In some uses, an assigned transport port (e.g., 0..49151) can 601 identify the upper-layer protocol or service [RFC7605]. However, 602 port information alone is not sufficient to guarantee identification. 603 Applications can use arbitrary ports and do not need to use assigned 604 port numbers. The use of an assigned port number is also not limited 605 to the protocol for which the port is intended. Multiple sessions 606 can also be multiplexed on a single port, and ports can be re-used by 607 subsequent sessions. 609 Some flows can be identified by observing signalling protocol data 610 (e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of 611 magic numbers placed in the first byte(s) of the datagram payload 612 [RFC7983]. 614 When transport header information cannot be observed, this removes 615 information that could have been used to classify flows by passive 616 observers along the path. More ambitious ways could be used to 617 collect, estimate, or infer flow information, including heuristics 618 based on the analysis of traffic patterns. For example, an operator 619 that cannot access the Session Description Protocol (SDP) session 620 descriptions [RFC4566] to classify a flow as audio traffic, might 621 instead use (possibly less-reliable) heuristics to infer that short 622 UDP packets with regular spacing carry audio traffic. Operational 623 practises aimed at inferring transport parameters are out of scope 624 for this document, and are only mentioned here to recognise that 625 encryption does not prevent operators from attempting to apply 626 practises that were used with unencrypted transport headers. 628 The IAB [RFC8546] have provided a summary of expected implications of 629 increased encryption on network functions that use the observable 630 headers and describe the expected benefits of designs that explicitly 631 declare protocol invariant header information that can be used for 632 this purpose. 634 3.2. To Understand Transport Protocol Performance 636 Information in exposed transport layer headers can be used by the 637 network to understand transport protocol performance and behaviour. 639 3.2.1. Using Information Derived from Transport Layer Headers 641 Observable transport headers enable explicit measurement and analysis 642 of protocol performance, network anomalies, and failure pathologies 643 at any point along the Internet path. Some operators use passive 644 monitoring to manage their portion of the Internet by characterising 645 the performance of link/network segments. Inferences from transport 646 headers are used to derive performance metrics. A variety of open 647 source and commercial tools have been deployed that utilise transport 648 header information in this way to derive the following metrics: 650 Traffic Rate and Volume: Volume measures per-application can be used 651 to characterise the traffic that uses a network segment or the 652 pattern of network usage. Observing the protocol sequence number 653 and packet size offers one way to measure this (e.g., measurements 654 observing counters in periodic reports such as RTCP; or 655 measurements observing protocol sequence numbers in statistical 656 samples of packet flows, or specific control packets, such as 657 those observed at the start and end of a flow). 659 Measurements can be per endpoint, or for an endpoint aggregate. 660 This can be used, for example, to assess subscriber usage or for 661 billing purposes. 663 Measurements can also be used to trigger traffic shaping, and to 664 associate QoS support within the network and lower layers. This 665 can be done with consent and in support of an end user, to improve 666 quality of service; or can be used by the network to de-prioritise 667 certain flows without user consent. 669 Volume measures can also be valuable for capacity planning and 670 providing detail of trends in usage. 672 The traffic rate and volume can be determined providing that the 673 packets belonging to individual flows can be identified, but there 674 might be no additional information about a flow when the transport 675 headers cannot be observed. 677 Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., 678 from transport sequence numbers or inferred from observing 679 transport protocol interactions) and has been used as a metric for 680 performance assessment and to characterise transport behaviour. 681 Understanding the location and root cause of loss can help an 682 operator determine whether this requires corrective action. 683 Network operators have used the variation in patterns of loss as a 684 key performance metric, utilising this to detect changes in the 685 offered service. 687 There are various causes of loss, including: corruption of link 688 frames (e.g., due to interference on a radio link), buffering loss 689 (e.g., overflow due to congestion, Active Queue Management (AQM) 690 [RFC7567], or inadequate provision following traffic pre-emption), 691 and policing (traffic management) [RFC2475]. Understanding flow 692 loss rates requires either observing sequence numbers in network 693 or transport headers, or maintaining per-flow packet counters 694 (flow identification often requires transport layer information). 695 Per-hop loss can also sometimes be monitored at the interface 696 level by devices in the network. 698 Losses can often occur as bursts, randomly-timed events, etc. The 699 pattern of loss can provide insight into the cause of loss. It 700 can also be valuable to understand the conditions under which loss 701 occurs, which usually requires relating loss to the traffic 702 flowing at a network node or segment at the time of loss. This 703 can also help identify cases where loss could have been wrongly 704 identified, or where the transport did not require transmission of 705 a lost packet. 707 Throughput and Goodput: Throughput is the amount of payload data 708 sent by a flow per time interval. Goodput (see Section 2.5 of 709 [RFC7928]) is a measure of useful data exchanged (the ratio of 710 useful data to total volume of traffic sent by a flow). The 711 throughput of a flow can be determined in the absence of transport 712 header information, providing that the individual flow can be 713 identified, and the overhead known. Goodput requires ability to 714 differentiate loss and retransmission of packets, for example by 715 observing packet sequence numbers in the TCP or RTP headers 716 [RFC3550]. 718 Latency: Latency is a key performance metric that impacts 719 application and user-perceived response times. It often 720 indirectly impacts throughput and flow completion time. This 721 determines the reaction time of the transport protocol itself, 722 impacting flow setup, congestion control, loss recovery, and other 723 transport mechanisms. The observed latency can have many 724 components [Latency]. Of these, unnecessary/unwanted queueing in 725 network buffers has often been observed as a significant factor 726 [bufferbloat]. Once the cause of unwanted latency has been 727 identified, this can often be eliminated. 729 To measure latency across a part of a path, an observation point 730 [RFC7799] can measure the experienced round trip time (RTT) using 731 packet sequence numbers and acknowledgements, or by observing 732 header timestamp information. Such information allows an 733 observation point in the network to determine not only the path 734 RTT, but also allows measurement of the upstream and downstream 735 contribution to the RTT. This could be used to locate a source of 736 latency, e.g., by observing cases where the median RTT is much 737 greater than the minimum RTT for a part of a path. 739 The service offered by network operators can benefit from latency 740 information to understand the impact of configuration changes and 741 to tune deployed services. Latency metrics are key to evaluating 742 and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit 743 Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements 744 could identify excessively large buffers, indicating where to 745 deploy or configure AQM. An AQM method is often deployed in 746 combination with other techniques, such as scheduling [RFC7567] 747 [RFC8290] and although parameter-less methods are desired 748 [RFC7567], current methods often require tuning [RFC8290] 749 [RFC8289] [RFC8033] because they cannot scale across all possible 750 deployment scenarios. 752 Latency and round-trip time information can potentially expose 753 some information useful for approximate geolocation, as discussed 754 in [PAM-RTT]. Encrypting transport headers can reduce the latency 755 information that is available. 757 Variation in delay: Some network applications are sensitive to 758 (small) changes in packet timing (jitter). Short and long-term 759 delay variation can impact on the latency of a flow and hence the 760 perceived quality of applications using the network. For example, 761 jitter metrics are often cited when characterising paths 762 supporting real-time traffic. The expected performance of such 763 applications, can be inferred from a measure the variation in 764 delay observed along a portion of the path [RFC3393] [RFC5481]. 765 The requirements resemble those for the measurement of latency. 767 Flow Reordering: Significant packet reordering within a flow can 768 impact time-critical applications and can be interpreted as loss 769 by reliable transports. Many transport protocol techniques are 770 impacted by reordering (e.g., triggering TCP retransmission or re- 771 buffering of real-time applications). Packet reordering can occur 772 for many reasons, from equipment design to misconfiguration of 773 forwarding rules. Network tools can detect and measure unwanted/ 774 excessive reordering, and the impact on transport performance. 776 There have been initiatives in the IETF transport area to reduce 777 the impact of reordering within a transport flow, possibly leading 778 to a reduction in the requirements for preserving ordering. These 779 have potential to simplify network equipment design as well as the 780 potential to improve robustness of the transport service. 781 Measurements of reordering can help understand the present level 782 of reordering within deployed infrastructure, and inform decisions 783 about how to progress such mechanisms. Key performance indicators 784 are retransmission rate, packet drop rate, sector utilisation 785 level, a measure of reordering, peak rate, the ECN congestion 786 experienced (CE) marking rate, etc. 788 Metrics have been defined that evaluate whether a network has 789 maintained packet order on a packet-by-packet basis [RFC4737] 790 [RFC5236]. 792 Techniques for measuring reordering typically observe packet 793 sequence numbers. Some protocols provide in-built monitoring and 794 reporting functions. Transport fields in the RTP header [RFC3550] 795 [RFC4585] can be observed to derive traffic volume measurements 796 and provide information on the progress and quality of a session 797 using RTP. As with other measurement, metadata assist in 798 understanding the context under which the data was collected, 799 including the time, observation point [RFC7799], and way in which 800 metrics were accumulated. The RTCP protocol directly reports some 801 of this information in a form that can be directly visible in the 802 network. A user of summary measurement data has to trust the 803 source of this data and the method used to generate the summary 804 information. 806 These metrics can support network operations, inform capacity 807 planning, and assist in determining the demand for equipment and/or 808 configuration changes by network operators. They can also inform 809 Internet engineering activities by informing the development of new 810 protocols, methodologies, and procedures. 812 In some cases, measurements could involve active injection of test 813 traffic to perform a measurement (see Section 3.4 of [RFC7799]). 814 However, most operators do not have access to user equipment, 815 therefore the point of test is normally different from the transport 816 endpoint. Injection of test traffic can incur an additional cost in 817 running such tests (e.g., the implications of capacity tests in a 818 mobile network are obvious). Some active measurements [RFC7799] 819 (e.g., response under load or particular workloads) perturb other 820 traffic, and could require dedicated access to the network segment. 822 Passive measurements (see Section 3.6 of [RFC7799]) can have 823 advantages in terms of eliminating unproductive test traffic, 824 reducing the influence of test traffic on the overall traffic mix, 825 and the ability to choose the point of observation (see 826 Section 3.3.1). Measurements can rely on observing packet headers, 827 which is not possible if those headers are encrypted, but could 828 utilise information about traffic volumes or patterns of interaction 829 to deduce metrics. 831 One alternative approach is to use in-network techniques, which does 832 not require the cooperation of an endpoint (see Section 5). 834 3.2.2. Using Information Derived from Network Layer Header Fields 836 Information from the transport header can be used by a multi-field 837 classifier as a part of policy framework. Policies are commonly used 838 for management of the QoS or Quality of Experience (QoE) in resource- 839 constrained networks, or by firewalls to implement access rules (see 840 also Section 2.2.2 of [RFC8404]). Operators can use such policies to 841 support user applications and to protect against unwanted traffic. 842 Such policies can also be used without user consent, to de-prioritise 843 certain applications or services, for example. 845 Network-layer classification methods that rely on a multi-field 846 classifier (e.g., inferring QoS from the 5-tuple or choice of 847 application protocol) are incompatible with transport protocols that 848 encrypt the transport header information. Traffic that cannot be 849 classified typically receives a default treatment. Some networks 850 block or rate traffic that cannot be classified. 852 Transport layer information can also be explicitly carried in 853 network-layer header fields that are not encrypted, serving as a 854 replacement/addition to the exposed transport header information 855 [RFC8558]. This information can enable a different forwarding 856 treatment by the network, even when a transport employs encryption to 857 protect other header information. 859 The user of a transport that multiplexes multiple sub-flows might 860 want to obscure the presence and characteristics of these sub-flows. 861 On the other hand, an encrypted transport could set the network-layer 862 information to indicate the presence of sub-flows, and to reflect the 863 service requirements of individual sub-flows. There are several ways 864 this could be done: 866 IP Address: Applications normally expose the addresses used by 867 endpoints, and this is used in the forwarding decisions in network 868 devices. Address and other protocol information can be used by a 869 Multi-Field (MF) classifier to determine how traffic is treated 870 [RFC2475], and hence affect the quality of experience for a flow. 872 Using the IPv6 Network-Layer Flow Label: A number of Standards Track 873 and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], 874 [RFC6438]) encourage endpoints to set the IPv6 flow label field of 875 the network-layer header. IPv6 "source nodes SHOULD assign each 876 unrelated transport connection and application data stream to a 877 new flow" [RFC6437]. A multiplexing transport could choose to use 878 multiple flow labels to allow the network to independently forward 879 sub-flows. RFC6437 provides further guidance on choosing a flow 880 label value, stating these "should be chosen such that their bits 881 exhibit a high degree of variability", and chosen so that "third 882 parties should be unlikely to be able to guess the next value that 883 a source of flow labels will choose". 885 Once set, a flow label can provide information that can help 886 inform network-layer queueing and forwarding [RFC6438], for 887 example with Equal Cost Multi-Path routing and Link Aggregation 888 [RFC6294]. Considerations when using IPsec are further described 889 in [RFC6438]. 891 The choice of how to assign a flow label needs to avoid 892 introducing linkability that a network device could observe. 893 Inappropriate use by the transport can have privacy implications 894 (e.g., assigning the same label to two independent flows that 895 ought not to be classified the same). 897 Using the Network-Layer Differentiated Services Code Point: 898 Applications can expose their delivery expectations to the network 899 by setting the Differentiated Services Code Point (DSCP) field of 900 IPv4 and IPv6 packets [RFC2474]. For example, WebRTC applications 901 identify different forwarding treatments for individual sub-flows 902 (audio vs. video) based on the value of the DSCP field 903 [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit information 904 to inform network-layer queueing and forwarding, rather than an 905 operator inferring traffic requirements from transport and 906 application headers via a multi-field classifier. Inappropriate 907 use by the transport can have privacy implications (e.g., 908 assigning a different DSCP to a subflow could assist in a network 909 device discovering the traffic pattern used by an application, 910 assigning the same label to two independent flows that ought not 911 to be classified the same). The field is mutable, i.e., some 912 network devices can be expected to change this field (use of each 913 DSCP value is defined by an RFC). 915 Since the DSCP value can impact the quality of experience for a 916 flow, observations of service performance has to consider this 917 field when a network path supports differentiated service 918 treatment. 920 Using Explicit Congestion Marking: ECN [RFC3168] is a transport 921 mechanism that uses the ECN field in the network-layer header. 922 Use of ECN explicitly informs the network-layer that a transport 923 is ECN-capable, and requests ECN treatment of the flow. An ECN- 924 capable transport can offer benefits when used over a path with 925 equipment that implements an AQM method with CE marking of IP 926 packets [RFC8087], since it can react to congestion without also 927 having to recover from lost packets. 929 ECN exposes the presence of congestion. The reception of CE- 930 marked packets can be used to estimate the level of incipient 931 congestion on the upstream portion of the path from the point of 932 observation (Section 2.5 of [RFC8087]). Interpreting the marking 933 behaviour (i.e., assessing congestion and diagnosing faults) 934 requires context from the transport layer, such as path RTT. 936 AQM and ECN offer a range of algorithms and configuration options. 937 Tools therefore have to be available to network operators and 938 researchers to understand the implication of configuration choices 939 and transport behaviour as the use of ECN increases and new 940 methods emerge [RFC7567]. 942 Network-Layer Options Network protocols can carry optional headers. 943 These can be used to explicitly expose transport header 944 information to on-path devices operating at the network layer (as 945 discussed further in Section 5). 947 IPv4 [RFC0791] has provision for optional header fields identified 948 by an option type field. IP routers can examine these headers and 949 are required to ignore IPv4 options that they does not recognise. 950 Many current paths include network devices that forward packets 951 that carry options on a slower processing path. Some network 952 devices (e.g., firewalls) can be (and are) configured to drop 953 these packets [RFC7126]. BCP 186 [RFC7126] provides Best Current 954 Practice guidance on how operators should treat IPv4 packets that 955 specify options. 957 IPv6 can encode optional network-layer information in separate 958 headers that may be placed between the IPv6 header and the upper- 959 layer header [RFC8200]. The Hop-by-Hop options header, when 960 present, immediately follows the IPv6 header. IPv6 permits this 961 header to be examined by any node along the path. While [RFC7872] 962 required all nodes to examine and process the Hop-by-Hop options 963 header, it is now expected [RFC8200] that nodes along a path only 964 examine and process the Hop-by-Hop options header if explicitly 965 configured to do so. 967 When transport headers cannot be observed, operators are unable to 968 use this information directly. Careful use of the network layer 969 features can help provide similar information in the case where the 970 network is unable to inspect transport protocol headers. Section 6 971 describes use of network extension headers. 973 3.3. To Support Network Operations 975 The common language between network operators and application/content 976 providers/users is packet transfer performance at a layer that all 977 can view and analyse. For most packets, this has been the transport 978 layer, until the emergence of transport protocols performing header 979 encryption, with the obvious exception of VPNs and IPsec. 981 When encryption hides more layers in each packet, people seeking 982 understanding of the network operation rely more on pattern inference 983 and other heuristics. It remains to be seen whether more complex 984 inferences can be mastered to produce the same monitoring accuracy 985 (see Section 2.1.1 of [RFC8404]). 987 When measurement datasets are made available by servers or client 988 endpoints, additional metadata, such as the state of the network, is 989 often necessary to interpret this data to answer questions about 990 network performance or understand a pathology. Collecting and 991 coordinating such metadata is more difficult when the observation 992 point is at a different location to the bottleneck/device under 993 evaluation [RFC7799]. 995 Packet sampling techniques are used to scale the processing involved 996 in observing packets on high rate links. This exports only the 997 packet header information of (randomly) selected packets. The 998 utility of these measurements depends on the type of bearer and 999 number of mechanisms used by network devices. Simple routers are 1000 relatively easy to manage, but a device with more complexity demands 1001 understanding of the choice of many system parameters. This level of 1002 complexity exists when several network methods are combined. 1004 This section discusses topics concerning observation of transport 1005 flows, with a focus on transport measurement. 1007 3.3.1. Problem Location 1009 In network measurements of transport header information can be used 1010 to locate the source of problems, or to assess the performance of a 1011 network segment or a particular device configuration. Often issues 1012 can only be understood in the context of the other flows that share a 1013 particular path, common network device, interface port, etc. A 1014 simple example is monitoring of a network device that uses a 1015 scheduler or active queue management technique [RFC7567], where it 1016 could be desirable to understand whether the algorithms are correctly 1017 controlling latency, or if overload protection is working. This 1018 understanding implies knowledge of how traffic is assigned to any 1019 sub-queues used for flow scheduling, but can also require information 1020 about how the traffic dynamics impact active queue management, 1021 starvation prevention mechanisms, and circuit-breakers. 1023 Sometimes multiple in network observation points have to be used. By 1024 correlating observations of headers at multiple points along the path 1025 (e.g., at the ingress and egress of a network segment), an observer 1026 can determine the contribution of a portion of the path to an 1027 observed metric, to locate a source of delay, jitter, loss, 1028 reordering, congestion marking, etc. 1030 3.3.2. Network Planning and Provisioning 1032 Traffic rate and volume measurements are used by operators to help 1033 plan deployment of new equipment and configuration in their networks. 1034 Data is also valuable to equipment vendors who want to understand 1035 traffic trends and patterns of usage as inputs to decisions about 1036 planning products and provisioning for new deployments. This 1037 measurement information can also be correlated with billing 1038 information when this is also collected by an operator. 1040 Trends in aggregate traffic can be observed and can be related to the 1041 endpoint addresses being used, but when transport header information 1042 is not observable, it might be impossible to correlate patterns in 1043 measurements with changes in transport protocols. This increases the 1044 dependency on other indirect sources of information to inform 1045 planning and provisioning. 1047 3.3.3. Service Performance Measurement 1049 Performance measurements (e.g., throughput, loss, latency) can be 1050 used by various actors to analyse the service offered to the users of 1051 a network segment, and to inform operational practice. 1053 3.3.4. Compliance with Congestion Control 1055 The traffic that can be observed by on-path network devices (the 1056 "wire image") is a function of transport protocol design/options, 1057 network use, applications, and user characteristics. In general, 1058 when only a small proportion of the traffic has a specific 1059 (different) characteristic, such traffic seldom leads to operational 1060 concern, although the ability to measure and monitor it is less. The 1061 desire to understand the traffic and protocol interactions typically 1062 grows as the proportion of traffic increases in volume. The 1063 challenges increase when multiple instances of an evolving protocol 1064 contribute to the traffic that share network capacity. 1066 Operators can manage traffic load (e.g., when the network is severely 1067 overloaded) by deploying rate-limiters, traffic shaping, or network 1068 transport circuit breakers [RFC8084]. The information provided by 1069 observing transport headers is a source of data that can help to 1070 inform such mechanisms. 1072 Congestion Control Compliance of Traffic: Congestion control is a 1073 key transport function [RFC2914]. Many network operators 1074 implicitly accept that TCP traffic complies with a behaviour that 1075 is acceptable for the shared Internet. TCP algorithms have been 1076 continuously improved over decades, and have reached a level of 1077 efficiency and correctness that is difficult to match in custom 1078 application-layer mechanisms [RFC8085]. 1080 A standards-compliant TCP stack provides congestion control that 1081 is judged safe for use across the Internet. Applications 1082 developed on top of well-designed transports can be expected to 1083 appropriately control their network usage, reacting when the 1084 network experiences congestion, by back-off and reduce the load 1085 placed on the network. This is the normal expected behaviour for 1086 IETF-specified transports (e.g., TCP and SCTP). 1088 However, when anomalies are detected, tools can interpret the 1089 transport protocol header information to help understand the 1090 impact of specific transport protocols (or protocol mechanisms) on 1091 the other traffic that shares a network. An observation in the 1092 network can gain an understanding of the dynamics of a flow and 1093 its congestion control behaviour. Analysing observed flows can 1094 help to build confidence that an application flow backs-off its 1095 share of the network load under persistent congestion, and hence 1096 to understand whether the behaviour is appropriate for sharing 1097 limited network capacity. For example, it is common to visualise 1098 plots of TCP sequence numbers versus time for a flow to understand 1099 how a flow shares available capacity, deduce its dynamics in 1100 response to congestion, etc. 1102 The ability to identify sources and flows that contribute to 1103 persistent congestion is important to the safe operation of 1104 network infrastructure, and can inform configuration of network 1105 devices to complement the endpoint congestion avoidance mechanisms 1106 [RFC7567] [RFC8084] to avoid a portion of the network being driven 1107 into congestion collapse [RFC2914]. 1109 Congestion Control Compliance for UDP traffic: UDP provides a 1110 minimal message-passing datagram transport that has no inherent 1111 congestion control mechanisms. Because congestion control is 1112 critical to the stable operation of the Internet, applications and 1113 other protocols that choose to use UDP as a transport have to 1114 employ mechanisms to prevent collapse, avoid unacceptable 1115 contributions to jitter/latency, and to establish an acceptable 1116 share of capacity with concurrent traffic [RFC8085]. 1118 A network operator can observe the headers of transport protocols 1119 layered above UDP to understand if the datagram flows comply with 1120 congestion control expectations. This can help inform a decision 1121 on whether it might be appropriate to deploy methods such as rate- 1122 limiters to enforce acceptable usage. 1124 UDP flows that expose a well-known header can be observed to gain 1125 understanding of the dynamics of a flow and its congestion control 1126 behaviour. For example, tools exist to monitor various aspects of 1127 RTP header information and RTCP reports for real-time flows (see 1128 Section 3.2). The Secure RTP and RTCP extensions [RFC3711] were 1129 explicitly designed to expose some header information to enable 1130 such observation, while protecting the payload data. 1132 3.4. To Support Network Diagnostics and Troubleshooting 1134 Transport header information can be utilised for a variety of 1135 operational tasks [RFC8404]: to diagnose network problems, assess 1136 network provider performance, evaluate equipment or protocol 1137 performance, capacity planning, management of security threats 1138 (including DoS), and responding to user performance questions. 1139 Section 3.1.2 and Section 5 of [RFC8404] provide further examples. 1141 Operators can monitor the health of a portion of the Internet, to 1142 provide early warning and trigger action. Traffic and performance 1143 measurements can assist in setting buffer sizes, debugging and 1144 diagnosing the root causes of faults that concern a particular user's 1145 traffic. They can also be used to support post-mortem investigation 1146 after an anomaly to determine the root cause of a problem. In other 1147 cases, measurement involves dissecting network traffic flows. 1148 Observed transport header information can help identify whether link/ 1149 network tuning is effective and alert to potential problems that can 1150 be hard to derive from link or device measurements alone. 1152 An alternative could rely on access to endpoint diagnostic tools or 1153 user involvement in diagnosing and troubleshooting unusual use cases 1154 or to troubleshoot non-trivial problems. 1156 Another approach is to use traffic pattern analysis. Such tools can 1157 provide useful information during network anomalies (e.g., detecting 1158 significant reordering, high or intermittent loss), however indirect 1159 measurements would need to be carefully designed to provide 1160 information for diagnostics and troubleshooting. 1162 The design trade-offs for radio networks are often very different 1163 from those of wired networks. A radio-based network (e.g., cellular 1164 mobile, enterprise Wireless LAN (WLAN), satellite access/back-haul, 1165 point-to-point radio) has the complexity of a subsystem that performs 1166 radio resource management, with direct impact on the available 1167 capacity, and potentially loss/reordering of packets. The impact of 1168 the pattern of loss and congestion, differs for different traffic 1169 types, correlation with propagation and interference can all have 1170 significant impact on the cost and performance of a provided service. 1171 For radio links, the use for this type of information is expected to 1172 increase as operators bring together heterogeneous types of network 1173 equipment and seek to deploy opportunistic methods to access radio 1174 spectrum. 1176 Lack of tools and resulting information can reduce the ability of an 1177 operator to observe transport performance and could limit the ability 1178 of network operators to trace problems, make appropriate QoS 1179 decisions, or respond to other queries about the network service. 1181 A network operator supporting traffic that uses transport header 1182 encryption is unable to use tools that rely on transport protocol 1183 information. However, the use of encryption has the desirable effect 1184 of preventing unintended observation of the payload data and these 1185 tools seldom seek to observe the payload, or other application 1186 details. A flow that hides its transport header information could 1187 imply "don't touch" to some operators. This might limit a trouble- 1188 shooting response to "can't help, no trouble found". 1190 3.5. To Support Header Compression 1192 Header compression saves link capacity by compressing network and 1193 transport protocol headers on a per-hop basis. It was widely used 1194 with low bandwidth dial-up access links, and still finds application 1195 on wireless links that are subject to capacity constraints. Examples 1196 of header compression include use with TCP/IP and RTP/UDP/IP flows 1197 [RFC2507], [RFC2508], [RFC4995]. 1199 While it is possible to compress only the network layer headers, 1200 significant savings can be made if both the network and transport 1201 layer headers are compressed together as a single unit. The SRTP 1202 extensions [RFC3711] were explicitly designed to leave the transport 1203 protocol headers unencrypted, but authenticated, since support for 1204 header compression was considered important. Encrypting the 1205 transport protocol headers does not break such header compression, 1206 but does cause a fall back to compressing only the network layer 1207 headers, with a significant reduction in efficiency. 1209 4. Encryption and Authentication of Transport Headers 1211 End-to-end encryption can be applied at various protocol layers. It 1212 can be applied above the transport to encrypt the transport payload 1213 (e.g., using TLS). This can hide information from an eavesdropper in 1214 the network. It can also help protect the privacy of a user, by 1215 hiding data relating to user/device identity or location. 1217 4.1. Motivation 1219 There are several motivations for encryption: 1221 o One motive to encrypt transport headers is in response to a 1222 growing awareness of the implications of network ossification from 1223 network devices that inspect transport headers. Once a network 1224 devices observes a transport header and becomes reliant upon using 1225 it, the overall use of that field can become ossified, preventing 1226 new protocols and mechanisms from being deployed. One of the 1227 benefits of encrypting transport headers is that it can help 1228 improve the pace of transport development by eliminating 1229 interference by deployed middleboxes. 1231 o Another motivation stems from increased concerns about privacy and 1232 surveillance. Users value the ability to protect their identity 1233 and location, and defend against analysis of the traffic. 1234 Revelations about the use of pervasive surveillance [RFC7624] 1235 have, to some extent, eroded trust in the service offered by 1236 network operators and have led to an increased use of encryption 1237 to avoid unwanted eavesdropping on communications. Concerns have 1238 also been voiced about the addition of information to packets by 1239 third parties to provide analytics, customisation, advertising, 1240 cross-site tracking of users, to bill the customer, or to 1241 selectively allow or block content. Whatever the reasons, the 1242 IETF is designing protocols that include transport header 1243 encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement 1244 the already widespread payload encryption, and to further limit 1245 exposure of transport metadata to the network. 1247 The use of transport header authentication and encryption exposes a 1248 tussle between middlebox vendors, operators, applications developers 1249 and users: 1251 o On the one hand, future Internet protocols that support transport 1252 header encryption assist in the restoration of the end-to-end 1253 nature of the Internet by returning complex processing to the 1254 endpoints, since middleboxes cannot modify what they cannot see, 1255 and can improve privacy by reducing leakage of transport metadata. 1257 o On the other hand, encryption of transport layer information has 1258 implications for people who are responsible for operating 1259 networks, and researchers and analysts seeking to understand the 1260 dynamics of protocols and traffic patterns. 1262 A decision to use transport header encryption can improve user 1263 privacy, and can reduce protocol ossification and help the evolution 1264 of the transport protocol stack, but is also has implications for 1265 network operations and management. 1267 4.2. Approaches to Transport Header Protection 1269 The following briefly reviews some security design options for 1270 transport protocols. A Survey of Transport Security Protocols 1271 [I-D.ietf-taps-transport-security] provides more details concerning 1272 commonly used encryption methods at the transport layer. 1274 Authenticating the Transport Protocol Header: Transport layer header 1275 information can be authenticated. An integrity check that 1276 protects the immutable transport header fields, but can still 1277 expose the transport protocol header information in the clear, 1278 allows in-network devices to observe these fields. An integrity 1279 check is not able to prevent in-network modification, but can 1280 prevent a receiving from accepting changes and avoid impact on the 1281 transport protocol operation. 1283 An example transport authentication mechanism is TCP- 1284 Authentication (TCP-AO) [RFC5925]. This TCP option authenticates 1285 the IP pseudo header, TCP header, and TCP data. TCP-AO protects 1286 the transport layer, preventing attacks from disabling the TCP 1287 connection itself and provides replay protection. Such 1288 authentication might interact with middleboxes, depending on their 1289 behaviour [RFC3234]. 1291 The IPsec Authentication Header (AH) [RFC4302] was designed to 1292 work at the network layer and authenticate the IP payload. This 1293 approach authenticates all transport headers, and verifies their 1294 integrity at the receiver, preventing in-network modification. 1295 The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also 1296 provide authentication and integrity without confidentiality using 1297 the NULL encryption algorithm [RFC2410]. SRTP [RFC3711] is 1298 another example of a transport protocol that allows header 1299 authentication. 1301 Selectively Encrypting Transport Headers and Payload: A transport 1302 protocol design can encrypt selected header fields, while also 1303 choosing to authenticate the entire transport header. This allows 1304 specific transport header fields to be made observable by network 1305 devices (explicitly exposed either in a transport header field or 1306 lower layer protocol header). A design that only exposes 1307 immutable fields can also perform end-to-end authentication of 1308 these fields across the path to prevent undetected modification of 1309 the immutable transport headers. 1311 Mutable fields in the transport header provide opportunities where 1312 network devices can modify the transport behaviour (e.g., the 1313 extended headers described in [I-D.trammell-plus-abstract-mech]). 1315 An example of a method that encrypts some, but not all, transport 1316 header information is GRE-in-UDP [RFC8086] when used with GRE 1317 encryption. 1319 Optional Encryption of Header Information: There are implications to 1320 the use of optional header encryption in the design of a transport 1321 protocol, where support of optional mechanisms can increase the 1322 complexity of the protocol and its implementation, and in the 1323 management decisions that are have to be made to use variable 1324 format fields. Instead, fields of a specific type ought to always 1325 be sent with the same level of confidentiality or integrity 1326 protection. 1328 Greasing: Protocols often provide extensibility features, reserving 1329 fields or values for use by future versions of a specification. 1330 The specification of receivers has traditionally ignored 1331 unspecified values, however in-network devices have emerged that 1332 ossify to require a certain value in a field, or re-use a field 1333 for another purpose. When the specification is later updated, it 1334 is impossible to deploy the new use of the field, and forwarding 1335 of the protocol could even become conditional on a specific header 1336 field value. 1338 A protocol can intentionally vary the value, format, and/or 1339 presence of observable transport header fields. This behaviour, 1340 known as GREASE (Generate Random Extensions And Sustain 1341 Extensibility) is designed to avoid a network device ossifying the 1342 use of a specific observable field. Greasing seeks to ease 1343 deployment of new methods. This seeks to prevent in-network 1344 devices utilising the information in a transport header, or can 1345 make an observation robust to a set of changing values, rather 1346 than a specific set of values. It is not a security mechanism, 1347 although use can be combined with an authentication mechanism. 1349 As seen, different transports use encryption to protect their header 1350 information to varying degrees. The trend is towards increased 1351 protection. 1353 5. Addition of Transport OAM Information to Network-Layer Headers 1355 An on-path device can make measurements by utilising additional 1356 protocol headers carrying operations, administration and management 1357 (OAM) information in an additional packet header. Using network- 1358 layer approaches to reveal information has the potential that the 1359 same method (and hence same observation and analysis tools) can be 1360 consistently used by multiple transport protocols. This approach 1361 also could be applied to methods beyond OAM (see Section 6). There 1362 can also be less desirable implications from separating the operation 1363 of the transport protocol from the measurement framework. 1365 5.1. Use of OAM within a Maintenance Domain 1367 OAM information can be added at the ingress to a maintenance domain 1368 (e.g., an Ethernet protocol header with timestamps and sequence 1369 number information using a method such as 802.11ag or in-situ OAM 1370 [I-D.ietf-ippm-ioam-data], or as a part of encapsulation protocol). 1371 The additional header information is typically removed the at the 1372 egress of the maintenance domain. 1374 Although some types of measurements are supported, this approach does 1375 not cover the entire range of measurements described in this 1376 document. In some cases, it can be difficult to position measurement 1377 tools at the appropriate segments/nodes and there can be challenges 1378 in correlating the downstream/upstream information when in-band OAM 1379 data is inserted by an on-path device. 1381 5.2. Use of OAM across Multiple Maintenance Domains 1383 OAM information can also be added at the network layer as an IPv6 1384 extension header or an IPv4 option. This information can be used 1385 across multiple network segments, or between the transport endpoints. 1387 One example is the IPv6 Performance and Diagnostic Metrics (PDM) 1388 destination option [RFC8250]. This allows a sender to optionally 1389 include a destination option that caries header fields that can be 1390 used to observe timestamps and packet sequence numbers. This 1391 information could be authenticated by receiving transport endpoints 1392 when the information is added at the sender and visible at the 1393 receiving endpoint, although methods to do this have not currently 1394 been proposed. This method has to be explicitly enabled at the 1395 sender. 1397 6. Intentionally Exposing Transport Information to the Network 1399 A transport protocol can choose to expose certain transport 1400 information to on-path devices operating at the network layer by 1401 sending observable fields. One approach is to make an explicit 1402 choice not to encrypt certain transport header fields, making this 1403 transport information observable by the network. Another approach is 1404 to choose to expose transport information through the use of network- 1405 layer extension headers. Both are examples of explicit information 1406 intended to be used by network devices on the path [RFC8558]. 1408 Whatever the mechanism used to expose the information, a decision to 1409 only expose specific transport information, places the transport 1410 endpoint in control of what to expose or not to expose outside of the 1411 encrypted transport header. This decision can then be made 1412 independently of the transport protocol functionality. This can be 1413 done by exposing part of the transport header or as a network layer 1414 option/extension. 1416 6.1. Exposing Transport Information in Extension Headers 1418 At the network-layer, packets can carry optional headers (similar to 1419 Section 5) that may be used to explicitly expose transport header 1420 information to the on-path devices operating at the network layer 1421 (Section 3.2.2). For example, an endpoint that sends an IPv6 Hop-by- 1422 Hop option [RFC8200] can provide explicit transport layer information 1423 that can be observed and used by network devices on the path. 1425 Network-layer optional headers explicitly indicate the information 1426 that is exposed, whereas use of exposed transport header information 1427 first requires an observer to identify the transport protocol and its 1428 format. See Section 3.1 for further discussion of transport protocol 1429 identification. 1431 An arbitrary path can include one or more network devices that drop 1432 packets that include a specific header or option used for this 1433 purpose (see [RFC7872]). This could impact the proper functioning of 1434 the protocols using the path. Protocol methods can be designed to 1435 probe to discover whether the specific option(s) can be used along 1436 the current path, enabling use on arbitrary paths. 1438 6.2. Common Exposed Transport Information 1440 There are opportunities for multiple transport protocols to 1441 consistently supply common observable information [RFC8558]. A 1442 common approach can result in an open definition of the observable 1443 fields. This has the potential that the same information can be 1444 utilised across a range of operational and analysis tools. 1446 6.3. Considerations for Exposing Transport Information 1448 The motivation to reflect actual transport header information and the 1449 implications of network devices using this information has to be 1450 considered when proposing such a method. RFC8558 summarises this as 1451 "When signals from endpoints to the path are independent from the 1452 signals used by endpoints to manage the flow's state mechanics, they 1453 may be falsified by an endpoint without affecting the peer's 1454 understanding of the flow's state. For encrypted flows, this 1455 divergence is not detectable by on-path devices." [RFC8558]. 1457 Considerations concerning the selection of appropriate information to 1458 expose include: 1460 o On the one hand, explicitly exposing derived fields containing 1461 relevant transport information (e.g., metrics for loss, latency, 1462 etc) can avoid network devices needing to derive this information 1463 from other header fields. This could result in development and 1464 evolution of transport-independent tools around a common 1465 observable header, and permit transport protocols to also evolve 1466 independently of this ossified header [RFC8558]. 1468 o On the other hand, protocols and implementations may not 1469 consistently expose external information that reflects the actual 1470 internal information used by the protocol itself. An endpoint/ 1471 protocol could choose to expose transport header information to 1472 optimise the benefit it gets from the network [RFC8558]. The 1473 value of this information would be enhanced if the exposed 1474 information could be verified to match the protocol's observed 1475 behavior. 1477 7. Implications of Protecting the Transport Headers 1479 The choice of which transport header fields to expose and which to 1480 encrypt is a design decision for the transport protocol. Selective 1481 encryption requires trading conflicting goals of observability and 1482 network support, privacy, and risk of ossification, to decide what 1483 header fields to protect and which to make visible. 1485 Security work typically employs a design technique that seeks to 1486 expose only what is needed. This approach provides incentives to not 1487 reveal any information that is not necessary for the end-to-end 1488 communication. However, there can be performance and operational 1489 benefits in exposing selected information to network tools. 1491 This section explores key implications of working with encrypted 1492 transport protocols. 1494 7.1. Independent Measurement 1496 Independent observation by multiple actors is important if the 1497 transport community is to maintain an accurate understanding of the 1498 network. Encrypting transport header encryption changes the ability 1499 to collect and independently analyse data. Internet transport 1500 protocols employ a set of mechanisms. Some of these have to work in 1501 cooperation with the network layer for loss detection and recovery, 1502 congestion detection and control. Others have to work only end-to- 1503 end (e.g., parameter negotiation, flow-control). 1505 The majority of present Internet applications use two well-known 1506 transport protocols, TCP and UDP. Although TCP represents the 1507 majority of current traffic, many real-time applications use UDP, and 1508 much of this traffic uses RTP format headers in the payload of the 1509 UDP datagram. Since these protocol headers have been fixed for 1510 decades, a range of tools and analysis methods have became common and 1511 well-understood. 1513 Protocols that expose the state information used by the transport 1514 protocol in their header information (e.g., timestamps used to 1515 calculate the RTT, packet numbers used to asses congestion and 1516 requests for retransmission) provide an incentive for the sending 1517 endpoint to provide correct information, since the protocol will not 1518 work otherwise. This increases confidence that the observer 1519 understands the transport interaction with the network. For example, 1520 when TCP is used over an unencrypted network path (i.e., one that 1521 does not use IPsec or other encryption below the transport), it 1522 implicitly exposes transport header information that can be used for 1523 measurement at any point along the path. This information is 1524 necessary for the protocol's correct operation, therefore there is no 1525 incentive for a TCP or RTP implementation to put incorrect 1526 information in this transport header. A network device can have 1527 confidence that the well-known (and ossified) transport header 1528 information represents the actual state of the endpoints. 1530 When encryption is used to hide some or all of the transport headers, 1531 the transport protocol chooses which information to reveal to the 1532 network about its internal state, what information to leave 1533 encrypted, and what fields to grease to protect against future 1534 ossification. Such a transport could be designed (or an existing 1535 transport modified), for example, to provide summary data regarding 1536 its performance, congestion control state, etc., or to make available 1537 explicit measurement information. For example, a QUIC endpoint can 1538 optionally set the spin bit to reflect to explicitly reveal the RTT 1539 of an encrypted transport session to the on-path network devices 1540 [I-D.ietf-quic-transport]). 1542 When providing or using such information, it is important to consider 1543 the privacy of the user and their incentive for providing accurate 1544 and detailed information. Protocols that selectively reveal some 1545 transport state or measurable information are choosing to establish a 1546 trust relationship with the network operators. There is no protocol 1547 mechanism that can guarantee that the information provided represents 1548 the actual transport state of the endpoints, since those endpoints 1549 can always send additional information in the encrypted part of the 1550 header, to update or replace whatever they reveal. This reduces the 1551 ability to independently measure and verify that a protocol is 1552 behaving as expected. For some operational uses, the information has 1553 to contain sufficient detail to understand, and possibly reconstruct, 1554 the network traffic pattern for further testing. In this case, 1555 operators have to gain the trust of transport protocol implementers 1556 if the transport headers are to correctly reveal such information. 1558 OAM data records [I-D.ietf-ippm-ioam-data] could be embedded into a 1559 variety of encapsulation methods at different layers to support the 1560 goals of a specific operational domain. OAM-related metadata can 1561 support functions such as performance evaluation, path-tracing, path 1562 verification information, classification and a diversity of other 1563 uses. When encryption is used to hide some or all of the transport 1564 headers, analysis requires coordination between actors at different 1565 layers to successfully characterise flows and correlate the 1566 performance or behaviour of a specific mechanism with the 1567 configuration and traffic using operational equipment (e.g., 1568 combining transport and network measurements to explore congestion 1569 control dynamics, the implications of designs for active queue 1570 management or circuit breakers). 1572 Some measurements could be completed by utilising endpoint-based 1573 logging (e.g., based on Quic-Trace [Quic-Trace]). Such information 1574 has a diversity of uses, including developers wishing to debug/ 1575 understand the transport/application protocols with which they work, 1576 researchers seeking to spot trends and anomalies, and to characterise 1577 variants of protocols. A standard format for endpoint logging could 1578 allow these to be shared (after appropriate anonymisation) to 1579 understand performance and pathologies. Measurements based on 1580 logging have to establish the validity and provenance of the logged 1581 information to establish how and when traces were captured. 1583 Despite being applicable in some scenarios, endpoint logs do not 1584 provide equivalent information to in-network measurements. In 1585 particular, endpoint logs contain only a part of the information to 1586 understand the operation of network devices and identify issues such 1587 as link performance or capacity sharing between multiple flows. 1588 Additional information has to be combined to determine which 1589 equipment/links are used and the configuration of equipment along the 1590 network paths being measured. 1592 7.2. Characterising "Unknown" Network Traffic 1594 The patterns and types of traffic that share Internet capacity change 1595 over time as networked applications, usage patterns and protocols 1596 continue to evolve. 1598 If "unknown" or "uncharacterised" traffic patterns form a small part 1599 of the traffic aggregate passing through a network device or segment 1600 of the network the path, the dynamics of the uncharacterised traffic 1601 might not have a significant collateral impact on the performance of 1602 other traffic that shares this network segment. Once the proportion 1603 of this traffic increases, monitoring the traffic can determine if 1604 appropriate safety measures have to be put in place. 1606 Tracking the impact of new mechanisms and protocols requires traffic 1607 volume to be measured and new transport behaviours to be identified. 1608 This is especially true of protocols operating over a UDP substrate. 1609 The level and style of encryption has to be considered in determining 1610 how this activity is performed. On a shorter timescale, information 1611 could also have to be collected to manage DoS attacks against the 1612 infrastructure. 1614 7.3. Accountability and Internet Transport Protocols 1616 Information provided by tools observing transport headers can be used 1617 to classify traffic, and to limit the network capacity used by 1618 certain flows, as discussed in Section 3.3.4). Equally, operators 1619 could use analysis of transport headers and transport flow state to 1620 demonstrate that they are not providing differential treatment to 1621 certain flows. Obfuscating or hiding this information using 1622 encryption could lead operators and maintainers of middleboxes 1623 (firewalls, etc.) to seek other methods to classify, and potentially 1624 other mechanisms to condition, network traffic. 1626 A lack of data that reduces the level of precision with which flows 1627 can be classified also reduces the design space for conditioning 1628 mechanisms (e.g., rate limiting, circuit breaker techniques 1629 [RFC8084], or blocking of uncharacterised traffic), and this has to 1630 be considered when evaluating the impact of designs for transport 1631 encryption [RFC5218]. 1633 7.4. Impact on Network Operations 1635 Some network operators currently use observed transport header 1636 information as a part of their operational practice, and have 1637 developed tools and techniques that use information observed in 1638 currently deployed transports and their applications. A variety of 1639 open source and proprietary tools have been deployed that use this 1640 information for a variety of short and long term measurements. 1641 Encryption of the transport header information prevents tooling from 1642 directly observing the transport header information, limiting its 1643 utility. 1645 Alternative diagnostic and troubleshooting tools would have to be 1646 developed and deployed is transport header encryption is widely 1647 deployed. Introducing a new protocol or application might then 1648 require these tool chains and practises to be updated, and could in 1649 turn impact operational mechanisms, and policies. Each change can 1650 introduce associated costs, including the cost of collecting data, 1651 and the tooling to handle multiple formats (possibly as these co- 1652 exist in the network, when measurements span time periods during 1653 which changes are deployed, or to compare with historical data). 1654 These costs are incurred by an operator to manage the service and 1655 debug network issues. 1657 At the time of writing, the overall operational impact of using 1658 encrypted transports is not yet well understood. Design trade-offs 1659 could mitigate these costs by explicitly choosing to expose selected 1660 information (e.g., header invariants and the spin-bit in QUIC 1661 [I-D.ietf-quic-transport]), the specification of common log formats, 1662 and development of alternative approaches. 1664 7.5. Impact on Research, Development and Deployment 1666 Transport protocol evolution, and the ability to measure and 1667 understand the impact of protocol changes, have to proceed hand-in- 1668 hand. A transport protocol that provides observable headers can be 1669 used to provide open and verifiable measurement data. Observation of 1670 pathologies has a critical role in the design of transport protocol 1671 mechanisms and development of new mechanisms and protocols. This 1672 helps understanding the interactions between cooperating protocols 1673 and network mechanism, the implications of sharing capacity with 1674 other traffic and the impact of different patterns of usage. The 1675 ability of other stake holders to review transport header traces 1676 helps develop insight into performance and traffic contribution of 1677 specific variants of a protocol. 1679 Development of new transport protocol mechanisms has to consider the 1680 scale of deployment and the range of environments in which the 1681 transport is used. Experience has shown that it is often difficult 1682 to correctly implement new mechanisms [RFC8085], and that mechanisms 1683 often evolve as a protocol matures, or in response to changes in 1684 network conditions, changes in network traffic, or changes to 1685 application usage. Analysis is especially valuable when based on the 1686 behaviour experienced across a range of topologies, vendor equipment, 1687 and traffic patterns. 1689 New transport protocol formats are expected to facilitate an 1690 increased pace of transport evolution, and with it the possibility to 1691 experiment with and deploy a wide range of protocol mechanisms. 1692 There has been recent interest in a wide range of new transport 1693 methods, e.g., Larger Initial Window, Proportional Rate Reduction 1694 (PRR), congestion control methods based on measuring bottleneck 1695 bandwidth and round-trip propagation time, the introduction of AQM 1696 techniques and new forms of ECN response (e.g., Data Centre TCP, 1697 DCTP, and methods proposed for L4S). The growth and diversity of 1698 applications and protocols using the Internet also continues to 1699 expand. For each new method or application it is desirable to build 1700 a body of data reflecting its behaviour under a wide range of 1701 deployment scenarios, traffic load, and interactions with other 1702 deployed/candidate methods. 1704 Encryption of transport header information could reduce the range of 1705 actors that can observe useful data. This would limit the 1706 information sources available to the Internet community to understand 1707 the operation of new transport protocols, reducing information to 1708 inform design decisions and standardisation of the new protocols and 1709 related operational practises. The cooperating dependence of 1710 network, application, and host to provide communication performance 1711 on the Internet is uncertain when only endpoints (i.e., at user 1712 devices and within service platforms) can observe performance, and 1713 when performance cannot be independently verified by all parties. 1715 Independently observed data is also important to ensure the health of 1716 the research and development communities and can help promote 1717 acceptance of proposed specifications by the wider community (e.g., 1718 as a method to judge the safety for Internet deployment) and provides 1719 valuable input during standardisation. Open standards motivate a 1720 desire to include independent observation and evaluation of 1721 performance data, which in turn demands control/understanding about 1722 where and when measurement samples are collected. This requires 1723 consideration of the methods used to observe data and the appropriate 1724 balance between encrypting all and no transport header information. 1726 8. Conclusions 1728 Header encryption and strong integrity checks are being incorporated 1729 into new transport protocols and have important benefits. The pace 1730 of development of transports using the WebRTC data channel, and the 1731 rapid deployment of the QUIC transport protocol, can both be 1732 attributed to using the combination of UDP as a substrate while 1733 providing confidentiality and authentication of the encapsulated 1734 transport headers and payload. 1736 This document has described some current practises, and the 1737 implications for some stake holders, when transport layer header 1738 encryption is used. It does not judge whether these practises are 1739 necessary, or endorse the use of any specific practise. Rather, the 1740 intent is to highlight operational tools and practises to consider 1741 when designing and modifying transport protocols, so protocol 1742 designers can make informed choice about what transport header fields 1743 to encrypt, and whether it might be beneficial to make an explicit 1744 choice to expose certain fields to the network. In making such a 1745 decision, it is important to balance: 1747 o User Privacy: The less transport header information that is 1748 exposed to the network, the lower the risk of leaking metadata 1749 that might have privacy implications for the users. Transports 1750 that chose to expose some header fields need to make a privacy 1751 assessment to understand the privacy cost versus benefit trade-off 1752 in making that information available. The process used to define 1753 and expose the QUIC spin bit to the network is an example of such 1754 an analysis. 1756 o Protocol Ossification: Unencrypted transport header fields are 1757 likely to ossify rapidly, as network devices come to rely on their 1758 presence, making it difficult to change the transport in future. 1759 This argues that the choice to expose information to the network 1760 is made deliberately and with care, since it is essentially 1761 defining a stable interface between the transport and the network. 1762 Some protocols will want to make that interface as limited as 1763 possible; other protocols might find value in exposing certain 1764 information to signal to the network, or in allowing the network 1765 to change certain header fields as signals to the transport. The 1766 visible wire image of a protocol should be explicitly designed. 1768 o Impact on Operational Practice: The network operations community 1769 has long relied on being able to understand Internet traffic 1770 patterns, both in aggregate and at the flow level, to support 1771 network management, traffic engineering, and troubleshooting. 1772 Operational practice has developed based on the information 1773 available from unencrypted transport headers. The IETF has 1774 supported this practice by developing operations and management 1775 specifications, interface specifications, and associated Best 1776 Current Practises. Widespread deployment of transport protocols 1777 that encrypt their information might impact network operations, 1778 unless operators can develop alternative practises that work 1779 without access to the transport header. 1781 o Pace of Evolution: Removing obstacles to change can enable an 1782 increased pace of evolution. If a protocol changes its transport 1783 header format (wire image) or their transport behaviour, this can 1784 result in the currently deployed tools and methods becoming no 1785 longer relevant. Where this needs to be accompanied by 1786 development of appropriate operational support functions and 1787 procedures, it can incur a cost in new tooling to catch-up with 1788 each change. Protocols that consistently expose observable data 1789 do not require such development, but can suffer from ossification 1790 and need to consider if the exposed protocol metadata has privacy 1791 implications, There is no single deployment context, and therefore 1792 designers need to consider the diversity of operational networks 1793 (ISPs, enterprises, Distributed DoS (DDoS) mitigation and firewall 1794 maintainers, etc.). 1796 o Supporting Common Specifications: Common, open, specifications can 1797 stimulate engagement by developers, users, researchers, and the 1798 broader community. Increased protocol diversity can be beneficial 1799 in meeting new requirements, but the ability to innovate without 1800 public scrutiny risks point solutions that optimise for specific 1801 cases, but that can accidentally disrupt operations of/in 1802 different parts of the network. The social contract that 1803 maintains the stability of the Internet relies on accepting common 1804 interworking specifications, and on it being possible to detect 1805 violations. It is important to find new ways of maintaining that 1806 community trust as increased use of transport header encryption 1807 limits visibility into transport behaviour. 1809 o Impact on Benchmarking and Understanding Feature Interactions: An 1810 appropriate vantage point for observation, coupled with timing 1811 information about traffic flows, provides a valuable tool for 1812 benchmarking network devices, endpoint stacks, functions, and/or 1813 configurations. This can also help with understanding complex 1814 feature interactions. An inability to observe transport header 1815 information can make it harder to diagnose and explore 1816 interactions between features at different protocol layers, a 1817 side-effect of not allowing a choice of vantage point from which 1818 this information is observed. New approaches might have to be 1819 developed. 1821 o Impact on Research and Development: Hiding transport header 1822 information can impede independent research into new mechanisms, 1823 measurement of behaviour, and development initiatives. Experience 1824 shows that transport protocols are complicated to design and 1825 complex to deploy, and that individual mechanisms have to be 1826 evaluated while considering other mechanisms, across a broad range 1827 of network topologies and with attention to the impact on traffic 1828 sharing the capacity. If increased use of transport header 1829 encryption results in reduced availability of open data, it could 1830 eliminate the independent self-checks to the standardisation 1831 process that have previously been in place from research and 1832 academic contributors (e.g., the role of the IRTF Internet 1833 Congestion Control Research Group (ICCRG) and research 1834 publications in reviewing new transport mechanisms and assessing 1835 the impact of their deployment). 1837 Observable transport header information might be useful to various 1838 stake holders. Other sets of stake holders have incentives to limit 1839 what can be observed. This document does not make recommendations 1840 about what information ought to be exposed, to whom it ought to be 1841 observable, or how this will be achieved. There are also design 1842 choices about where observable fields are placed. For example, one 1843 location could be a part of the transport header outside of the 1844 encryption envelope, another alternative is to carry the information 1845 in a network-layer option or extension header. New transport 1846 protocol designs ought to explicitly identify any fields that are 1847 intended to be observed, consider if there are alternative ways of 1848 providing the information, and reflect on the implications of 1849 observable fields being used by network devices, and how this might 1850 impact user privacy and protocol evolution when these fields become 1851 ossified. 1853 As [RFC7258] notes, "Making networks unmanageable to mitigate 1854 (pervasive monitoring) is not an acceptable outcome, but ignoring 1855 (pervasive monitoring) would go against the consensus documented 1856 here." Providing explicit information can help avoid traffic being 1857 inappropriately classified, impacting application performance. An 1858 appropriate balance will emerge over time as real instances of this 1859 tension are analysed [RFC7258]. This balance between information 1860 exposed and information hidden ought to be carefully considered when 1861 specifying new transport protocols. 1863 9. Security Considerations 1865 This document is about design and deployment considerations for 1866 transport protocols. Issues relating to security are discussed 1867 throughout this document. 1869 Authentication, confidentiality protection, and integrity protection 1870 are identified as Transport Features by [RFC8095]. As currently 1871 deployed in the Internet, these features are generally provided by a 1872 protocol or layer on top of the transport protocol 1873 [I-D.ietf-taps-transport-security]. 1875 Confidentiality and strong integrity checks have properties that can 1876 also be incorporated into the design of a transport protocol or to 1877 modify an existing transport. Integrity checks can protect an 1878 endpoint from undetected modification of protocol fields by network 1879 devices, whereas encryption and obfuscation or greasing can further 1880 prevent these headers being utilised by network devices. Preventing 1881 observation of headers provides an opportunity for greater freedom to 1882 update the protocols and can ease experimentation with new techniques 1883 and their final deployment in endpoints. A protocol specification 1884 needs to weigh the costs of ossifying common headers, versus the 1885 potential benefits of exposing specific information that could be 1886 observed along the network path to provide tools to manage new 1887 variants of protocols. 1889 Header encryption can provide confidentiality of some or all of the 1890 transport header information. This prevents an on-path device from 1891 knowledge of the header field. It therefore prevents mechanisms 1892 being built that directly rely on the information or seeks to infer 1893 semantics of an exposed header field. Reduces visibility into 1894 transport metadata can limit the ability to measure and characterise 1895 traffic. It can also provide privacy benefits in some cases. 1897 Extending the transport payload security context to also include the 1898 transport protocol header protects both information with the same 1899 key. A privacy concern would arise if this key was shared with a 1900 third party, e.g., providing access to transport header information 1901 to debug a performance issue, would also result in exposing the 1902 transport payload data to the same third party. Such risks would be 1903 mitigated using a layered security design that provides one domain of 1904 protection and associated keys for the transport payload and 1905 encrypted transport headers; and a separate domain of protection and 1906 associated keys for any observable transport header fields. 1908 Exposed transport headers are sometimes utilised as a part of the 1909 information to detect anomalies in network traffic. "While PM is an 1910 attack, other forms of monitoring that might fit the definition of PM 1911 can be beneficial and not part of any attack, e.g., network 1912 management functions monitor packets or flows and anti-spam 1913 mechanisms need to see mail message content." [RFC7258]. This can 1914 be used as the first line of defence to identify potential threats 1915 from DoS or malware and redirect suspect traffic to dedicated nodes 1916 responsible for DoS analysis, malware detection, or to perform packet 1917 "scrubbing" (the normalisation of packets so that there are no 1918 ambiguities in interpretation by the ultimate destination of the 1919 packet). These techniques are currently used by some operators to 1920 also defend from distributed DoS attacks. 1922 Exposed transport header fields can also form a part of the 1923 information used by the receiver of a transport protocol to protect 1924 the transport layer from data injection by an attacker. In 1925 evaluating this use of exposed header information, it is important to 1926 consider whether it introduces a significant DoS threat. For 1927 example, an attacker could construct a DoS attack by sending packets 1928 with a sequence number that falls within the currently accepted range 1929 of sequence numbers at the receiving endpoint, this would then 1930 introduce additional work at the receiving endpoint, even though the 1931 data in the attacking packet might not finally be delivered by the 1932 transport layer. This is sometimes known as a "shadowing attack". 1933 An attack can, for example, disrupt receiver processing, trigger loss 1934 and retransmission, or make a receiving endpoint perform unproductive 1935 decryption of packets that cannot be successfully decrypted (forcing 1936 a receiver to commit decryption resources, or to update and then 1937 restore protocol state). 1939 One mitigation to off-path attack is to deny knowledge of what header 1940 information is accepted by a receiver or obfuscate the accepted 1941 header information, e.g., setting a non-predictable initial value for 1942 a sequence number during a protocol handshake, as in [RFC3550] and 1943 [RFC6056], or a port value that cannot be predicted (see Section 5.1 1944 of [RFC8085]). A receiver could also require additional information 1945 to be used as a part of a validation check before accepting packets 1946 at the transport layer (e.g., utilising a part of the sequence number 1947 space that is encrypted; or by verifying an encrypted token not 1948 visible to an attacker). This would also mitigate against on-path 1949 attacks. An additional processing cost can be incurred when 1950 decryption has to be attempted before a receiver is able to discard 1951 injected packets. 1953 Open standards motivate a desire for this evaluation to include 1954 independent observation and evaluation of performance data, which in 1955 turn suggests control over where and when measurement samples are 1956 collected. This requires consideration of the appropriate balance 1957 between encrypting all and no transport header information. Open 1958 data, and accessibility to tools that can help understand trends in 1959 application deployment, network traffic and usage patterns can all 1960 contribute to understanding security challenges. 1962 The Security and Privacy Considerations in the Framework for Large- 1963 Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain 1964 considerations for Active and Passive measurement techniques and 1965 supporting material on measurement context. 1967 Addition of observable transport information to the path increases 1968 the information available to an observer and may, when this 1969 information can be linked to a node or user, reduce the privacy of 1970 the user. See the security considerations of [RFC8558]. 1972 10. IANA Considerations 1974 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1976 This memo includes no request to IANA. 1978 11. Acknowledgements 1980 The authors would like to thank Mohamed Boucadair, Spencer Dawkins, 1981 Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen 1982 Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris 1983 Wood, Thomas Fossati, Mohamed Boucadair, Martin Thomson, David Black, 1984 and other members of TSVWG for their comments and feedback. 1986 This work has received funding from the European Union's Horizon 2020 1987 research and innovation programme under grant agreement No 688421, 1988 and the EU Stand ICT Call 4. The opinions expressed and arguments 1989 employed reflect only the authors' view. The European Commission is 1990 not responsible for any use that might be made of that information. 1992 This work has received funding from the UK Engineering and Physical 1993 Sciences Research Council under grant EP/R04144X/1. 1995 12. Informative References 1997 [bufferbloat] 1998 Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in 1999 the Internet. Communications of the ACM, 55(1):57-65", 2000 January 2012. 2002 [I-D.ietf-ippm-ioam-data] 2003 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 2004 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 2005 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 2006 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 2007 data-06 (work in progress), July 2019. 2009 [I-D.ietf-quic-transport] 2010 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 2011 and Secure Transport", draft-ietf-quic-transport-22 (work 2012 in progress), July 2019. 2014 [I-D.ietf-rtcweb-overview] 2015 Alvestrand, H., "Overview: Real Time Protocols for 2016 Browser-based Applications", draft-ietf-rtcweb-overview-19 2017 (work in progress), November 2017. 2019 [I-D.ietf-taps-transport-security] 2020 Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. 2021 Rose, "A Survey of Transport Security Protocols", draft- 2022 ietf-taps-transport-security-08 (work in progress), August 2023 2019. 2025 [I-D.ietf-tls-dtls13] 2026 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2027 Datagram Transport Layer Security (DTLS) Protocol Version 2028 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 2029 2020. 2031 [I-D.ietf-tsvwg-rtcweb-qos] 2032 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 2033 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 2034 qos-18 (work in progress), August 2016. 2036 [I-D.trammell-plus-abstract-mech] 2037 Trammell, B., "Abstract Mechanisms for a Cooperative Path 2038 Layer under Endpoint Control", draft-trammell-plus- 2039 abstract-mech-00 (work in progress), September 2016. 2041 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 2042 Techniques and Their Merits, IEEE Comm. Surveys & 2043 Tutorials. 26;18(3) p2149-2196", November 2014. 2045 [Measurement] 2046 Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- 2047 based Protocol Design, Eur. Conf. on Networks and 2048 Communications, Oulu, Finland.", June 2017. 2050 [PAM-RTT] Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 2051 Implications of Two-Way Internet Latency Data (in Proc. 2052 PAM 2018)", March 2018. 2054 [Quic-Trace] 2055 "https:QUIC trace utilities //github.com/google/quic- 2056 trace". 2058 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2059 DOI 10.17487/RFC0791, September 1981, 2060 . 2062 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2063 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 2064 November 1998, . 2066 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2067 "Definition of the Differentiated Services Field (DS 2068 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2069 DOI 10.17487/RFC2474, December 1998, 2070 . 2072 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2073 and W. Weiss, "An Architecture for Differentiated 2074 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2075 . 2077 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 2078 Compression", RFC 2507, DOI 10.17487/RFC2507, February 2079 1999, . 2081 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 2082 Headers for Low-Speed Serial Links", RFC 2508, 2083 DOI 10.17487/RFC2508, February 1999, 2084 . 2086 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2087 RFC 2914, DOI 10.17487/RFC2914, September 2000, 2088 . 2090 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 2091 Shelby, "Performance Enhancing Proxies Intended to 2092 Mitigate Link-Related Degradations", RFC 3135, 2093 DOI 10.17487/RFC3135, June 2001, 2094 . 2096 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2097 of Explicit Congestion Notification (ECN) to IP", 2098 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2099 . 2101 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 2102 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 2103 . 2105 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2106 A., Peterson, J., Sparks, R., Handley, M., and E. 2107 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2108 DOI 10.17487/RFC3261, June 2002, 2109 . 2111 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2112 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2113 DOI 10.17487/RFC3393, November 2002, 2114 . 2116 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 2117 Sooriyabandara, "TCP Performance Implications of Network 2118 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 2119 December 2002, . 2121 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2122 Jacobson, "RTP: A Transport Protocol for Real-Time 2123 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2124 July 2003, . 2126 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2127 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2128 RFC 3711, DOI 10.17487/RFC3711, March 2004, 2129 . 2131 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2132 DOI 10.17487/RFC4302, December 2005, 2133 . 2135 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2136 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2137 . 2139 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2140 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2141 July 2006, . 2143 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2144 "Extended RTP Profile for Real-time Transport Control 2145 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2146 DOI 10.17487/RFC4585, July 2006, 2147 . 2149 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2150 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2151 DOI 10.17487/RFC4737, November 2006, 2152 . 2154 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 2155 Header Compression (ROHC) Framework", RFC 4995, 2156 DOI 10.17487/RFC4995, July 2007, 2157 . 2159 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 2160 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 2161 . 2163 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 2164 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 2165 DOI 10.17487/RFC5236, June 2008, 2166 . 2168 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 2169 RFC 5426, DOI 10.17487/RFC5426, March 2009, 2170 . 2172 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 2173 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 2174 March 2009, . 2176 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2177 Header Compression (ROHC) Framework", RFC 5795, 2178 DOI 10.17487/RFC5795, March 2010, 2179 . 2181 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2182 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2183 June 2010, . 2185 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2186 Protocol Port Randomization", BCP 156, RFC 6056, 2187 DOI 10.17487/RFC6056, January 2011, 2188 . 2190 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2191 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2192 DOI 10.17487/RFC6269, June 2011, 2193 . 2195 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 2196 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 2197 2011, . 2199 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2200 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2201 January 2012, . 2203 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2204 "IPv6 Flow Label Specification", RFC 6437, 2205 DOI 10.17487/RFC6437, November 2011, 2206 . 2208 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2209 for Equal Cost Multipath Routing and Link Aggregation in 2210 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2211 . 2213 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2214 Morris, J., Hansen, M., and R. Smith, "Privacy 2215 Considerations for Internet Protocols", RFC 6973, 2216 DOI 10.17487/RFC6973, July 2013, 2217 . 2219 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 2220 on Filtering of IPv4 Packets Containing IPv4 Options", 2221 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 2222 . 2224 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2225 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2226 2014, . 2228 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2229 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2230 . 2232 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 2233 Recommendations Regarding Active Queue Management", 2234 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 2235 . 2237 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 2238 Aitken, P., and A. Akhter, "A Framework for Large-Scale 2239 Measurement of Broadband Performance (LMAP)", RFC 7594, 2240 DOI 10.17487/RFC7594, September 2015, 2241 . 2243 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 2244 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 2245 August 2015, . 2247 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2248 Trammell, B., Huitema, C., and D. Borkmann, 2249 "Confidentiality in the Face of Pervasive Surveillance: A 2250 Threat Model and Problem Statement", RFC 7624, 2251 DOI 10.17487/RFC7624, August 2015, 2252 . 2254 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 2255 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 2256 May 2016, . 2258 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2259 "Observations on the Dropping of Packets with IPv6 2260 Extension Headers in the Real World", RFC 7872, 2261 DOI 10.17487/RFC7872, June 2016, 2262 . 2264 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 2265 D. Ros, "Characterization Guidelines for Active Queue 2266 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 2267 2016, . 2269 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 2270 Updates for Secure Real-time Transport Protocol (SRTP) 2271 Extension for Datagram Transport Layer Security (DTLS)", 2272 RFC 7983, DOI 10.17487/RFC7983, September 2016, 2273 . 2275 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 2276 "Proportional Integral Controller Enhanced (PIE): A 2277 Lightweight Control Scheme to Address the Bufferbloat 2278 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 2279 . 2281 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2282 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2283 . 2285 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2286 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2287 March 2017, . 2289 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2290 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2291 March 2017, . 2293 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 2294 Explicit Congestion Notification (ECN)", RFC 8087, 2295 DOI 10.17487/RFC8087, March 2017, 2296 . 2298 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 2299 Ed., "Services Provided by IETF Transport Protocols and 2300 Congestion Control Mechanisms", RFC 8095, 2301 DOI 10.17487/RFC8095, March 2017, 2302 . 2304 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2305 (IPv6) Specification", STD 86, RFC 8200, 2306 DOI 10.17487/RFC8200, July 2017, 2307 . 2309 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 2310 Performance and Diagnostic Metrics (PDM) Destination 2311 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 2312 . 2314 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 2315 Iyengar, Ed., "Controlled Delay Active Queue Management", 2316 RFC 8289, DOI 10.17487/RFC8289, January 2018, 2317 . 2319 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 2320 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 2321 and Active Queue Management Algorithm", RFC 8290, 2322 DOI 10.17487/RFC8290, January 2018, 2323 . 2325 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 2326 Pervasive Encryption on Operators", RFC 8404, 2327 DOI 10.17487/RFC8404, July 2018, 2328 . 2330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2332 . 2334 [RFC8462] Rooney, N. and S. Dawkins, Ed., "Report from the IAB 2335 Workshop on Managing Radio Networks in an Encrypted World 2336 (MaRNEW)", RFC 8462, DOI 10.17487/RFC8462, October 2018, 2337 . 2339 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 2340 Jacquenet, "An Inventory of Transport-Centric Functions 2341 Provided by Middleboxes: An Operator Perspective", 2342 RFC 8517, DOI 10.17487/RFC8517, February 2019, 2343 . 2345 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 2346 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2347 2019, . 2349 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 2350 Q., and E. Smith, "Cryptographic Protection of TCP Streams 2351 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 2352 . 2354 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 2355 RFC 8558, DOI 10.17487/RFC8558, April 2019, 2356 . 2358 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 2359 Paasch, "TCP Extensions for Multipath Operation with 2360 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2361 2020, . 2363 Appendix A. Revision information 2365 -00 This is an individual draft for the IETF community. 2367 -01 This draft was a result of walking away from the text for a few 2368 days and then reorganising the content. 2370 -02 This draft fixes textual errors. 2372 -03 This draft follows feedback from people reading this draft. 2374 -04 This adds an additional contributor and includes significant 2375 reworking to ready this for review by the wider IETF community Colin 2376 Perkins joined the author list. 2378 Comments from the community are welcome on the text and 2379 recommendations. 2381 -05 Corrections received and helpful inputs from Mohamed Boucadair. 2383 -06 Updated following comments from Stephen Farrell, and feedback via 2384 email. Added a draft conclusion section to sketch some strawman 2385 scenarios that could emerge. 2387 -07 Updated following comments from Al Morton, Chris Seal, and other 2388 feedback via email. 2390 -08 Updated to address comments sent to the TSVWG mailing list by 2391 Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 2392 11/05/2018, and Spencer Dawkins. 2394 -09 Updated security considerations. 2396 -10 Updated references, split the Introduction, and added a paragraph 2397 giving some examples of why ossification has been an issue. 2399 -01 This resolved some reference issues. Updated section on 2400 observation by devices on the path. 2402 -02 Comments received from Kyle Rose, Spencer Dawkins and Tom 2403 Herbert. The network-layer information has also been re-organised 2404 after comments at IETF-103. 2406 -03 Added a section on header compression and rewriting of sections 2407 referring to RTP transport. This version contains author editorial 2408 work and removed duplicate section. 2410 -04 Revised following SecDir Review 2411 o Added some text on TLS story (additional input sought on relevant 2412 considerations). 2414 o Section 2, paragraph 8 - changed to be clearer, in particular, 2415 added "Encryption with secure key distribution prevents" 2417 o Flow label description rewritten based on PS/BCP RFCs. 2419 o Clarify requirements from RFCs concerning the IPv6 flow label and 2420 highlight ways it can be used with encryption. (section 3.1.3) 2422 o Add text on the explicit spin-bit work in the QUIC DT. Added 2423 greasing of spin-bit. (Section 6.1) 2425 o Updated section 6 and added more explanation of impact on 2426 operators. 2428 o Other comments addressed. 2430 -05 Editorial pass and minor corrections noted on TSVWG list. 2432 -06 Updated conclusions and minor corrections. Responded to request 2433 to add OAM discussion to Section 6.1. 2435 -07 Addressed feedback from Ruediger and Thomas. 2437 Section 2 deserved some work to make it easier to read and avoid 2438 repetition. This edit finally gets to this, and eliminates some 2439 duplication. This also moves some of the material from section 2 to 2440 reform a clearer conclusion. The scope remains focussed on the usage 2441 of transport headers and the implications of encryption - not on 2442 proposals for new techniques/specifications to be developed. 2444 -08 Addressed feedback and completed editorial work, including 2445 updating the text referring to RFC7872, in preparation for a WGLC. 2447 -09 Updated following WGLC. In particular, thanks to Joe Touch 2448 (specific comments and commentary on style and tone); Dimitri Tikonov 2449 (editorial); Christian Huitema (various); David Black (various). 2450 Amended privacy considerations based on SECDIR review. Emile Stephan 2451 (inputs on operations measurement); Various others. 2453 Added summary text and refs to key sections. Note to editors: The 2454 section numbers are hard-linked. 2456 -10 Updated following additional feedback from 1st WGLC. Comments 2457 from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter 2458 Gutmann; Ekr; and many others via the TSVWG list. Some people 2459 thought that "needed" and "need" could represent requirements in the 2460 document, etc. this has been clarified. 2462 -11 Updated following additional feedback from Martin Thomson, and 2463 corrections from other reviewers. 2465 -12 Updated following additional feedback from reviewers. 2467 -13 Updated following 2nd WGLC with comments from D.L.Black; T. 2468 Herbert; Ekr; and other reviewers. 2470 -14 Update to resolve feedback to rev -13. This moves the general 2471 discussion of adding fields to transport packets to section 6, and 2472 discusses with reference to material in RFC8558. 2474 -15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins 2475 and M. Duke. Update to add reference to RFC7605. Clarify a focus 2476 on immutable transport fields, rather than modifying middleboxes with 2477 Tom H. Clarified Header Compression discusion only provides a list 2478 of examples of HC methods for transport. Clarified port usage with 2479 Tom H/Joe T. Removed some duplicated sentences, and minor edits. 2480 Added NULL-ESP. Improved after initial feedback from Martin Duke. 2482 -16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3. 2484 Authors' Addresses 2486 Godred Fairhurst 2487 University of Aberdeen 2488 Department of Engineering 2489 Fraser Noble Building 2490 Aberdeen AB24 3UE 2491 Scotland 2493 EMail: gorry@erg.abdn.ac.uk 2494 URI: http://www.erg.abdn.ac.uk/ 2496 Colin Perkins 2497 University of Glasgow 2498 School of Computing Science 2499 Glasgow G12 8QQ 2500 Scotland 2502 EMail: csp@csperkins.org 2503 URI: https://csperkins.org/