idnits 2.17.1 draft-ietf-tsvwg-transport-encrypt-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 493: '... IPv6 "source nodes SHOULD assign each...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2021) is 1104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-00 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-03) exists of draft-marx-qlog-main-schema-02 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C. Perkins 5 Expires: October 20, 2021 University of Glasgow 6 April 18, 2021 8 Considerations around Transport Header Confidentiality, Network 9 Operations, and the Evolution of Internet Transport Protocols 10 draft-ietf-tsvwg-transport-encrypt-21 12 Abstract 14 To protect user data and privacy, Internet transport protocols have 15 supported payload encryption and authentication for some time. Such 16 encryption and authentication is now also starting to be applied to 17 the transport protocol headers. This helps avoid transport protocol 18 ossification by middleboxes, mitigate attacks against the transport 19 protocol, and protect metadata about the communication. Current 20 operational practice in some networks inspect transport header 21 information within the network, but this is no longer possible when 22 those transport headers are encrypted. 24 This document discusses the possible impact when network traffic uses 25 a protocol with an encrypted transport header. It suggests issues to 26 consider when designing new transport protocols or features. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 20, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Current uses of Transport Headers within the Network . . . . 4 64 2.1. To Separate Flows in Network Devices . . . . . . . . . . 5 65 2.2. To Identify Transport Protocols and Flows . . . . . . . . 5 66 2.3. To Understand Transport Protocol Performance . . . . . . 6 67 2.4. To Support Network Operations . . . . . . . . . . . . . . 13 68 2.5. To Mitigate the Effects of Constrained Networks . . . . . 18 69 2.6. To Verify SLA Compliance . . . . . . . . . . . . . . . . 19 70 3. Research, Development and Deployment . . . . . . . . . . . . 20 71 3.1. Independent Measurement . . . . . . . . . . . . . . . . . 20 72 3.2. Measurable Transport Protocols . . . . . . . . . . . . . 21 73 3.3. Other Sources of Information . . . . . . . . . . . . . . 22 74 4. Encryption and Authentication of Transport Headers . . . . . 23 75 5. Intentionally Exposing Transport Information to the Network . 28 76 5.1. Exposing Transport Information in Extension Headers . . . 28 77 5.2. Common Exposed Transport Information . . . . . . . . . . 29 78 5.3. Considerations for Exposing Transport Information . . . . 29 79 6. Addition of Transport OAM Information to Network-Layer 80 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 6.1. Use of OAM within a Maintenance Domain . . . . . . . . . 30 82 6.2. Use of OAM across Multiple Maintenance Domains . . . . . 30 83 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 87 11. Informative References . . . . . . . . . . . . . . . . . . . 36 88 Appendix A. Revision information . . . . . . . . . . . . . . . . 46 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 91 1. Introduction 93 The transport layer supports the end-to-end flow of data across a 94 network path, providing features such as connection establishment, 95 reliability, framing, ordering, congestion control, flow control, 96 etc., as needed to support applications. One of the core functions 97 of an Internet transport is to discover and adapt to the 98 characteristics of the network path that is currently being used. 100 For some years, it has been common for the transport layer payload to 101 be protected by encryption and authentication, but for the transport 102 layer headers to be sent unprotected. Examples of protocols that 103 behave in this manner include Transport Layer Security (TLS) over TCP 104 [RFC8446], Datagram TLS [RFC6347] [I-D.ietf-tls-dtls13], the Secure 105 Real-time Transport Protocol [RFC3711], and tcpcrypt [RFC8548]. The 106 use of unencrypted transport headers has led some network operators, 107 researchers, and others to develop tools and processes that rely on 108 observations of transport headers both in aggregate and at the flow 109 level to infer details of the network's behaviour and inform 110 operational practice. 112 Transport protocols are now being developed that encrypt some or all 113 of the transport headers, in addition to the transport payload data. 114 The QUIC transport protocol [I-D.ietf-quic-transport] is an example 115 of such a protocol. Such transport header encryption makes it 116 difficult to observe transport protocol behaviour from the vantage 117 point of the network. This document discusses some implications of 118 transport header encryption for network operators and researchers 119 that have previously observed transport headers, and highlights some 120 issues to consider for transport protocol designers. 122 As discussed in [RFC7258], the IETF has concluded that Pervasive 123 Monitoring (PM) is a technical attack that needs to be mitigated in 124 the design of IETF protocols. This document supports that 125 conclusion. It also recognises that RFC7258 states "Making networks 126 unmanageable to mitigate PM is not an acceptable outcome, but 127 ignoring PM would go against the consensus documented here. An 128 appropriate balance will emerge over time as real instances of this 129 tension are considered". This document is written to provide input 130 to the discussion around what is an appropriate balance, by 131 highlighting some implications of transport header encryption. 133 Current uses of transport header information by network devices on 134 the Internet path are explained. These uses can be beneficial or 135 malicious. This is written to provide input to the discussion around 136 what is an appropriate balance, by highlighting some implications of 137 transport header encryption. 139 2. Current uses of Transport Headers within the Network 141 In response to pervasive monitoring [RFC7624] revelations and the 142 IETF consensus that "Pervasive Monitoring is an Attack" [RFC7258], 143 efforts are underway to increase encryption of Internet traffic. 144 Applying confidentiality to transport header fields can improve 145 privacy, and can help to mitigate certain attacks or manipulation of 146 packets by devices on the network path, but it can also affect 147 network operations and measurement [RFC8404]. 149 When considering what parts of the transport headers should be 150 encrypted to provide confidentiality, and what parts should be 151 visible to network devices (including non-encrypted but authenticated 152 headers), it is necessary to consider both the impact on network 153 operations and management, and the implications for ossification and 154 user privacy [Measurement]. Different parties will view the relative 155 importance of these concerns differently. For some, the benefits of 156 encrypting all the transport headers outweigh the impact of doing so; 157 others might analyse the security, privacy, and ossification impacts 158 and arrive at a different trade-off. 160 This section reviews examples of the observation of transport layer 161 headers within the network by devices on the network path, or using 162 information exported by an on-path device. Unencrypted transport 163 headers provide information that can support network operations and 164 management, and this section notes some ways in which this has been 165 done. Unencrypted transport header information also contributes 166 metadata that can be exploited for purposes unrelated to network 167 transport measurement, diagnostics or troubleshooting (e.g., to block 168 or to throttle traffic from a specific content provider), and this 169 section also notes some threats relating to unencrypted transport 170 headers. 172 Exposed transport information also provides a source of information 173 that contributes to linked data sets, which could be exploited to 174 deduce private information, e.g., user patterns, user location, 175 tracking behaviour, etc. This might reveal information the parties 176 did not intend to be revealed. [RFC6973] aims to make designers, 177 implementers, and users of Internet protocols aware of privacy- 178 related design choices in IETF protocols. 180 This section does not consider intentional modification of transport 181 headers by middleboxes, such as devices performing Network Address 182 Translation (NAT) or Firewalls. 184 2.1. To Separate Flows in Network Devices 186 Some network layer mechanisms separate network traffic by flow, 187 without resorting to identifying the type of traffic. Hash-based 188 load-sharing sharing across paths (e..g., equal cost multi path, 189 ECMP), sharing across a group of links (e.g., using a link 190 aggregation group, LAG), ensuring equal access to link capacity 191 (e.g., fair queuing, FQ), or distributing traffic to servers (e.g., 192 load balancing). To prevent packet reordering, forwarding engines 193 can consistently forward the same transport flows along the same 194 forwarding path, often achieved by calculating a hash using an 195 n-tuple gleaned from a combination of link header information through 196 to transport header information. This n-tuple can use the MAC 197 address, IP addresses, and can include observable transport header 198 information. 200 When transport header information cannot be observed, there can be 201 less information to separate flows at equipment along the path. Flow 202 separation might not be possible when, a transport that forms traffic 203 into an encrypted aggregate. For IPv6, the Flow Label [RFC6437] can 204 be used even when all transport information is encrypted, enabling 205 Flow Label-based ECMP [RFC6438] and Load-Sharing [RFC7098]. 207 2.2. To Identify Transport Protocols and Flows 209 Information in exposed transport layer headers can be used by the 210 network to identify transport protocols and flows [RFC8558]. The 211 ability to identify transport protocols, flows, and sessions is a 212 common function performed, for example, by measurement activities, 213 Quality of Service (QoS) classifiers, and firewalls. These functions 214 can be beneficial, and performed with the consent of, and in support 215 of, the end user. Alternatively, the same mechanisms could be used 216 to support practises that might be adversarial to the end user, 217 including blocking, de-prioritising, and monitoring traffic without 218 consent. 220 Observable transport header information, together with information in 221 the network header, has been used to identify flows and their 222 connection state, together with the set of protocol options being 223 used. Transport protocols, such as TCP [RFC7414] and the Stream 224 Control Transport Protocol (SCTP) [RFC4960], specify a standard base 225 header that includes sequence number information and other data. 226 They also have the possibility to negotiate additional headers at 227 connection setup, identified by an option number in the transport 228 header. 230 In some uses, an assigned transport port (e.g., 0..49151) can 231 identify the upper-layer protocol or service [RFC7605]. However, 232 port information alone is not sufficient to guarantee identification. 233 Applications can use arbitrary ports and do not need to use assigned 234 port numbers. The use of an assigned port number is also not limited 235 to the protocol for which the port is intended. Multiple sessions 236 can also be multiplexed on a single port, and ports can be re-used by 237 subsequent sessions. 239 Some flows can be identified by observing signalling data (e.g., 240 [RFC3261], [RFC8837]) or through the use of magic numbers placed in 241 the first byte(s) of a datagram payload [RFC7983]. 243 When transport header information cannot be observed, this removes 244 information that could have been used to classify flows by passive 245 observers along the path. More ambitious ways could be used to 246 collect, estimate, or infer flow information, including heuristics 247 based on the analysis of traffic patterns, such as classification of 248 flows relying on timing, volumes of information, and correlation 249 between multiple flows. For example, an operator that cannot access 250 the Session Description Protocol (SDP) session descriptions [RFC4566] 251 to classify a flow as audio traffic, might instead use (possibly 252 less-reliable) heuristics to infer that short UDP packets with 253 regular spacing carry audio traffic. Operational practises aimed at 254 inferring transport parameters are out of scope for this document, 255 and are only mentioned here to recognise that encryption does not 256 prevent operators from attempting to apply practises that were used 257 with unencrypted transport headers. 259 The IAB [RFC8546] have provided a summary of expected implications of 260 increased encryption on network functions that use the observable 261 headers and describe the expected benefits of designs that explicitly 262 declare protocol invariant header information that can be used for 263 this purpose. 265 2.3. To Understand Transport Protocol Performance 267 This subsection describes use by the network of exposed transport 268 layer headers to understand transport protocol performance and 269 behaviour. 271 2.3.1. Using Information Derived from Transport Layer Headers 273 Observable transport headers enable explicit measurement and analysis 274 of protocol performance, and detection of network anomalies at any 275 point along the Internet path. Some operators use passive monitoring 276 to manage their portion of the Internet by characterising the 277 performance of link/network segments. Inferences from transport 278 headers are used to derive performance metrics: 280 Traffic Rate and Volume: Per-application traffic rate and volume 281 measures can be used to characterise the traffic that uses a 282 network segment or the pattern of network usage. Observing the 283 protocol sequence number and packet size offers one way to measure 284 this (e.g., measurements observing counters in periodic reports 285 such as RTCP; or measurements observing protocol sequence numbers 286 in statistical samples of packet flows, or specific control 287 packets, such as those observed at the start and end of a flow). 289 Measurements can be per endpoint, or for an endpoint aggregate. 290 These could be used to assess usage or for subscriber billing. 292 Such measurements can be used to trigger traffic shaping, and to 293 associate QoS support within the network and lower layers. This 294 can be done with consent and in support of an end user, to improve 295 quality of service; or could be used by the network to de- 296 prioritise certain flows without user consent. 298 The traffic rate and volume can be determined providing that the 299 packets belonging to individual flows can be identified, but there 300 might be no additional information about a flow when the transport 301 headers cannot be observed. 303 Loss Rate and Loss Pattern: Flow loss rate can be derived (e.g., 304 from transport sequence numbers or inferred from observing 305 transport protocol interactions) and has been used as a metric for 306 performance assessment and to characterise transport behaviour. 307 Network operators have used the variation in patterns to detect 308 changes in the offered service. Understanding the location and 309 root cause of loss can help an operator determine whether this 310 requires corrective action. 312 There are various causes of loss, including: corruption of link 313 frames (e.g., due to interference on a radio link), buffering loss 314 (e.g., overflow due to congestion, Active Queue Management, AQM 315 [RFC7567], or inadequate provision following traffic pre-emption), 316 and policing (traffic management [RFC2475]). Understanding flow 317 loss rates requires maintaining per-flow state (flow 318 identification often requires transport layer information) and 319 either observing the increase in sequence numbers in the network 320 or transport headers, or comparing a per-flow packet counter with 321 the number of packets that the flow actually sent. Per-hop loss 322 can also sometimes be monitored at the interface level by devices 323 on the network path, or using in-situ methods operating over a 324 network segment (see Section 3.3). 326 The pattern of loss can provide insight into the cause of loss. 327 Losses can often occur as bursts, randomly-timed events, etc. It 328 can also be valuable to understand the conditions under which loss 329 occurs. This usually requires relating loss to the traffic 330 flowing at a network node or segment at the time of loss. 331 Transport header information can help identify cases where loss 332 could have been wrongly identified, or where the transport did not 333 require retransmission of a lost packet. 335 Throughput and Goodput: Throughput is the amount of payload data 336 sent by a flow per time interval. Goodput (the subset of 337 throughput consisting of useful traffic) (see Section 2.5 of 338 [RFC7928] and [RFC5166]) is a measure of useful data exchanged. 339 The throughput of a flow can be determined in the absence of 340 transport header information, providing that the individual flow 341 can be identified, and the overhead known. Goodput requires 342 ability to differentiate loss and retransmission of packets, for 343 example by observing packet sequence numbers in the TCP or RTP 344 headers [RFC3550]. 346 Latency: Latency is a key performance metric that impacts 347 application and user-perceived response times. It often 348 indirectly impacts throughput and flow completion time. This 349 determines the reaction time of the transport protocol itself, 350 impacting flow setup, congestion control, loss recovery, and other 351 transport mechanisms. The observed latency can have many 352 components [Latency]. Of these, unnecessary/unwanted queueing in 353 buffers of the network devices on the path has often been observed 354 as a significant factor [bufferbloat]. Once the cause of unwanted 355 latency has been identified, this can often be eliminated. 357 To measure latency across a part of a path, an observation point 358 [RFC7799] can measure the experienced round trip time (RTT) using 359 packet sequence numbers and acknowledgements, or by observing 360 header timestamp information. Such information allows an 361 observation point on the network path to determine not only the 362 path RTT, but also allows measurement of the upstream and 363 downstream contribution to the RTT. This could be used to locate 364 a source of latency, e.g., by observing cases where the median RTT 365 is much greater than the minimum RTT for a part of a path. 367 The service offered by network operators can benefit from latency 368 information to understand the impact of configuration changes and 369 to tune deployed services. Latency metrics are key to evaluating 370 and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit 371 Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements 372 could identify excessively large buffers, indicating where to 373 deploy or configure AQM. An AQM method is often deployed in 374 combination with other techniques, such as scheduling [RFC7567] 375 [RFC8290] and although parameter-less methods are desired 377 [RFC7567], current methods often require tuning [RFC8290] 378 [RFC8289] [RFC8033] because they cannot scale across all possible 379 deployment scenarios. 381 Latency and round-trip time information can potentially expose 382 some information useful for approximate geolocation, as discussed 383 in [PAM-RTT]. 385 Variation in delay: Some network applications are sensitive to 386 (small) changes in packet timing (jitter). Short and long-term 387 delay variation can impact on the latency of a flow and hence the 388 perceived quality of applications using a network path. For 389 example, jitter metrics are often cited when characterising paths 390 supporting real-time traffic. The expected performance of such 391 applications, can be inferred from a measure of the variation in 392 delay observed along a portion of the path [RFC3393] [RFC5481]. 393 The requirements resemble those for the measurement of latency. 395 Flow Reordering: Significant packet reordering within a flow can 396 impact time-critical applications and can be interpreted as loss 397 by reliable transports. Many transport protocol techniques are 398 impacted by reordering (e.g., triggering TCP retransmission or re- 399 buffering of real-time applications). Packet reordering can occur 400 for many reasons, from equipment design to misconfiguration of 401 forwarding rules. Flow identification is often required to avoid 402 significant packet mis-ordering (e.g., when using ECMP, or LAG). 403 Network tools can detect and measure unwanted/excessive 404 reordering, and the impact on transport performance. 406 There have been initiatives in the IETF transport area to reduce 407 the impact of reordering within a transport flow, possibly leading 408 to a reduction in the requirements for preserving ordering. These 409 have potential to simplify network equipment design as well as the 410 potential to improve robustness of the transport service. 411 Measurements of reordering can help understand the present level 412 of reordering, and inform decisions about how to progress new 413 mechanisms. 415 Techniques for measuring reordering typically observe packet 416 sequence numbers. Metrics have been defined that evaluate whether 417 a network path has maintained packet order on a packet-by-packet 418 basis [RFC4737] [RFC5236]. Some protocols provide in-built 419 monitoring and reporting functions. Transport fields in the RTP 420 header [RFC3550] [RFC4585] can be observed to derive traffic 421 volume measurements and provide information on the progress and 422 quality of a session using RTP. Metadata assists in understanding 423 the context under which the data was collected, including the 424 time, observation point [RFC7799], and way in which metrics were 425 accumulated. The RTCP protocol directly reports some of this 426 information in a form that can be directly visible by devices on 427 the network path. 429 In some cases, measurements could involve active injection of test 430 traffic to perform a measurement (see Section 3.4 of [RFC7799]). 431 However, most operators do not have access to user equipment, 432 therefore the point of test is normally different from the transport 433 endpoint. Injection of test traffic can incur an additional cost in 434 running such tests (e.g., the implications of capacity tests in a 435 mobile network segment are obvious). Some active measurements 436 [RFC7799] (e.g., response under load or particular workloads) perturb 437 other traffic, and could require dedicated access to the network 438 segment. 440 Passive measurements (see Section 3.6 of [RFC7799]) can have 441 advantages in terms of eliminating unproductive test traffic, 442 reducing the influence of test traffic on the overall traffic mix, 443 and the ability to choose the point of observation (see 444 Section 2.4.1). Measurements can rely on observing packet headers, 445 which is not possible if those headers are encrypted, but could 446 utilise information about traffic volumes or patterns of interaction 447 to deduce metrics. 449 Passive packet sampling techniques are also often used to scale the 450 processing involved in observing packets on high rate links. This 451 exports only the packet header information of (randomly) selected 452 packets. Interpretation of the exported information relies on 453 understanding of the header information. The utility of these 454 measurements depends on the type of network segment/link and number 455 of mechanisms used by the network devices. Simple routers are 456 relatively easy to manage, but a device with more complexity demands 457 understanding of the choice of many system parameters. 459 2.3.2. Using Information Derived from Network Layer Header Fields 461 Information from the transport header can be used by a multi-field 462 (MF) classifier as a part of policy framework. Policies are commonly 463 used for management of the QoS or Quality of Experience (QoE) in 464 resource-constrained networks, or by firewalls to implement access 465 rules (see also Section 2.2.2 of [RFC8404]). Policies can support 466 user applications/services or protect against unwanted, or lower 467 priority traffic (Section 2.4.4). 469 Transport layer information can also be explicitly carried in 470 network-layer header fields that are not encrypted, serving as a 471 replacement/addition to the exposed transport header information 472 [RFC8558]. This information can enable a different forwarding 473 treatment by the devices forming the network path, even when a 474 transport employs encryption to protect other header information. 476 On the one hand, the user of a transport that multiplexes multiple 477 sub-flows might want to obscure the presence and characteristics of 478 these sub-flows. On the other hand, an encrypted transport could set 479 the network-layer information to indicate the presence of sub-flows, 480 and to reflect the service requirements of individual sub-flows. 481 There are several ways this could be done: 483 IP Address: Applications normally expose the endpoint addresses used 484 in the forwarding decisions in network devices. Address and other 485 protocol information can be used by a MF-classifier to determine 486 how traffic is treated [RFC2475], and hence affect the quality of 487 experience for a flow. Common issues concerning IP address 488 sharing are described in [RFC6269]. 490 Using the IPv6 Network-Layer Flow Label: A number of Standards Track 491 and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], 492 [RFC6438]) encourage endpoints to set the IPv6 flow label field of 493 the network-layer header. IPv6 "source nodes SHOULD assign each 494 unrelated transport connection and application data stream to a 495 new flow" [RFC6437]. A multiplexing transport could choose to use 496 multiple flow labels to allow the network to independently forward 497 sub-flows. RFC6437 provides further guidance on choosing a flow 498 label value, stating these "should be chosen such that their bits 499 exhibit a high degree of variability", and chosen so that "third 500 parties should be unlikely to be able to guess the next value that 501 a source of flow labels will choose". 503 Once set, a flow label can provide information that can help 504 inform network-layer queueing and forwarding, including use with 505 IPsec, [RFC6294] and use with Equal Cost Multi-Path routing and 506 Link Aggregation[RFC6438]. 508 The choice of how to assign a flow label needs to avoid 509 introducing linkages between flows that a network device could not 510 otherwise observe. Inappropriate use by the transport can have 511 privacy implications (e.g., assigning the same label to two 512 independent flows that ought not to be classified the same). 514 Using the Network-Layer Differentiated Services Code Point: 515 Applications can expose their delivery expectations to network 516 devices by setting the Differentiated Services Code Point (DSCP) 517 field of IPv4 and IPv6 packets [RFC2474]. For example, WebRTC 518 applications identify different forwarding treatments for 519 individual sub-flows (audio vs. video) based on the value of the 520 DSCP field [I-D.ietf-tsvwg-rtcweb-qos]). This provides explicit 521 information to inform network-layer queueing and forwarding, 522 rather than an operator inferring traffic requirements from 523 transport and application headers via a multi-field classifier. 524 Inappropriate use by the transport can have privacy implications 525 (e.g., assigning a different DSCP to a subflow could assist in a 526 network device discovering the traffic pattern used by an 527 application). The field is mutable, i.e., some network devices 528 can be expected to change this field. Since the DSCP value can 529 impact the quality of experience for a flow, observations of 530 service performance have to consider this field when a network 531 path supports differentiated service treatment. 533 Using Explicit Congestion Marking: ECN [RFC3168] is a transport 534 mechanism that uses the ECN field in the network-layer header. 535 Use of ECN explicitly informs the network-layer that a transport 536 is ECN-capable, and requests ECN treatment of the flow. An ECN- 537 capable transport can offer benefits when used over a path with 538 equipment that implements an AQM method with CE marking of IP 539 packets [RFC8087], since it can react to congestion without also 540 having to recover from lost packets. 542 ECN exposes the presence of congestion. The reception of CE- 543 marked packets can be used to estimate the level of incipient 544 congestion on the upstream portion of the path from the point of 545 observation (Section 2.5 of [RFC8087]). Interpreting the marking 546 behaviour (i.e., assessing congestion and diagnosing faults) 547 requires context from the transport layer, such as path RTT. 549 AQM and ECN offer a range of algorithms and configuration options. 550 Tools therefore have to be available to network operators and 551 researchers to understand the implication of configuration choices 552 and transport behaviour as the use of ECN increases and new 553 methods emerge [RFC7567]. 555 Network-Layer Options Network protocols can carry optional headers 556 (see Section 5.1). These can explicitly expose transport header 557 information to on-path devices operating at the network layer (as 558 discussed further in Section 6). 560 IPv4 [RFC0791] has provision for optional header fields. IP 561 routers can examine these headers and are required to ignore IPv4 562 options that they do not recognise. Many current paths include 563 network devices that forward packets that carry options on a 564 slower processing path. Some network devices (e.g., firewalls) 565 can be (and are) configured to drop these packets [RFC7126]. BCP 566 186 [RFC7126] provides Best Current Practice guidance on how 567 operators should treat IPv4 packets that specify options. 569 IPv6 can encode optional network-layer information in separate 570 headers that may be placed between the IPv6 header and the upper- 571 layer header [RFC8200]. (e.g., the IPv6 Alternate Marking Method 572 [I-D.ietf-6man-ipv6-alt-mark], which can be used to measure packet 573 loss and delay metrics). The Hop-by-Hop options header, when 574 present, immediately follows the IPv6 header. IPv6 permits this 575 header to be examined by any node along the path if explicitly 576 configured [RFC8200]. 578 Careful use of the network layer features (e.g., Extension Headers 579 can Section 5) help provide similar information in the case where the 580 network is unable to inspect transport protocol headers. 582 2.4. To Support Network Operations 584 Some network operators make use of on-path observations of transport 585 headers to analyse the service offered to the users of a network 586 segment, and to inform operational practice, and can help detect and 587 locate network problems. [RFC8517] gives an operator's perspective 588 about such use. 590 When observable transport header information is not available, those 591 seeking an understanding of transport behaviour and dynamics might 592 learn to work without that information. Alternatively, they might 593 use more limited measurements combined with pattern inference and 594 other heuristics to infer network behaviour (see Section 2.1.1 of 595 [RFC8404]). Operational practises aimed at inferring transport 596 parameters are out of scope for this document, and are only mentioned 597 here to recognise that encryption does not necessarily stop operators 598 from attempting to apply practises that have been used with 599 unencrypted transport headers. 601 This section discusses topics concerning observation of transport 602 flows, with a focus on transport measurement. 604 2.4.1. Problem Location 606 Observations of transport header information can be used to locate 607 the source of problems or to assess the performance of a network 608 segment. Often issues can only be understood in the context of the 609 other flows that share a particular path, particular device 610 configuration, interface port, etc. A simple example is monitoring 611 of a network device that uses a scheduler or active queue management 612 technique [RFC7567], where it could be desirable to understand 613 whether the algorithms are correctly controlling latency, or if 614 overload protection is working. This implies knowledge of how 615 traffic is assigned to any sub-queues used for flow scheduling, but 616 can require information about how the traffic dynamics impact active 617 queue management, starvation prevention mechanisms, and circuit- 618 breakers. 620 Sometimes correlating observations of headers at multiple points 621 along the path (e.g., at the ingress and egress of a network 622 segment), allows an observer to determine the contribution of a 623 portion of the path to an observed metric. e.g., to locate a source 624 of delay, jitter, loss, reordering, or congestion marking. 626 2.4.2. Network Planning and Provisioning 628 Traffic rate and volume measurements are used to help plan deployment 629 of new equipment and configuration in networks. Data is also 630 valuable to equipment vendors who want to understand traffic trends 631 and patterns of usage as inputs to decisions about planning products 632 and provisioning for new deployments. 634 Trends in aggregate traffic can be observed and can be related to the 635 endpoint addresses being used, but when transport header information 636 is not observable, it might be impossible to correlate patterns in 637 measurements with changes in transport protocols. This increases the 638 dependency on other indirect sources of information to inform 639 planning and provisioning. 641 2.4.3. Compliance with Congestion Control 643 The traffic that can be observed by on-path network devices (the 644 "wire image") is a function of transport protocol design/options, 645 network use, applications, and user characteristics. In general, 646 when only a small proportion of the traffic has a specific 647 (different) characteristic, such traffic seldom leads to operational 648 concern, although the ability to measure and monitor it is lower. 649 The desire to understand the traffic and protocol interactions 650 typically grows as the proportion of traffic increases. The 651 challenges increase when multiple instances of an evolving protocol 652 contribute to the traffic that share network capacity. 654 Operators can manage traffic load (e.g., when the network is severely 655 overloaded) by deploying rate-limiters, traffic shaping, or network 656 transport circuit breakers [RFC8084]. The information provided by 657 observing transport headers is a source of data that can help to 658 inform such mechanisms. 660 Congestion Control Compliance of Traffic: Congestion control is a 661 key transport function [RFC2914]. Many network operators 662 implicitly accept that TCP traffic complies with a behaviour that 663 is acceptable for the shared Internet. TCP algorithms have been 664 continuously improved over decades, and have reached a level of 665 efficiency and correctness that is difficult to match in custom 666 application-layer mechanisms [RFC8085]. 668 A standards-compliant TCP stack provides congestion control that 669 is judged safe for use across the Internet. Applications 670 developed on top of well-designed transports can be expected to 671 appropriately control their network usage, reacting when the 672 network experiences congestion, by back-off and reduce the load 673 placed on the network. This is the normal expected behaviour for 674 IETF-specified transports (e.g., TCP and SCTP). 676 Congestion Control Compliance for UDP traffic: UDP provides a 677 minimal message-passing datagram transport that has no inherent 678 congestion control mechanisms. Because congestion control is 679 critical to the stable operation of the Internet, applications and 680 other protocols that choose to use UDP as a transport have to 681 employ mechanisms to prevent collapse, avoid unacceptable 682 contributions to jitter/latency, and to establish an acceptable 683 share of capacity with concurrent traffic [RFC8085]. 685 UDP flows that expose a well-known header can be observed to gain 686 understanding of the dynamics of a flow and its congestion control 687 behaviour. For example, tools exist to monitor various aspects of 688 RTP header information and RTCP reports for real-time flows (see 689 Section 2.3). The Secure RTP and RTCP extensions [RFC3711] were 690 explicitly designed to expose some header information to enable 691 such observation, while protecting the payload data. 693 A network operator can observe the headers of transport protocols 694 layered above UDP to understand if the datagram flows comply with 695 congestion control expectations. This can help inform a decision 696 on whether it might be appropriate to deploy methods such as rate- 697 limiters to enforce acceptable usage. The available information 698 determines the level of precision with which flows can be 699 classified and the design space for conditioning mechanisms (e.g., 700 rate limiting, circuit breaker techniques [RFC8084], or blocking 701 of uncharacterised traffic) [RFC5218]. 703 When anomalies are detected, tools can interpret the transport header 704 information to help understand the impact of specific transport 705 protocols (or protocol mechanisms) on the other traffic that shares a 706 network. An observer on the network path can gain an understanding 707 of the dynamics of a flow and its congestion control behaviour. 708 Analysing observed flows can help to build confidence that an 709 application flow backs-off its share of the network load under 710 persistent congestion, and hence to understand whether the behaviour 711 is appropriate for sharing limited network capacity. For example, it 712 is common to visualise plots of TCP sequence numbers versus time for 713 a flow to understand how a flow shares available capacity, deduce its 714 dynamics in response to congestion, etc. 716 The ability to identify sources and flows that contribute to 717 persistent congestion is important to the safe operation of network 718 infrastructure, and can inform configuration of network devices to 719 complement the endpoint congestion avoidance mechanisms [RFC7567] 720 [RFC8084] to avoid a portion of the network being driven into 721 congestion collapse [RFC2914]. 723 2.4.4. To Characterise "Unknown" Network Traffic 725 The patterns and types of traffic that share Internet capacity change 726 over time as networked applications, usage patterns and protocols 727 continue to evolve. 729 Encryption can increase the volume of "unknown" or "uncharacterised" 730 traffic seen by the network. If these traffic patterns form a small 731 part of the traffic aggregate passing through a network device or 732 segment of the network path, the dynamics of the uncharacterised 733 traffic might not have a significant collateral impact on the 734 performance of other traffic that shares this network segment. Once 735 the proportion of this traffic increases, monitoring the traffic can 736 determine if appropriate safety measures have to be put in place. 738 Tracking the impact of new mechanisms and protocols requires traffic 739 volume to be measured and new transport behaviours to be identified. 740 This is especially true of protocols operating over a UDP substrate. 741 The level and style of encryption needs to be considered in 742 determining how this activity is performed. 744 Traffic that cannot be classified typically receives a default 745 treatment. Some networks block or rate-limit traffic that cannot be 746 classified. 748 2.4.5. To Support Network Security Functions 750 On-path observation of the transport headers of packets can be used 751 for various security functions. For example, Denial of Service (DoS) 752 and Distributed DoS (DDoS) attacks against the infrastructure or 753 against an endpoint can be detected and mitigated by characterising 754 anomalous traffic (see Section 2.4.4) on a shorter timescale. Other 755 uses include support for security audits (e.g., verifying the 756 compliance with cipher suites), client and application fingerprinting 757 for inventory, and to provide alerts for network intrusion detection 758 and other next generation firewall functions. 760 When using an encrypted transport, endpoints can directly provide 761 information to support these security functions. Another method, if 762 the endpoints do not provide this information, is to use an on-path 763 network device that relies on pattern inferences in the traffic, and 764 heuristics or machine learning instead of processing observed header 765 information. An endpoint could also explicitly cooperate with an on- 766 path device (e.g., a QUIC endpoint could share information about 767 current uses of connection IDs). 769 2.4.6. Network Diagnostics and Troubleshooting 771 Operators monitor the health of a network segment to support a 772 variety of operational tasks [RFC8404] including procedures to 773 provide early warning and trigger action: to diagnose network 774 problems, to manage security threats (including DoS), to evaluate 775 equipment or protocol performance, or to respond to user performance 776 questions. Information about transport flows can assist in setting 777 buffer sizes, and help identify whether link/network tuning is 778 effective. Information can also support debugging and diagnosis of 779 the root causes of faults that concern a particular user's traffic 780 and can support post-mortem investigation after an anomaly. 781 Section 3.1.2 and Section 5 of [RFC8404] provide further examples. 783 Network segments vary in their complexity. The design trade-offs for 784 radio networks are often very different from those of wired networks 785 [RFC8462]. A radio-based network (e.g., cellular mobile, enterprise 786 Wireless LAN (WLAN), satellite access/back-haul, point-to-point 787 radio) adds a subsystem that performs radio resource management, with 788 impact on the available capacity, and potentially loss/reordering of 789 packets. This impact can differ by traffic type, and can be 790 correlated with link propagation and interference. These can impact 791 the cost and performance of a provided service, and is expected to 792 increase in importance as operators bring together heterogeneous 793 types of network equipment and deploy opportunistic methods to access 794 shared radio spectrum. 796 2.4.7. Tooling and Network Operations 798 A variety of open source and proprietary tools have been deployed 799 that use the transport header information observable with widely used 800 protocols such as TCP or RTP/UDP/IP. Tools that dissect network 801 traffic flows can alert to potential problems that are hard to derive 802 from volume measurements, link statistics or device measurements 803 alone. 805 Any introduction of a new transport protocol, protocol feature, or 806 application might require changes to such tools, and so could impact 807 operational practice and policies. Such changes have associated 808 costs that are incurred by the network operators that need to update 809 their tooling or develop alternative practises that work without 810 access to the changed/removed information. 812 The use of encryption has the desirable effect of preventing 813 unintended observation of the payload data and these tools seldom 814 seek to observe the payload, or other application details. A flow 815 that hides its transport header information could imply "don't touch" 816 to some operators. This might limit a trouble-shooting response to 817 "can't help, no trouble found". 819 An alternative that does not require access to observable transport 820 headers is to access endpoint diagnostic tools or to include user 821 involvement in diagnosing and troubleshooting unusual use cases or to 822 troubleshoot non-trivial problems. Another approach is to use 823 traffic pattern analysis. Such tools can provide useful information 824 during network anomalies (e.g., detecting significant reordering, 825 high or intermittent loss), however indirect measurements need to be 826 carefully designed to provide information for diagnostics and 827 troubleshooting. 829 If new protocols, or protocol extensions, are made to closely 830 resemble or match existing mechanisms, then the changes to tooling 831 and the associated costs can be small. Equally, more extensive 832 changes to the transport tend to require more extensive, and more 833 expensive, changes to tooling and operational practice. Protocol 834 designers can mitigate these costs by explicitly choosing to expose 835 selected information as invariants that are guaranteed not to change 836 for a particular protocol (e.g., the header invariants and the spin- 837 bit in QUIC [I-D.ietf-quic-transport]). Specification of common log 838 formats and development of alternative approaches can also help 839 mitigate the costs of transport changes. 841 2.5. To Mitigate the Effects of Constrained Networks 843 Some link and network segments are constrained by the capacity they 844 can offer, by the time it takes to access capacity (e.g., due to 845 under-lying radio resource management methods), or by asymmetries in 846 the design (e.g., many link are designed so that the capacity 847 available is different in the forward and return directions; some 848 radio technologies have different access methods in the forward and 849 return directions resulting from differences in the power budget). 851 The impact of path constraints can be mitigated using a proxy 852 operating at or above the transport layer to use an alternate 853 transport protocol. 855 In many cases, one or both endpoints are unaware of the 856 characteristics of the constraining link or network segment and 857 mitigations are applied below the transport layer: Packet 858 classification and QoS methods (described in various sections) can be 859 beneficial in differentially prioritising certain traffic when there 860 is a capacity constraint or additional delay in scheduling link 861 transmissions. Another common mitigation is to apply header 862 compression over the specific link or subnetwork (see Section 2.5.1). 864 2.5.1. To Provide Header Compression 866 Header compression saves link capacity by compressing network and 867 transport protocol headers on a per-hop basis. This has been widely 868 used with low bandwidth dial-up access links, and still finds 869 application on wireless links that are subject to capacity 870 constraints. These methods are effective for bit-congestive links 871 sending small packets (e.g., reducing the cost for sending control 872 packets or small data packets over radio links). 874 Examples of header compression include use with TCP/IP and RTP/UDP/IP 875 flows [RFC2507], [RFC6846], [RFC2508], [RFC5795], [RFC8724]. 876 Successful compression depends on observing the transport headers and 877 understanding of the way fields change between packets, and is hence 878 incompatible with header encryption. Devices that compress transport 879 headers are dependent on a stable header format, implying 880 ossification of that format. 882 Introducing a new transport protocol, or changing the format of the 883 transport header information, will limit the effectiveness of header 884 compression until the network devices are updated. Encrypting the 885 transport protocol headers will tend to cause the header compression 886 to fall back to compressing only the network layer headers, with a 887 significant reduction in efficiency. This can limit connectivity if 888 the resulting flow exceeds the link capacity, or if the packets are 889 dropped because they exceed the link MTU. 891 The Secure RTP (SRTP) extensions [RFC3711] were explicitly designed 892 to leave the transport protocol headers unencrypted, but 893 authenticated, since support for header compression was considered 894 important. 896 2.6. To Verify SLA Compliance 898 Observable transport headers coupled with published transport 899 specifications allow operators and regulators to explore and verify 900 compliance with Service Level Agreements (SLAs). It can also be used 901 to understand whether a service is providing differential treatment 902 to certain flows. 904 When transport header information cannot be observed, other methods 905 have to be found to confirm that the traffic produced conforms to the 906 expectations of the operator or developer. 908 Independently verifiable performance metrics can be utilised to 909 demonstrate regulatory compliance in some jurisdictions, and as a 910 basis for informing design decisions. This can bring assurance to 911 those operating networks, often avoiding deployment of complex 912 techniques that routinely monitor and manage Internet traffic flows 913 (e.g., avoiding the capital and operational costs of deploying flow 914 rate-limiting and network circuit-breaker methods [RFC8084]). 916 3. Research, Development and Deployment 918 Research and development of new protocols and mechanisms need to be 919 informed by measurement data (as described in the previous section). 920 Data can also help promote acceptance of proposed standards 921 specifications by the wider community (e.g., as a method to judge the 922 safety for Internet deployment). 924 Observed data is important to ensure the health of the research and 925 development communities, and provides data needed to evaluate new 926 proposals for standardisation. Open standards motivate a desire to 927 include independent observation and evaluation of performance and 928 deployment data. Independent data helps compare different methods, 929 judge the level of deployment and ensure the wider applicability of 930 the results. This is important when considering when a protocol or 931 mechanism should be standardised for use in the general Internet. 932 This, in turn, demands control/understanding about where and when 933 measurement samples are collected. This requires consideration of 934 the methods used to observe information and the appropriate balance 935 between encrypting all and no transport header information. 937 There can be performance and operational trade-offs in exposing 938 selected information to network tools. This section explores key 939 implications of tools and procedures that observe transport 940 protocols, but does not endorse or condemn any specific practises. 942 3.1. Independent Measurement 944 Encrypting transport header information has implications on the way 945 network data is collected and analysed. Independent observation by 946 multiple actors is currently used by the transport community to 947 maintain an accurate understanding of the network within transport 948 area working groups, IRTF research groups, and the broader research 949 community. This is important to be able to provide accountability, 950 and demonstrate that protocols behave as intended, although when 951 providing or using such information, it is important to consider the 952 privacy of the user and their incentive for providing accurate and 953 detailed information. 955 Protocols that expose the state of the transport protocol in their 956 header (e.g., timestamps used to calculate the RTT, packet numbers 957 used to assess congestion and requests for retransmission) provide an 958 incentive for a sending endpoint to provide consistent information, 959 because a protocol will not work otherwise. An on-path observer can 960 have confidence that well-known (and ossified) transport header 961 information represents the actual state of the endpoints, when this 962 information is necessary for the protocol's correct operation. 964 Encryption of transport header information could reduce the range of 965 actors that can observe useful data. This would limit the 966 information sources available to the Internet community to understand 967 the operation of new transport protocols, reducing information to 968 inform design decisions and standardisation of the new protocols and 969 related operational practises. The cooperating dependence of 970 network, application, and host to provide communication performance 971 on the Internet is uncertain when only endpoints (i.e., at user 972 devices and within service platforms) can observe performance, and 973 when performance cannot be independently verified by all parties. 975 3.2. Measurable Transport Protocols 977 Transport protocol evolution, and the ability to measure and 978 understand the impact of protocol changes, have to proceed hand-in- 979 hand. A transport protocol that provides observable headers can be 980 used to provide open and verifiable measurement data. Observation of 981 pathologies has a critical role in the design of transport protocol 982 mechanisms and development of new mechanisms and protocols, and aides 983 understanding of the interactions between cooperating protocols and 984 network mechanisms, the implications of sharing capacity with other 985 traffic and the impact of different patterns of usage. The ability 986 of other stakeholders to review transport header traces helps develop 987 insight into the performance and the traffic contribution of specific 988 variants of a protocol. 990 Development of new transport protocol mechanisms has to consider the 991 scale of deployment and the range of environments in which the 992 transport is used. Experience has shown that it is often difficult 993 to correctly implement new mechanisms [RFC8085], and that mechanisms 994 often evolve as a protocol matures, or in response to changes in 995 network conditions, changes in network traffic, or changes to 996 application usage. Analysis is especially valuable when based on the 997 behaviour experienced across a range of topologies, vendor equipment, 998 and traffic patterns. 1000 Encryption enables a transport protocol to choose which internal 1001 state to reveal to devices on the network path, what information to 1002 encrypt, and what fields to grease [RFC8701]. A new design can 1003 provide summary information regarding its performance, congestion 1004 control state, etc., or to make available explicit measurement 1005 information. For example, [I-D.ietf-quic-transport] specifies a way 1006 for a QUIC endpoint to optionally set the spin-bit to explicitly 1007 reveal the RTT of an encrypted transport session to the on-path 1008 network devices. There is a choice of what information to expose. 1009 For some operational uses, the information has to contain sufficient 1010 detail to understand, and possibly reconstruct, the network traffic 1011 pattern for further testing. The interpretation of the information 1012 needs to consider whether this information reflects the actual 1013 transport state of the endpoints. This might require the trust of 1014 transport protocol implementers, to correctly reveal the desired 1015 information. 1017 New transport protocol formats are expected to facilitate an 1018 increased pace of transport evolution, and with it the possibility to 1019 experiment with and deploy a wide range of protocol mechanisms. At 1020 the time of writing, there has been interest in a wide range of new 1021 transport methods, e.g., Larger Initial Window, Proportional Rate 1022 Reduction (PRR), congestion control methods based on measuring 1023 bottleneck bandwidth and round-trip propagation time, the 1024 introduction of AQM techniques and new forms of ECN response (e.g., 1025 Data Centre TCP, DCTCP, and methods proposed for L4S). The growth 1026 and diversity of applications and protocols using the Internet also 1027 continues to expand. For each new method or application, it is 1028 desirable to build a body of data reflecting its behaviour under a 1029 wide range of deployment scenarios, traffic load, and interactions 1030 with other deployed/candidate methods. 1032 3.3. Other Sources of Information 1034 Some measurements that traditionally rely on observable transport 1035 information could be completed by utilising endpoint-based logging 1036 (e.g., based on Quic-Trace [Quic-Trace] and qlog 1037 [I-D.marx-qlog-main-schema]). Such information has a diversity of 1038 uses, including developers wishing to debug/understand the transport/ 1039 application protocols with which they work, researchers seeking to 1040 spot trends and anomalies, and to characterise variants of protocols. 1041 A standard format for endpoint logging could allow these to be shared 1042 (after appropriate anonymisation) to understand performance and 1043 pathologies. 1045 When measurement datasets are made available by servers or client 1046 endpoints, additional metadata, such as the state of the network and 1047 conditions in which the system was observed, is often necessary to 1048 interpret this data to answer questions about network performance or 1049 understand a pathology. Collecting and coordinating such metadata is 1050 more difficult when the observation point is at a different location 1051 to the bottleneck or device under evaluation [RFC7799]. 1053 Despite being applicable in some scenarios, endpoint logs do not 1054 provide equivalent information to on-path measurements made by 1055 devices in the network. In particular, endpoint logs contain only a 1056 part of the information to understand the operation of network 1057 devices and identify issues such as link performance or capacity 1058 sharing between multiple flows. An analysis can require coordination 1059 between actors at different layers to successfully characterise flows 1060 and correlate the performance or behaviour of a specific mechanism 1061 with an equipment configuration and traffic using operational 1062 equipment along a network path (e.g., combining transport and network 1063 measurements to explore congestion control dynamics, to understand 1064 the implications of traffic on designs for active queue management or 1065 circuit breakers). 1067 Another source of information could arise from operations, 1068 administration and management (OAM) (see Section 6) information data 1069 records could be embedded into header information at different layers 1070 to support functions such as performance evaluation, path-tracing, 1071 path verification information, classification and a diversity of 1072 other uses. 1074 In-situ OAM (IOAM) data fields [I-D.ietf-ippm-ioam-data] can be 1075 encapsulated into a variety of protocols to record operational and 1076 telemetry information in an existing packet, while that packet 1077 traverses a part of the path between two points in a network (e.g., 1078 within a particular IOAM management domain). The IOAM-Data-Fields 1079 are independent from the protocols into which the IOAM-Data-Fields 1080 are encapsulated. For example, IOAM can provide proof that a certain 1081 traffic flow takes a pre-defined path, SLA verification for the live 1082 data traffic, and statistics relating to traffic distribution. 1084 4. Encryption and Authentication of Transport Headers 1086 There are several motivations for transport header encryption. 1088 One motive to encrypt transport headers is to prevent network 1089 ossification from network devices that inspect well-known transport 1090 headers. Once a network device observes a transport header and 1091 becomes reliant upon using it, the overall use of that field can 1092 become ossified, preventing new versions of the protocol and 1093 mechanisms from being deployed. Examples include: 1095 o During the development of TLS 1.3 [RFC8446], the design needed to 1096 function in the presence of deployed middleboxes that relied on 1097 the presence of certain header fields exposed in TLS 1.2 1098 [RFC5426]. 1100 o The design of Multipath TCP (MPTCP) [RFC8684] had to account for 1101 middleboxes (known as "TCP Normalizers") that monitor the 1102 evolution of the window advertised in the TCP header and then 1103 reset connections when the window did not grow as expected. 1105 o TCP Fast Open [RFC7413] can experience problems due to middleboxes 1106 that modify the transport header of packets by removing "unknown" 1107 TCP options. Segments with unrecognised TCP options can be 1108 dropped, segments that contain data and set the SYN bit can be 1109 dropped, and some middleboxes that disrupt connections that send 1110 data before completion of the three-way handshake. 1112 o Other examples of TCP ossification have included middleboxes that 1113 modify transport headers by rewriting TCP sequence and 1114 acknowledgement numbers, but are unaware of the (newer) TCP 1115 selective acknowledgement (SACK) option and therefore fail to 1116 correctly rewrite the SACK information to match the changes made 1117 to the fixed TCP header, preventing correct SACK operation. 1119 In all these cases, middleboxes with a hard-coded, but incomplete, 1120 understanding of a specific transport behaviour (i.e., TCP), 1121 interacted poorly with transport protocols after the transport 1122 behaviour was changed. In some cases, the middleboxes modified or 1123 replaced information in the transport protocol header. 1125 Transport header encryption prevents an on-path device from observing 1126 the transport headers, and therefore stops ossified mechanisms being 1127 used that directly rely on or infer semantics of the transport header 1128 information. This encryption is normally combined with 1129 authentication of the protected information. RFC 8546 summarises 1130 this approach, stating that it is "The wire image, not the protocol's 1131 specification, determines how third parties on the network paths 1132 among protocol participants will interact with that protocol" 1133 (Section 1 of [RFC8546]), and it can be expected that header 1134 information that is not encrypted will become ossified. 1136 Encryption does not itself prevent ossification of the network 1137 service. People seeking to understand or classify network traffic 1138 could still come to rely on pattern inferences and other heuristics 1139 or machine learning to derive measurement data and as the basis for 1140 network forwarding decisions [RFC8546]. This can also create 1141 dependencies on the transport protocol, or the patterns of traffic it 1142 can generate, also resulting in ossification of the service. 1144 Another motivation for using transport header encryption is to 1145 improve privacy and to decrease opportunities for surveillance. 1146 Users value the ability to protect their identity and location, and 1147 defend against analysis of the traffic. Revelations about the use of 1148 pervasive surveillance [RFC7624] have, to some extent, eroded trust 1149 in the service offered by network operators and have led to an 1150 increased use of encryption. Concerns have also been voiced about 1151 the addition of metadata to packets by third parties to provide 1152 analytics, customisation, advertising, cross-site tracking of users, 1153 to bill the customer, or to selectively allow or block content. 1155 Whatever the reasons, the IETF is designing protocols that include 1156 transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to 1157 supplement the already widespread payload encryption, and to further 1158 limit exposure of transport metadata to the network. 1160 If a transport protocol uses header encryption, the designers have to 1161 decide whether to encrypt all, or a part of, the transport layer 1162 information. Section 4 of [RFC8558] states: "Anything exposed to the 1163 path should be done with the intent that it be used by the network 1164 elements on the path". 1166 Certain transport header fields can be made observable to on-path 1167 network devices, or can define new fields designed to explicitly 1168 expose observable transport layer information to the network. Where 1169 exposed fields are intended to be immutable (i.e., can be observed, 1170 but not modified by a network device), the endpoints are encouraged 1171 to use authentication to provide a cryptographic integrity check that 1172 can detect if these immutable fields have been modified by network 1173 devices. Authentication can help to prevent attacks that rely on 1174 sending packets that fake exposed control signals in transport 1175 headers (e.g., TCP RST spoofing). Making a part of a transport 1176 header observable or exposing new header fields can lead to 1177 ossification of that part of a header as network devices come to rely 1178 on observations of the exposed fields. 1180 The use of transport header authentication and encryption therefore 1181 exposes a tussle between middlebox vendors, operators, researchers, 1182 applications developers, and end-users: 1184 o On the one hand, future Internet protocols that support transport 1185 header encryption assist in the restoration of the end-to-end 1186 nature of the Internet by returning complex processing to the 1187 endpoints. Since middleboxes cannot modify what they cannot see, 1188 the use of transport header encryption can improve application and 1189 end-user privacy by reducing leakage of transport metadata to 1190 operators that deploy middleboxes. 1192 o On the other hand, encryption of transport layer information has 1193 implications for network operators and researchers seeking to 1194 understand the dynamics of protocols and traffic patterns, since 1195 it reduces the information that is available to them. 1197 The following briefly reviews some security design options for 1198 transport protocols. A Survey of the Interaction between Security 1199 Protocols and Transport Services [RFC8922] provides more details 1200 concerning commonly used encryption methods at the transport layer. 1202 Security work typically employs a design technique that seeks to 1203 expose only what is needed [RFC3552]. This approach provides 1204 incentives to not reveal any information that is not necessary for 1205 the end-to-end communication. The IETF has provided guidelines for 1206 writing Security Considerations for IETF specifications [RFC3552]. 1208 Endpoint design choices impacting privacy also need to be considered 1209 as a part of the design process [RFC6973]. The IAB has provided 1210 guidance for analyzing and documenting privacy considerations within 1211 IETF specifications [RFC6973]. 1213 Authenticating the Transport Protocol Header: Transport layer header 1214 information can be authenticated. An example transport 1215 authentication mechanism is TCP-Authentication (TCP-AO) [RFC5925]. 1216 This TCP option authenticates the IP pseudo header, TCP header, 1217 and TCP data. TCP-AO protects the transport layer, preventing 1218 attacks from disabling the TCP connection itself and provides 1219 replay protection. Such authentication might interact with 1220 middleboxes, depending on their behaviour [RFC3234]. 1222 The IPsec Authentication Header (AH) [RFC4302] was designed to 1223 work at the network layer and authenticate the IP payload. This 1224 approach authenticates all transport headers, and verifies their 1225 integrity at the receiver, preventing modification by network 1226 devices on the path. The IPsec Encapsulating Security Payload 1227 (ESP) [RFC4303] can also provide authentication and integrity 1228 without confidentiality using the NULL encryption algorithm 1229 [RFC2410]. SRTP [RFC3711] is another example of a transport 1230 protocol that allows header authentication. 1232 Integrity Check Transport protocols usually employ integrity checks 1233 on the transport header information. Security method usually 1234 employ stronger checks and can combine this with authentication. 1235 An integrity check that protects the immutable transport header 1236 fields, but can still expose the transport header information in 1237 the clear, allows on-path network devices to observe these fields. 1238 An integrity check is not able to prevent modification by network 1239 devices on the path, but can prevent a receiving endpoint from 1240 accepting changes and avoid impact on the transport protocol 1241 operation, including some types of attack. 1243 Selectively Encrypting Transport Headers and Payload: A transport 1244 protocol design that encrypts selected header fields, allows 1245 specific transport header fields to be made observable by network 1246 devices on the path. This information is explicitly exposed 1247 either in a transport header field or lower layer protocol header. 1248 A design that only exposes immutable fields can also perform end- 1249 to-end authentication of these fields across the path to prevent 1250 undetected modification of the immutable transport headers. 1252 Mutable fields in the transport header provide opportunities where 1253 on-path network devices can modify the transport behaviour (e.g., 1254 the extended headers described in 1255 [I-D.trammell-plus-abstract-mech]). An example of a method that 1256 encrypts some, but not all, transport header information is GRE- 1257 in-UDP [RFC8086] when used with GRE encryption. 1259 Optional Encryption of Header Information: There are implications to 1260 the use of optional header encryption in the design of a transport 1261 protocol, where support of optional mechanisms can increase the 1262 complexity of the protocol and its implementation, and in the 1263 management decisions that have to be made to use variable format 1264 fields. Instead, fields of a specific type ought to be sent with 1265 the same level of confidentiality or integrity protection. 1267 Greasing: Protocols often provide extensibility features, reserving 1268 fields or values for use by future versions of a specification. 1269 The specification of receivers has traditionally ignored 1270 unspecified values, however on-path network devices have emerged 1271 that ossify to require a certain value in a field, or re-use a 1272 field for another purpose. When the specification is later 1273 updated, it is impossible to deploy the new use of the field, and 1274 forwarding of the protocol could even become conditional on a 1275 specific header field value. 1277 A protocol can intentionally vary the value, format, and/or 1278 presence of observable transport header fields at random 1279 [RFC8701]. This prevents a network device ossifying the use of a 1280 specific observable field and can ease future deployment of new 1281 uses of the value or code-point. This is not a security 1282 mechanism, although the use can be combined with an authentication 1283 mechanism. 1285 Different transports use encryption to protect their header 1286 information to varying degrees. The trend is towards increased 1287 protection. 1289 5. Intentionally Exposing Transport Information to the Network 1291 A transport protocol can choose to expose certain transport 1292 information to on-path devices operating at the network layer by 1293 sending observable fields. One approach is to make an explicit 1294 choice not to encrypt certain transport header fields, making this 1295 transport information observable by an on-path network device. 1296 Another approach is to expose transport information in a network- 1297 layer extension header (see Section 5.1). Both are examples of 1298 explicit information intended to be used by network devices on the 1299 path [RFC8558]. 1301 Whatever the mechanism used to expose the information, a decision to 1302 expose only specific information places the transport endpoint in 1303 control of what to expose outside of the encrypted transport header. 1304 This decision can then be made independently of the transport 1305 protocol functionality. This can be done by exposing part of the 1306 transport header or as a network layer option/extension. 1308 5.1. Exposing Transport Information in Extension Headers 1310 At the network-layer, packets can carry optional headers that 1311 explicitly expose transport header information to the on-path devices 1312 operating at the network layer (Section 2.3.2). For example, an 1313 endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide 1314 explicit transport layer information that can be observed and used by 1315 network devices on the path. New hop-by-hop options are not 1316 recommended in RFC 8200 [RFC8200] "because nodes may be configured to 1317 ignore the Hop-by-Hop Options header, drop packets containing a Hop- 1318 by-Hop Options header, or assign packets containing a Hop-by-Hop 1319 Options header to a slow processing path. Designers considering 1320 defining new hop-by-hop options need to be aware of this likely 1321 behavior." 1323 Network-layer optional headers explicitly indicate the information 1324 that is exposed, whereas use of exposed transport header information 1325 first requires an observer to identify the transport protocol and its 1326 format. (See Section 2.2.) 1328 An arbitrary path can include one or more network devices that drop 1329 packets that include a specific header or option used for this 1330 purpose (see [RFC7872]). This could impact the proper functioning of 1331 the protocols using the path. Protocol methods can be designed to 1332 probe to discover whether the specific option(s) can be used along 1333 the current path, enabling use on arbitrary paths. 1335 5.2. Common Exposed Transport Information 1337 There are opportunities for multiple transport protocols to 1338 consistently supply common observable information [RFC8558]. A 1339 common approach can result in an open definition of the observable 1340 fields. This has the potential that the same information can be 1341 utilised across a range of operational and analysis tools. 1343 5.3. Considerations for Exposing Transport Information 1345 Considerations concerning what information, if any, it is appropriate 1346 to expose include: 1348 o On the one hand, explicitly exposing derived fields containing 1349 relevant transport information (e.g., metrics for loss, latency, 1350 etc) can avoid network devices needing to derive this information 1351 from other header fields. This could result in development and 1352 evolution of transport-independent tools around a common 1353 observable header, and permit transport protocols to also evolve 1354 independently of this ossified header [RFC8558]. 1356 o On the other hand, protocols and implementations might be designed 1357 to avoid consistently exposing external information that 1358 corresponds to the actual internal information used by the 1359 protocol itself. An endpoint/protocol could choose to expose 1360 transport header information to optimise the benefit it gets from 1361 the network [RFC8558]. The value of this information for 1362 analysing operation of the transport layer would be enhanced if 1363 the exposed information could be verified to match the transport 1364 protocol's observed behavior. 1366 The motivation to include actual transport header information and the 1367 implications of network devices using this information has to be 1368 considered when proposing such a method. RFC 8558 summarises this as 1369 "When signals from endpoints to the path are independent from the 1370 signals used by endpoints to manage the flow's state mechanics, they 1371 may be falsified by an endpoint without affecting the peer's 1372 understanding of the flow's state. For encrypted flows, this 1373 divergence is not detectable by on-path devices [RFC8558]. 1375 6. Addition of Transport OAM Information to Network-Layer Headers 1377 Even when the transport headers are encrypted, on-path devices can 1378 make measurements by utilising additional protocol headers carrying 1379 OAM information in an additional packet header. OAM information can 1380 be included with packets to perform functions such as identification 1381 of transport protocols and flows, to aide understanding of network or 1382 transport performance, or to support network operations or mitigate 1383 the effects of specific network segments. 1385 Using network-layer approaches to reveal information has the 1386 potential that the same method (and hence same observation and 1387 analysis tools) can be consistently used by multiple transport 1388 protocols. This approach also could be applied to methods beyond OAM 1389 (see Section 5). There can also be less desirable implications from 1390 separating the operation of the transport protocol from the 1391 measurement framework. 1393 6.1. Use of OAM within a Maintenance Domain 1395 OAM information can be restricted to a maintenance domain, typically 1396 owned and operated by a single entity. OAM information can be added 1397 at the ingress to the maintenance domain (e.g., an Ethernet protocol 1398 header with timestamps and sequence number information using a method 1399 such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data], or as a 1400 part of the encapsulation protocol). This additional header 1401 information is not delivered to the endpoints and is typically 1402 removed at the egress of the maintenance domain. 1404 Although some types of measurements are supported, this approach does 1405 not cover the entire range of measurements described in this 1406 document. In some cases, it can be difficult to position measurement 1407 tools at the appropriate segments/nodes and there can be challenges 1408 in correlating the downstream/upstream information when in-band OAM 1409 data is inserted by an on-path device. 1411 6.2. Use of OAM across Multiple Maintenance Domains 1413 OAM information can also be added at the network layer by the sender 1414 as an IPv6 extension header or an IPv4 option, or in an 1415 encapsulation/tunnel header that also includes an extension header or 1416 option. This information can be used across multiple network 1417 segments, or between the transport endpoints. 1419 One example is the IPv6 Performance and Diagnostic Metrics (PDM) 1420 destination option [RFC8250]. This allows a sender to optionally 1421 include a destination option that carries header fields that can be 1422 used to observe timestamps and packet sequence numbers. This 1423 information could be authenticated by a receiving transport endpoint 1424 when the information is added at the sender and visible at the 1425 receiving endpoint, although methods to do this have not currently 1426 been proposed. This needs to be explicitly enabled at the sender. 1428 7. Conclusions 1430 Header encryption and strong integrity checks are being incorporated 1431 into new transport protocols and have important benefits. The pace 1432 of development of transports using the WebRTC data channel, and the 1433 rapid deployment of the QUIC transport protocol, can both be 1434 attributed to using the combination of UDP as a substrate while 1435 providing confidentiality and authentication of the encapsulated 1436 transport headers and payload. 1438 This document has described some current practises, and the 1439 implications for some stakeholders, when transport layer header 1440 encryption is used. It does not judge whether these practises are 1441 necessary, or endorse the use of any specific practise. Rather, the 1442 intent is to highlight operational tools and practises to consider 1443 when designing and modifying transport protocols, so protocol 1444 designers can make informed choices about what transport header 1445 fields to encrypt, and whether it might be beneficial to make an 1446 explicit choice to expose certain fields to devices on the network 1447 path. In making such a decision, it is important to balance: 1449 o User Privacy: The less transport header information that is 1450 exposed to the network, the lower the risk of leaking metadata 1451 that might have user privacy implications. Transports that chose 1452 to expose some header fields need to make a privacy assessment to 1453 understand the privacy cost versus benefit trade-off in making 1454 that information available. The design of the QUIC spin bit to 1455 the network is an example of such considered analysis. 1457 o Transport Ossification: Unencrypted transport header fields are 1458 likely to ossify rapidly, as network devices come to rely on their 1459 presence, making it difficult to change the transport in future. 1460 This argues that the choice to expose information to the network 1461 is made deliberately and with care, since it is essentially 1462 defining a stable interface between the transport and the network. 1463 Some protocols will want to make that interface as limited as 1464 possible; other protocols might find value in exposing certain 1465 information to signal to the network, or in allowing the network 1466 to change certain header fields as signals to the transport. The 1467 visible wire image of a protocol should be explicitly designed. 1469 o Network Ossification: While encryption can reduce ossification of 1470 the transport protocol, it does not itself prevent ossification of 1471 the network service. People seeking to understand network traffic 1472 could still come to rely on pattern inferences and other 1473 heuristics or machine learning to derive measurement data and as 1474 the basis for network forwarding decisions [RFC8546]. This 1475 creates dependencies on the transport protocol, or the patterns of 1476 traffic it can generate, resulting in ossification of the service. 1478 o Impact on Operational Practice: The network operations community 1479 has long relied on being able to understand Internet traffic 1480 patterns, both in aggregate and at the flow level, to support 1481 network management, traffic engineering, and troubleshooting. 1482 Operational practice has developed based on the information 1483 available from unencrypted transport headers. The IETF has 1484 supported this practice by developing operations and management 1485 specifications, interface specifications, and associated Best 1486 Current Practises. Widespread deployment of transport protocols 1487 that encrypt their information will impact network operations, 1488 unless operators can develop alternative practises that work 1489 without access to the transport header. 1491 o Pace of Evolution: Removing obstacles to change can enable an 1492 increased pace of evolution. If a protocol changes its transport 1493 header format (wire image), or its transport behaviour, this can 1494 result in the currently deployed tools and methods becoming no 1495 longer relevant. Where this needs to be accompanied by 1496 development of appropriate operational support functions and 1497 procedures, it can incur a cost in new tooling to catch-up with 1498 each change. Protocols that consistently expose observable data 1499 do not require such development, but can suffer from ossification 1500 and need to consider if the exposed protocol metadata has privacy 1501 implications. There is no single deployment context, and 1502 therefore designers need to consider the diversity of operational 1503 networks (ISPs, enterprises, DDoS mitigation and firewall 1504 maintainers, etc.). 1506 o Supporting Common Specifications: Common, open, transport 1507 specifications can stimulate engagement by developers, users, 1508 researchers, and the broader community. Increased protocol 1509 diversity can be beneficial in meeting new requirements, but the 1510 ability to innovate without public scrutiny risks point solutions 1511 that optimise for specific cases, and that can accidentally 1512 disrupt operations of/in different parts of the network. The 1513 social contract that maintains the stability of the Internet 1514 relies on accepting common transport specifications, and on it 1515 being possible to detect violations. The existence of independent 1516 measurements, transparency, and public scrutiny of transport 1517 protocol behaviour, help the community to enforce the social norm 1518 that protocol implementations behave fairly and conform (at least 1519 mostly) to the specifications. It is important to find new ways 1520 of maintaining that community trust as increased use of transport 1521 header encryption limits visibility into transport behaviour (see 1522 also Section 5.3). 1524 o Impact on Benchmarking and Understanding Feature Interactions: An 1525 appropriate vantage point for observation, coupled with timing 1526 information about traffic flows, provides a valuable tool for 1527 benchmarking network devices, endpoint stacks, and/or 1528 configurations. This can help understand complex feature 1529 interactions. An inability to observe transport header 1530 information can make it harder to diagnose and explore 1531 interactions between features at different protocol layers, a 1532 side-effect of not allowing a choice of vantage point from which 1533 this information is observed. New approaches might have to be 1534 developed. 1536 o Impact on Research and Development: Hiding transport header 1537 information can impede independent research into new mechanisms, 1538 measurement of behaviour, and development initiatives. Experience 1539 shows that transport protocols are complicated to design and 1540 complex to deploy, and that individual mechanisms have to be 1541 evaluated while considering other mechanisms, across a broad range 1542 of network topologies and with attention to the impact on traffic 1543 sharing the capacity. If increased use of transport header 1544 encryption results in reduced availability of open data, it could 1545 eliminate the independent checks to the standardisation process 1546 that have previously been in place from research and academic 1547 contributors (e.g., the role of the IRTF Internet Congestion 1548 Control Research Group (ICCRG) and research publications in 1549 reviewing new transport mechanisms and assessing the impact of 1550 their deployment). 1552 Observable transport header information might be useful to various 1553 stakeholders. Other sets of stakeholders have incentives to limit 1554 what can be observed. This document does not make recommendations 1555 about what information ought to be exposed, to whom it ought to be 1556 observable, or how this will be achieved. There are also design 1557 choices about where observable fields are placed. For example, one 1558 location could be a part of the transport header outside of the 1559 encryption envelope, another alternative is to carry the information 1560 in a network-layer option or extension header. New transport 1561 protocol designs ought to explicitly identify any fields that are 1562 intended to be observed, consider if there are alternative ways of 1563 providing the information, and reflect on the implications of 1564 observable fields being used by on-path network devices, and how this 1565 might impact user privacy and protocol evolution when these fields 1566 become ossified. 1568 As [RFC7258] notes, "Making networks unmanageable to mitigate 1569 (pervasive monitoring) is not an acceptable outcome, but ignoring 1570 (pervasive monitoring) would go against the consensus documented 1571 here." Providing explicit information can help avoid traffic being 1572 inappropriately classified, impacting application performance. An 1573 appropriate balance will emerge over time as real instances of this 1574 tension are analysed [RFC7258]. This balance between information 1575 exposed and information hidden ought to be carefully considered when 1576 specifying new transport protocols. 1578 8. Security Considerations 1580 This document is about design and deployment considerations for 1581 transport protocols. Issues relating to security are discussed 1582 throughout this document. 1584 Authentication, confidentiality protection, and integrity protection 1585 are identified as Transport Features by [RFC8095]. As currently 1586 deployed in the Internet, these features are generally provided by a 1587 protocol or layer on top of the transport protocol [RFC8922]. 1589 Confidentiality and strong integrity checks have properties that can 1590 also be incorporated into the design of a transport protocol or to 1591 modify an existing transport. Integrity checks can protect an 1592 endpoint from undetected modification of protocol fields by on-path 1593 network devices, whereas encryption and obfuscation or greasing can 1594 further prevent these headers being utilised by network devices 1595 [RFC8701]. Preventing observation of headers provides an opportunity 1596 for greater freedom to update the protocols and can ease 1597 experimentation with new techniques and their final deployment in 1598 endpoints. A protocol specification needs to weigh the costs of 1599 ossifying common headers, versus the potential benefits of exposing 1600 specific information that could be observed along the network path to 1601 provide tools to manage new variants of protocols. 1603 Header encryption can provide confidentiality of some or all of the 1604 transport header information. This prevents an on-path device from 1605 gaining knowledge of the header field. It therefore prevents 1606 mechanisms being built that directly rely on the information or seeks 1607 to infer semantics of an exposed header field. Reduced visibility 1608 into transport metadata can limit the ability to measure and 1609 characterise traffic, and conversely can provide privacy benefits. 1611 Extending the transport payload security context to also include the 1612 transport protocol header protects both types of information with the 1613 same key. A privacy concern would arise if this key was shared with 1614 a third party, e.g., providing access to transport header information 1615 to debug a performance issue, would also result in exposing the 1616 transport payload data to the same third party. Such risks would be 1617 mitigated using a layered security design that provides one domain of 1618 protection and associated keys for the transport payload and 1619 encrypted transport headers; and a separate domain of protection and 1620 associated keys for any observable transport header fields. 1622 Exposed transport headers are sometimes utilised as a part of the 1623 information to detect anomalies in network traffic. "While PM is an 1624 attack, other forms of monitoring that might fit the definition of PM 1625 can be beneficial and not part of any attack, e.g., network 1626 management functions monitor packets or flows and anti-spam 1627 mechanisms need to see mail message content." [RFC7258]. This can 1628 be used as the first line of defence to identify potential threats 1629 from DoS or malware and redirect suspect traffic to dedicated nodes 1630 responsible for DoS analysis, malware detection, or to perform packet 1631 "scrubbing" (the normalisation of packets so that there are no 1632 ambiguities in interpretation by the ultimate destination of the 1633 packet). These techniques are currently used by some operators to 1634 also defend from distributed DoS attacks. 1636 Exposed transport header fields can also form a part of the 1637 information used by the receiver of a transport protocol to protect 1638 the transport layer from data injection by an attacker. In 1639 evaluating this use of exposed header information, it is important to 1640 consider whether it introduces a significant DoS threat. For 1641 example, an attacker could construct a DoS attack by sending packets 1642 with a sequence number that falls within the currently accepted range 1643 of sequence numbers at the receiving endpoint. This would then 1644 introduce additional work at the receiving endpoint, even though the 1645 data in the attacking packet might not finally be delivered by the 1646 transport layer. This is sometimes known as a "shadowing attack". 1647 An attack can, for example, disrupt receiver processing, trigger loss 1648 and retransmission, or make a receiving endpoint perform unproductive 1649 decryption of packets that cannot be successfully decrypted (forcing 1650 a receiver to commit decryption resources, or to update and then 1651 restore protocol state). 1653 One mitigation to off-path attack is to deny knowledge of what header 1654 information is accepted by a receiver or obfuscate the accepted 1655 header information, e.g., setting a non-predictable initial value for 1656 a sequence number during a protocol handshake, as in [RFC3550] and 1657 [RFC6056], or a port value that cannot be predicted (see Section 5.1 1658 of [RFC8085]). A receiver could also require additional information 1659 to be used as a part of a validation check before accepting packets 1660 at the transport layer (e.g., utilising a part of the sequence number 1661 space that is encrypted; or by verifying an encrypted token not 1662 visible to an attacker). This would also mitigate against on-path 1663 attacks. An additional processing cost can be incurred when 1664 decryption is attempted before a receiver discards an injected 1665 packet. 1667 The existence of open transport protocol standards, and a research 1668 and operations community with a history of independent observation 1669 and evaluation of performance data, encourages fairness and 1670 conformance to those standards. This suggests careful consideration 1671 will be made over where, and when, measurement samples are collected. 1672 An appropriate balance between encrypting some or all of the 1673 transport header information needs to be considered. Open data, and 1674 accessibility to tools that can help understand trends in application 1675 deployment, network traffic and usage patterns can all contribute to 1676 understanding security challenges. 1678 The Security and Privacy Considerations in the Framework for Large- 1679 Scale Measurement of Broadband Performance (LMAP) [RFC7594] contain 1680 considerations for Active and Passive measurement techniques and 1681 supporting material on measurement context. 1683 Addition of observable transport information to the path increases 1684 the information available to an observer and may, when this 1685 information can be linked to a node or user, reduce the privacy of 1686 the user. See the security considerations of [RFC8558]. 1688 9. IANA Considerations 1690 This memo includes no request to IANA. 1692 10. Acknowledgements 1694 The authors would like to thank Mohamed Boucadair, Spencer Dawkins, 1695 Tom Herbert, Jana Iyengar, Mirja Kuehlewind, Kyle Rose, Kathleen 1696 Moriarty, Al Morton, Chris Seal, Joe Touch, Brian Trammell, Chris 1697 Wood, Thomas Fossati, Mohamed Boucadair, Martin Thomson, David Black, 1698 Martin Duke, Joel Halpern and members of TSVWG for their comments and 1699 feedback. 1701 This work has received funding from the European Union's Horizon 2020 1702 research and innovation programme under grant agreement No 688421, 1703 and the EU Stand ICT Call 4. The opinions expressed and arguments 1704 employed reflect only the authors' view. The European Commission is 1705 not responsible for any use that might be made of that information. 1707 This work has received funding from the UK Engineering and Physical 1708 Sciences Research Council under grant EP/R04144X/1. 1710 11. Informative References 1712 [bufferbloat] 1713 Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in 1714 the Internet. Communications of the ACM, 55(1):57-65", 1715 January 2012. 1717 [I-D.ietf-6man-ipv6-alt-mark] 1718 Fioccola, G., Zhou, T., Cociglio, M., and F. Qin, "IPv6 1719 Application of the Alternate Marking Method", draft-ietf- 1720 6man-ipv6-alt-mark-00 (work in progress), May 2020. 1722 [I-D.ietf-ippm-ioam-data] 1723 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 1724 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 1725 progress), July 2020. 1727 [I-D.ietf-quic-transport] 1728 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1729 and Secure Transport", draft-ietf-quic-transport-29 (work 1730 in progress), June 2020. 1732 [I-D.ietf-tls-dtls13] 1733 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1734 Datagram Transport Layer Security (DTLS) Protocol Version 1735 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1736 2020. 1738 [I-D.ietf-tsvwg-rtcweb-qos] 1739 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1740 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 1741 qos-18 (work in progress), August 2016. 1743 [I-D.marx-qlog-main-schema] 1744 Marx, R., "Main logging schema for qlog", draft-marx-qlog- 1745 main-schema-02 (work in progress), November 2020. 1747 [I-D.trammell-plus-abstract-mech] 1748 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1749 Layer under Endpoint Control", draft-trammell-plus- 1750 abstract-mech-00 (work in progress), September 2016. 1752 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1753 Techniques and Their Merits, IEEE Comm. Surveys & 1754 Tutorials. 26;18(3) p2149-2196", November 2014. 1756 [Measurement] 1757 Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- 1758 based Protocol Design, Eur. Conf. on Networks and 1759 Communications, Oulu, Finland.", June 2017. 1761 [PAM-RTT] Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 1762 Implications of Two-Way Internet Latency Data (in Proc. 1763 PAM 2018)", March 2018. 1765 [Quic-Trace] 1766 "https:QUIC trace utilities //github.com/google/quic- 1767 trace". 1769 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1770 DOI 10.17487/RFC0791, September 1981, 1771 . 1773 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1774 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 1775 November 1998, . 1777 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1778 "Definition of the Differentiated Services Field (DS 1779 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1780 DOI 10.17487/RFC2474, December 1998, 1781 . 1783 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1784 and W. Weiss, "An Architecture for Differentiated 1785 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1786 . 1788 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1789 Compression", RFC 2507, DOI 10.17487/RFC2507, February 1790 1999, . 1792 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1793 Headers for Low-Speed Serial Links", RFC 2508, 1794 DOI 10.17487/RFC2508, February 1999, 1795 . 1797 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1798 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1799 . 1801 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1802 of Explicit Congestion Notification (ECN) to IP", 1803 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1804 . 1806 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1807 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1808 . 1810 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1811 A., Peterson, J., Sparks, R., Handley, M., and E. 1812 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1813 DOI 10.17487/RFC3261, June 2002, 1814 . 1816 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1817 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1818 DOI 10.17487/RFC3393, November 2002, 1819 . 1821 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1822 Jacobson, "RTP: A Transport Protocol for Real-Time 1823 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1824 July 2003, . 1826 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1827 Text on Security Considerations", BCP 72, RFC 3552, 1828 DOI 10.17487/RFC3552, July 2003, 1829 . 1831 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1832 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1833 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1834 . 1836 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1837 DOI 10.17487/RFC4302, December 2005, 1838 . 1840 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1841 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1842 . 1844 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1845 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1846 July 2006, . 1848 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1849 "Extended RTP Profile for Real-time Transport Control 1850 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1851 DOI 10.17487/RFC4585, July 2006, 1852 . 1854 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1855 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1856 DOI 10.17487/RFC4737, November 2006, 1857 . 1859 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1860 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1861 . 1863 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 1864 Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March 1865 2008, . 1867 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1868 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1869 . 1871 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 1872 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1873 DOI 10.17487/RFC5236, June 2008, 1874 . 1876 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 1877 RFC 5426, DOI 10.17487/RFC5426, March 2009, 1878 . 1880 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1881 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1882 March 2009, . 1884 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1885 Header Compression (ROHC) Framework", RFC 5795, 1886 DOI 10.17487/RFC5795, March 2010, 1887 . 1889 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1890 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1891 June 2010, . 1893 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1894 Protocol Port Randomization", BCP 156, RFC 6056, 1895 DOI 10.17487/RFC6056, January 2011, 1896 . 1898 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1899 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1900 DOI 10.17487/RFC6269, June 2011, 1901 . 1903 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 1904 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 1905 2011, . 1907 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1908 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1909 January 2012, . 1911 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1912 "IPv6 Flow Label Specification", RFC 6437, 1913 DOI 10.17487/RFC6437, November 2011, 1914 . 1916 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1917 for Equal Cost Multipath Routing and Link Aggregation in 1918 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1919 . 1921 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 1922 "RObust Header Compression (ROHC): A Profile for TCP/IP 1923 (ROHC-TCP)", RFC 6846, DOI 10.17487/RFC6846, January 2013, 1924 . 1926 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1927 Morris, J., Hansen, M., and R. Smith, "Privacy 1928 Considerations for Internet Protocols", RFC 6973, 1929 DOI 10.17487/RFC6973, July 2013, 1930 . 1932 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1933 Flow Label for Load Balancing in Server Farms", RFC 7098, 1934 DOI 10.17487/RFC7098, January 2014, 1935 . 1937 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1938 on Filtering of IPv4 Packets Containing IPv4 Options", 1939 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1940 . 1942 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1943 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1944 2014, . 1946 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1947 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1948 . 1950 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1951 Zimmermann, "A Roadmap for Transmission Control Protocol 1952 (TCP) Specification Documents", RFC 7414, 1953 DOI 10.17487/RFC7414, February 2015, 1954 . 1956 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1957 Recommendations Regarding Active Queue Management", 1958 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1959 . 1961 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1962 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1963 Measurement of Broadband Performance (LMAP)", RFC 7594, 1964 DOI 10.17487/RFC7594, September 2015, 1965 . 1967 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1968 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1969 August 2015, . 1971 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1972 Trammell, B., Huitema, C., and D. Borkmann, 1973 "Confidentiality in the Face of Pervasive Surveillance: A 1974 Threat Model and Problem Statement", RFC 7624, 1975 DOI 10.17487/RFC7624, August 2015, 1976 . 1978 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1979 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1980 May 2016, . 1982 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1983 "Observations on the Dropping of Packets with IPv6 1984 Extension Headers in the Real World", RFC 7872, 1985 DOI 10.17487/RFC7872, June 2016, 1986 . 1988 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 1989 D. Ros, "Characterization Guidelines for Active Queue 1990 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1991 2016, . 1993 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1994 Updates for Secure Real-time Transport Protocol (SRTP) 1995 Extension for Datagram Transport Layer Security (DTLS)", 1996 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1997 . 1999 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 2000 "Proportional Integral Controller Enhanced (PIE): A 2001 Lightweight Control Scheme to Address the Bufferbloat 2002 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 2003 . 2005 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2006 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2007 . 2009 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2010 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2011 March 2017, . 2013 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2014 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2015 March 2017, . 2017 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 2018 Explicit Congestion Notification (ECN)", RFC 8087, 2019 DOI 10.17487/RFC8087, March 2017, 2020 . 2022 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 2023 Ed., "Services Provided by IETF Transport Protocols and 2024 Congestion Control Mechanisms", RFC 8095, 2025 DOI 10.17487/RFC8095, March 2017, 2026 . 2028 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2029 (IPv6) Specification", STD 86, RFC 8200, 2030 DOI 10.17487/RFC8200, July 2017, 2031 . 2033 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 2034 Performance and Diagnostic Metrics (PDM) Destination 2035 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 2036 . 2038 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 2039 Iyengar, Ed., "Controlled Delay Active Queue Management", 2040 RFC 8289, DOI 10.17487/RFC8289, January 2018, 2041 . 2043 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 2044 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 2045 and Active Queue Management Algorithm", RFC 8290, 2046 DOI 10.17487/RFC8290, January 2018, 2047 . 2049 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 2050 Pervasive Encryption on Operators", RFC 8404, 2051 DOI 10.17487/RFC8404, July 2018, 2052 . 2054 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2055 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2056 . 2058 [RFC8462] Rooney, N. and S. Dawkins, Ed., "Report from the IAB 2059 Workshop on Managing Radio Networks in an Encrypted World 2060 (MaRNEW)", RFC 8462, DOI 10.17487/RFC8462, October 2018, 2061 . 2063 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 2064 Jacquenet, "An Inventory of Transport-Centric Functions 2065 Provided by Middleboxes: An Operator Perspective", 2066 RFC 8517, DOI 10.17487/RFC8517, February 2019, 2067 . 2069 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 2070 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2071 2019, . 2073 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 2074 Q., and E. Smith, "Cryptographic Protection of TCP Streams 2075 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 2076 . 2078 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 2079 RFC 8558, DOI 10.17487/RFC8558, April 2019, 2080 . 2082 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 2083 Paasch, "TCP Extensions for Multipath Operation with 2084 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2085 2020, . 2087 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 2088 Sustain Extensibility (GREASE) to TLS Extensibility", 2089 RFC 8701, DOI 10.17487/RFC8701, January 2020, 2090 . 2092 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2093 Zuniga, "SCHC: Generic Framework for Static Context Header 2094 Compression and Fragmentation", RFC 8724, 2095 DOI 10.17487/RFC8724, April 2020, 2096 . 2098 [RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, 2099 "Differentiated Services Code Point (DSCP) Packet Markings 2100 for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January 2101 2021, . 2103 [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. 2104 Wood, "A Survey of the Interaction between Security 2105 Protocols and Transport Services", RFC 8922, 2106 DOI 10.17487/RFC8922, October 2020, 2107 . 2109 Appendix A. Revision information 2111 -00 This is an individual draft for the IETF community. 2113 -01 This draft was a result of walking away from the text for a few 2114 days and then reorganising the content. 2116 -02 This draft fixes textual errors. 2118 -03 This draft follows feedback from people reading this draft. 2120 -04 This adds an additional contributor and includes significant 2121 reworking to ready this for review by the wider IETF community Colin 2122 Perkins joined the author list. 2124 Comments from the community are welcome on the text and 2125 recommendations. 2127 -05 Corrections received and helpful inputs from Mohamed Boucadair. 2129 -06 Updated following comments from Stephen Farrell, and feedback via 2130 email. Added a draft conclusion section to sketch some strawman 2131 scenarios that could emerge. 2133 -07 Updated following comments from Al Morton, Chris Seal, and other 2134 feedback via email. 2136 -08 Updated to address comments sent to the TSVWG mailing list by 2137 Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 2138 11/05/2018, and Spencer Dawkins. 2140 -09 Updated security considerations. 2142 -10 Updated references, split the Introduction, and added a paragraph 2143 giving some examples of why ossification has been an issue. 2145 -01 This resolved some reference issues. Updated section on 2146 observation by devices on the path. 2148 -02 Comments received from Kyle Rose, Spencer Dawkins and Tom 2149 Herbert. The network-layer information has also been re-organised 2150 after comments at IETF-103. 2152 -03 Added a section on header compression and rewriting of sections 2153 referring to RTP transport. This version contains author editorial 2154 work and removed duplicate section. 2156 -04 Revised following SecDir Review 2157 o Added some text on TLS story (additional input sought on relevant 2158 considerations). 2160 o Section 2, paragraph 8 - changed to be clearer, in particular, 2161 added "Encryption with secure key distribution prevents" 2163 o Flow label description rewritten based on PS/BCP RFCs. 2165 o Clarify requirements from RFCs concerning the IPv6 flow label and 2166 highlight ways it can be used with encryption. (section 3.1.3) 2168 o Add text on the explicit spin-bit work in the QUIC DT. Added 2169 greasing of spin-bit. (Section 6.1) 2171 o Updated section 6 and added more explanation of impact on 2172 operators. 2174 o Other comments addressed. 2176 -05 Editorial pass and minor corrections noted on TSVWG list. 2178 -06 Updated conclusions and minor corrections. Responded to request 2179 to add OAM discussion to Section 6.1. 2181 -07 Addressed feedback from Ruediger and Thomas. 2183 Section 2 deserved some work to make it easier to read and avoid 2184 repetition. This edit finally gets to this, and eliminates some 2185 duplication. This also moves some of the material from section 2 to 2186 reform a clearer conclusion. The scope remains focussed on the usage 2187 of transport headers and the implications of encryption - not on 2188 proposals for new techniques/specifications to be developed. 2190 -08 Addressed feedback and completed editorial work, including 2191 updating the text referring to RFC7872, in preparation for a WGLC. 2193 -09 Updated following WGLC. In particular, thanks to Joe Touch 2194 (specific comments and commentary on style and tone); Dimitri Tikonov 2195 (editorial); Christian Huitema (various); David Black (various). 2196 Amended privacy considerations based on SECDIR review. Emile Stephan 2197 (inputs on operations measurement); Various others. 2199 Added summary text and refs to key sections. Note to editors: The 2200 section numbers are hard-linked. 2202 -10 Updated following additional feedback from 1st WGLC. Comments 2203 from David Black; Tommy Pauly; Ian Swett; Mirja Kuehlewind; Peter 2204 Gutmann; Ekr; and many others via the TSVWG list. Some people 2205 thought that "needed" and "need" could 2207 represent requirements in the document, etc. this has been clarified. 2209 -11 Updated following additional feedback from Martin Thomson, and 2210 corrections from other reviewers. 2212 -12 Updated following additional feedback from reviewers. 2214 -13 Updated following 2nd WGLC with comments from D.L.Black; T. 2215 Herbert; Ekr; and other reviewers. 2217 -14 Update to resolve feedback to rev -13. This moves the general 2218 discussion of adding fields to transport packets to section 6, and 2219 discusses with reference to material in RFC8558. 2221 -15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins 2222 and M. Duke. Update to add reference to RFC7605. Clarify a focus 2223 on immutable transport fields, rather than modifying middleboxes with 2224 Tom H. Clarified Header Compression discussion only provides a list 2225 of examples of HC methods for transport. Clarified port usage with 2226 Tom H/Joe T. Removed some duplicated sentences, and minor edits. 2227 Added NULL-ESP. Improved after initial feedback from Martin Duke. 2229 -16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3. 2231 -17 Revised to satisfy ID-NITs and updates REFs to latest rev, 2232 updated HC Refs; cited IAB guidance on security and privacy within 2233 IETF specs. 2235 -18 Revised based on AD review. 2237 -19 Revised after additional AD review request, and request to 2238 restructure. 2240 -20 Revised after directorate reviews and IETF LC comments. 2242 Gen-ART: 2244 o While section 2 does include a discussion of traffic mis-ordering, 2245 it does not include a discussion of ECMP, and the dependence of 2246 ECMP on flow identification to avoid significant packet mis- 2247 ordering.:: ECMP added as example. 2249 o Section 5.1 of this document discusses the use of Hop-by-Hop IPv6 2250 options. It seems that it should acknowledge and discuss the 2251 applicability of the sentence "New hop-by-hop options are not 2252 recommended..." from section 4.8 of RFC 8200. I think a good 2253 argument can be made in this case as to why (based on the rest of 2254 the sentence from 8200) the recommendation does not apply to this 2255 proposal. The document should make the argument.:: Quoted RFC 2256 sentences directly to avoid interpretting them. 2258 o I found the discussion of header compression slightly confusing. 2259 Given that the TCP / UDP header is small even compared to the IP 2260 header, it is difficult to see why encrypting it would have a 2261 significant impact on header compression efficacy. :: Added a 2262 preface that explains that HC methods are most effective for bit- 2263 congestive links. 2265 o The wording in section 6.2 on adding header information to an IP 2266 packet has the drawback of seeming to imply that one could add (or 2267 remove) such information in the network, without adding an 2268 encapsulating header. That is not permitted by RFC 8200 (IPv6). 2269 It would be good to clarify the first paragraph. (The example, 2270 which talks about the sender putting in the information is, of 2271 course, fine.) :: Unintended - added a sentence of preface. 2273 SECDIR:: Previous revisions were updated following Early Review 2274 comments. 2276 OPSEC:: No additional changes were requested in the OPSEC review. 2278 IETF LC:: Tom Herbert: Please refer to 8200 on EH :: addressed in 2279 response to Joel above. Michael Richardson, Fernando Gont, Tom 2280 Herbert: Continuation of discussion on domains where EH might be (or 2281 not) useful and the tussle on what information to reveal. Unclear 2282 yet what additional text should be changed within this ID. 2284 ------------ 2286 - 21 Revised after IESG review: 2288 Revision 21 includes revised text after comments from Zahed, Erik 2289 Kline, Rob Wilton, Eric Vyncke, Roman Danyliw, and Benjamin Kaduk. 2291 Authors' Addresses 2292 Godred Fairhurst 2293 University of Aberdeen 2294 Department of Engineering 2295 Fraser Noble Building 2296 Aberdeen AB24 3UE 2297 Scotland 2299 EMail: gorry@erg.abdn.ac.uk 2300 URI: http://www.erg.abdn.ac.uk/ 2302 Colin Perkins 2303 University of Glasgow 2304 School of Computing Science 2305 Glasgow G12 8QQ 2306 Scotland 2308 EMail: csp@csperkins.org 2309 URI: https://csperkins.org/