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