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