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