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