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