idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2017) is 2397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'I-D.dolson-plus-middlebox-benefits' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-accurate-ecn' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-plus-statefulness' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'RFC3449' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 1152, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'RFC6679' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'RFC7713' is defined on line 1235, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-00 == Outdated reference: A later version (-06) exists of draft-ietf-aqm-fq-codel-00 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-00 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-00 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-06 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-00 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-11 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C.S. Perkins 5 Expires: March 29, 2018 University of Glasgow 6 September 27, 2017 8 The Impact of Transport Header Encryption on Operation and Evolution of 9 the Internet 10 draft-fairhurst-tsvwg-transport-encrypt-04 12 Abstract 14 This document describes implications of applying end-to-end 15 encryption at the transport layer. It identifies some in-network 16 uses of transport layer header information that can be used with a 17 transport header integrity check. It reviews the implication of 18 developing encrypted end-to-end transport protocols and examines the 19 implication of developing and deploying encrypted end-to-end 20 transport protocols. Since transport measurement and analysis of the 21 impact of network characteristics have been important to the design 22 of current transport protocols, it also considers some anticipated 23 implications on transport and application evolution. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 29, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Current uses of Transport Headers within the Network . . . 6 60 1.1.1. Observing Transport Information in the Network . . . . 7 61 1.1.1.1. Flow Identification . . . . . . . . . . . . . . . 7 62 1.1.1.2. Metrics derived from Transport Layer Headers . . . 7 63 1.1.1.3. Metrics derived from Network Layer Headers . . . . 10 64 1.1.2. Transport Measurement . . . . . . . . . . . . . . . . 12 65 1.1.2.1. Point of Measurement . . . . . . . . . . . . . . . 12 66 1.1.2.2. Use by Operators to Plan and Provision Networks . 13 67 1.1.2.3. Service Performance Measurement . . . . . . . . . 13 68 1.1.2.4. Measuring Transport to Support Network Operations 13 69 1.1.3. Use for Network Diagnostics and Troubleshooting . . . 15 70 1.1.4. Observing Headers to Implement Network Policy . . . . 15 71 2. Encryption and Authentication of Transport Headers . . . . . . 15 72 2.1. Authenticating the Transport Protocol Header . . . . . . . 17 73 2.2. Encrypting the Transport Payload . . . . . . . . . . . . . 17 74 2.3. Encrypting the Transport Header . . . . . . . . . . . . . 18 75 2.4. Authenticating Transport Information and Selectively 76 Encrypting the Transport Header . . . . . . . . . . . . . 18 77 2.5. Adding Transport Information to Network-Layer Protocol 78 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 3. Implications of Protecting the Transport Headers . . . . . . . 19 80 3.1. Independent Measurement . . . . . . . . . . . . . . . . . 19 81 3.2. Characterising "Unknown" Network Traffic . . . . . . . . . 20 82 3.3. Accountability and Internet Transport Protocols . . . . . 20 83 3.4. Impact on Research, Development and Deployment . . . . . . 21 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Appendix A. Revision information . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 This document discusses the implications of end-to-end encryption 96 applied at the transport layer, and examines the impact on transport 97 protocol design, usage, and network operations and management. It 98 also considers anticipated implications on transport and application 99 evolution. 101 The transport layer provides the first end-to-end interactions across 102 the Internet. Transport protocols layer directly over the network- 103 layer service and are sent in the payload of network-layer packets. 104 They support end-to-end communication between applications, supported 105 by higher-layer protocols, running on the end systems (or transport 106 endpoint). This simple architectural view hides one of the core 107 functions of the transport, however - to discover and adapt to the 108 properties of the Internet path that is currently being used. The 109 design of Internet transport protocols is as much about trying to 110 avoid the unwanted side effects of congestion on a flow and other 111 capacity-sharing flows, avoiding congestion collapse, adapting to 112 changes in the path characteristics, etc., as it is about end-to-end 113 feature negotiation, flow control and optimising for performance of a 114 specific application. 116 To achieve stable Internet operations the IETF transport community 117 has to date relied heavily on measurement and insights of the network 118 operations community to understand the trade-offs, and to inform 119 selection of select appropriate mechanisms, to ensure a safe, 120 reliable and robust Internet. In turn, the network operations 121 community relies on being able to understand the traffic passing over 122 the Internet, both in aggregate and at the flow level -- inspecting 123 transport layer headers to help understand traffic dynamics. 125 There are many motivations for deploying encrypted transports, and 126 encryption of transport payloads. The increasing public concerns 127 about the interference with Internet traffic have led to a rapidly 128 expanding deployment of encryption to protect end-user privacy, in 129 protocols like QUIC. At the same time, network operators and access 130 providers, especially in mobile networks, have come to rely on the 131 in-network measurement of transport properties and the functionality 132 provided by middleboxes to both support network operations and 133 enhance performance. 135 This document considers some implications of working with encrypted 136 transport protocols, and discusses trade-offs around authentication, 137 encryption of transport protocol headers. It describes some of the 138 architectural challenges and considerations in the way transport 139 protocols are designed when using encryption [Measure]. 141 Encryption of the transport layer brings some well-known privacy and 142 security benefits, but also introduces various costs that need to be 143 considered. Specifically, it can impact the following activities 144 that rely on measurement and analysis of traffic flows: 146 o Network Operations and Research: Observable transport headers 147 enable operators and the research community to measure and analyse 148 protocol performance, network anomalies, and failure pathologies. 149 This information can help inform capacity planning, and assist in 150 determining the need for equipment and/or configuration changes by 151 network operators. This data also can inform Internet engineering 152 research, and help the develop of new protocols and procedures. 153 Encryption of the entire transport protocol, including header 154 information, will restrict the availability of data, and might 155 lead to the development of alternative, and potentially more 156 intrusive, methods to acquire the needed data. Encrypting the 157 transport payload, but leaving some, or all, of the transport 158 headers unencrypted but authenticated can provide the majority of 159 the privacy and security benefits while allowing some measurement. 161 o Network Troubleshooting and diagnostics: Encrypting transport 162 header information eliminates the incentive for operators to 163 troubleshoot what they cannot interpret. A flow experiencing 164 packet loss looks like an unaffected flow when only observing 165 network layer headers (if transport sequence numbers and flow 166 identifiers are obscured). This limits understanding of the impact 167 of packet loss on the flows that share a network segment. 168 Encrypted traffic therefore implies "don't touch", and a likely 169 trouble-shooting response will be "can't help, no trouble found". 170 The additional mechanisms that will need to be introduced to help 171 reconstruct transport-level metrics add complexity and operational 172 costs [I-D.mm-wg-effect-encrypt]. 174 o Network Traffic Analysis: The use of encryption can make it harder 175 to determine which transport protocols and features are being used 176 across a network segment. The trends in usage. This could impact 177 the ability for an operator to anticipate the need for network 178 upgrades and roll-out. It can also impact the on-going traffic 179 engineering activities performed by operators. While the impact 180 may, in many cases, be small there are scenarios where operators 181 directly support particular services (e.g., in radio links, or to 182 troubleshoot issues realting to Quality of Service, QoS). The more 183 complex the underlying infrastructure the more important this 184 impact. 186 o Open and Verifiable Network Data: The use of transport header 187 encryption reduces the range of actors that can capture useful 188 measurement data. This is, of course, its goal. Doing so, 189 however, limits the information sources available to the Internet 190 community to understand the operation of transport protocols, so 191 preventing access to the information necessary to inform design 192 decisions and standards for new protocols and related operational 193 practices. There are dangers in a model where only endpoints 194 (i.e., at user devices and within service platforms) can observe 195 performance, and this cannot be independently verified. To ensure 196 the health of the standards and research communities, we need 197 independently captured data to develop on the behaviour of the 198 transports. Independently verifiable performance metrics might 199 also important in order to demonstrate regulatory compliance in 200 some jurisdictions. 202 The last point leads us to consider the impact of encrypting all the 203 transport headers the specification and development of protocols and 204 standards. It has potential impact on: 206 o Understanding Feature Interactions: An appropriate vantage point, 207 coupled with timing information about traffic flows, provides a 208 valuable tool for benchmarking equipment and/or configurations, 209 and to understand complex feature interactions. Transport header 210 encryption limits the ability to diagnose and explore interactions 211 between features at different protocol layers, a side-effect of 212 not allowing a choice of vantage point from which this information 213 is observed. 215 o Supporting Common Specifications: The Transmission Control Protocl 216 (TCP) is the predominant transport protocol. Its many variants 217 have broadly consistent approaches to avoiding congestion 218 collapse, and to ensuring the stability of the network. Increased 219 use of transport layer encryption can overcome ossification, 220 allowing deployment of new transports with different types of 221 congestion control. This flexibility can be beneficial, but it 222 comes at the cost of fragmenting the ecosystem. There's little 223 doubt that developers will try to produce high quality transports 224 for their target uses, but it is not clear there are sufficient 225 incentives to ensure good practice that benefits the wide 226 diversity of requirements for the Internet community as a whole. 227 Increased diversity, and the ability to innovate without public 228 scrutiny, risks point solutions that optimise for specific needs, 229 but accidentally disrupt operations of/in different parts of the 230 network. The social compact that maintains the stability of the 231 network relies on accepting common specifications, and on the 232 ability to verify that others also conform. 234 o Operational practice: Published transport specifications allow 235 operators to check compliance. This can bring assurance to those 236 operating networks, often avoiding the need to deploy complex 237 techniques that routinely monitor and manage TCP/IP traffic flows 238 (e.g. Avoiding the capital and operational costs of deploying 239 flow rate-limiting and network circuit-breaker methods). This 240 should continue when encrypted transport headers are used, but 241 methods need to confirm that the traffic produced conforms to the 242 expectations of the operator or developer. 244 o Restricting research and development: The use of encryption may 245 impede independent research into new mechanisms, measurement of 246 behaviour, and development initiatives. Experience shows that 247 transport protocols are complicated to design and complex to 248 deploy, and that individual mechanisms need to be evaluated while 249 considering other mechanism, across a broad range of network 250 topologies and with attention to the impact on traffic sharing the 251 capacity. Adopting pervasive encryption of transport information 252 could eliminate the independent self-checks that have previously 253 been in place from research and academic contributors (e.g., the 254 role of the IRTF ICCRG, and research publications in reviewing new 255 transport mechanisms and assessing the impact of their 256 experimental deployment). 258 Pervasive use of transport header encryption can impact the ways that 259 protocols are designed, standardised, deployed, and operated. The 260 choice of whether future transport protocols encrypt their protocol 261 headers therefore needs to be taken based not solely on security and 262 privacy considerations, but also taking into account the impact on 263 operations, standards, and research. A network that is secure but 264 unusable due to persistent congestion collapse is not an improvement, 265 and while that would be an extreme outcome proposals that impose high 266 costs for very limited benefits need to be considered carefully, to 267 ensure the benefits outweigh the costs. 269 1.1. Current uses of Transport Headers within the Network 271 The transport layer is the first end-to-end layer in the network 272 stack. Despite headers having end-to-end meaning, some transport 273 headers have come to be used in various ways within the Internet. In 274 response to pervasive monitoring [RFC7624] revelations and the IETF 275 consensus that "Pervasive Monitoring is an Attack" [RFC7258], efforts 276 are underway to increase encryption of Internet traffic, which would 277 prevent visibility of transport headers. This affects on how network 278 protocols are designed and used [I-D.mm-wg-effect-encrypt]. To 279 understand these implications, it is first necessary to understand 280 how transport layer headers are currently observed and/or modified by 281 middleboxes within the network. 283 Transport protocols can be designed to encrypt or authenticate 284 transport header fields. Authentication methods at the transport 285 layer can be sued to detect any changes to an immutable header field 286 that were made by a network device along a path. The intentional 287 modification of transport headers by middleboxes (such as Network 288 Address Translation with Protocol Translation, NAT-PT, or Firewalls) 289 is not considered. 291 1.1.1. Observing Transport Information in the Network 293 In-network observation of transport protocol headers requires 294 knowledge of the format of the transport header: 296 o Flows need to be identified at the level required for monitoring; 298 o The protocol and version of the header need to be observable. As 299 protocols evolve over time and there may be a need to introduce 300 new transport headers. This may require interpretation of 301 protocol version information or connection setup information; 303 o Location and syntax of any transport headers to be observed. IETF 304 transport protocols specify this information. 306 The following subsections describe various ways that observable 307 transport information may be utilised. 309 1.1.1.1. Flow Identification 311 Transport protocol header information can identify a flow and the 312 connection state of the flow, together with the protocol options 313 being used. In some usages, a low-numbered (well-known ) port can 314 identify a protocol (although port information alone is not 315 sufficient to guarantee identification of a protocol). Transport 316 protocols, such as TCP and Stream Control Transport Protocol (SCTP) 317 specify a standard base header that includes sequence number 318 information and other data, with the possibility to negotiate 319 additional headers at connection setup, identified by an option 320 number in the transport header. UDP-based protocols can use, but 321 sometimes do not use, well-known ports. Some can instead be 322 identified by signalling protocols or through the use of magic 323 numbers placed in the first byte(s) of the datagram payload. 325 1.1.1.2. Metrics derived from Transport Layer Headers 327 Some actors have a need to characterise the performance of link/ 328 network segments. Passive monitoring uses observed traffic to makes 329 inferences from transport headers to derive these measurements. A 330 variety of open source and commercial tools have been deployed that 331 utilise this information. The following metrics can be derived from 332 transport header information: 334 Traffic Rate and Volume: Header infromation may allow derivation of 335 volume measures per-application, to characterise the traffic that 336 uses a network segment or the pattern of network usage. This may 337 be measured per endpoint or aggregate of endpoint (e.g., by an 338 operator to assess subscriber usage). It can also be used to 339 trigger measurement-based traffic shaping and to implement QoS 340 support within the network and lower layers. Volume measures can 341 be valuable for capacity planning (providing detail of trends 342 rather than the volume per subscriber). 344 Loss Rate and Loss Pattern: Flow loss rate may be derived and is 345 often used as a metric for performance assessment and to 346 characterise transport behaviour. Understanding the root cause of 347 loss can help an operator determine whether this requires 348 corrective action. 350 There are various cause of loss, including: corruption on a link 351 (e.g., interference on a radio link), buffer overflow (e.g., due 352 to congestion), policing (traffic management), buffer management 353 (e.g., Active Queue Management, AQM). Understanding flow loss 354 rate requires either maintaining per flow packet counters or by 355 observing sequence numbers in transport headers. Loss can be 356 monitored at the interface level by devices in the network. It is 357 often important to understand the conditions under which packet 358 loss occurs. This usually requires relating loss to the traffic 359 flowing on the network segment at the time of loss. 361 Observation of transport feedback information (observing loss 362 reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase 363 understanding of the impact of loss and help identify cases where 364 loss may have been wrongly identified, or the transport did not 365 require the lost packet. It is sometimes more important to 366 understand the pattern of loss, than the loss rate - since losses 367 can often occur as bursts, rather than randomly-timed events. 369 Throughput and Goodput: The throughput observed by a flow can be 370 determined even when a flow is encrypted, providing the individual 371 flow can be identified. Goodput [RFC7928] is a measure of useful 372 data exchanged (the ratio of useful/total volume of traffic sent 373 by a flow), which requires ability to differentiate loss and 374 retransmission of packets (e.g., by observing packet sequence 375 numbers in the TCP or the Real Time Protocol, RTP, headers 377 [RFC3550]). 379 Latency: Latency is a key performance metric that impacts application 380 response time and user-perceived response time. It often 381 indirectly impacts throughput and flow completion time. Latency 382 determines the reaction time of the transport protocol itself, 383 impacting flow setup, congestion control, loss recovery, and other 384 transport mechanisms. The observed latency can have many 385 components [Latency]. Of these, unnecessary/unwanted queuing in 386 network buffers has often been observed as a significant factor. 387 Once the cause of unwanted latency has been identified, this can 388 often be eliminated, and determining latency metrics is a key 389 driver in the deployment of AQM [RFC7567], DiffServ [RFC2474], and 390 Explicit Congestion Notification (ECN) [RFC3168] [RFC8087]. 392 To measure latency across a part of the path, an observation point 393 can measure the experienced round trip time (RTT) using packet 394 sequence numbers, and acknowledgements, or by observing header 395 timestamp information. Such information allows an observation 396 point in the network to determine not only the path RTT, but also 397 to measure the upstream and downstream contribution to the RTT. 398 This may be used to locate a source of latency, e.g., by observing 399 cases where the ratio of median to minimum RTT is large for a part 400 of a path. 402 An example usage of this method could identify excessive buffers 403 to help deploy or configure AQM [RFC7567] [RFC7928] to effectively 404 eliminate unnecessary queuing in routers and other devices. AQM 405 methods need to be deployed at the capacity bottleneck, but are 406 often deployed in combination with other techniques, such as 407 scheduling [RFC7567] [I-D.ietf-aqm-fq-codel] and although 408 parameter-less methods are desired [RFC7567], current methods [I-D 409 .ietf-aqm-fq-codel] [I-D.ietf-aqm-codel] [I-D.ietf-aqm-pie] often 410 cannot scale across all possible deployment scenarios. The 411 service offered by operators can therefore benefit from latency 412 information to understand the impact of deployment and tune 413 deployed services. 415 Jitter: Some network applications are sensitive to changes in packet 416 timing. For such applications, it can be necessary to measure the 417 jitter observed along a portion of the path. The requirements to 418 measure jitter resemble those for the measurement of latency. 420 Flow Reordering: Significant flow reordering can impact time-critical 421 applications and can be interpreted as loss by reliable 422 transports. Many transport protocol techniques are impacted by 423 reordering (e.g., triggering TCP retransmission, or re-buffering 424 of real-time applications). Packet reordering can occur for many 425 reasons (from equipment design to misconfiguration of forwarding 426 rules). 428 As in the drive to reduce network latency, there is a need for 429 operational tools to detect mis-ordered packet flows and quantify 430 the degree or reordering. Techniques for measuring reordering 431 typically observe packet sequence numbers. Metrics have been 432 defined that evaluate whether a network has maintained packet 433 order on a packet-by-packet basis [RFC4737] and [RFC5236]. 435 There has been initiatives in the IETF transport area to reduce 436 the impact of reordering within a transport flow, possibly leading 437 to reduced the requirements for ordering. These have promise to 438 simplify network equipment design as well as the potential to 439 improve robustness of the transport service. Measurements of 440 reordering can help understand the level of reordering within 441 deployed infrastructure, and inform decisions about how to 442 progress such mechanisms. 444 Some protocols provide in-built monitoring and reporting functions. 445 Transport fields in the RTP header [RFC3550] [RFC4585] can be 446 observed to derive traffic volume measurements and provide 447 information on the progress and quality of a session using RTP. Key 448 performance indicators are retransmission rate, packet drop rate, 449 sector utilization level, a measure of reordering, peak rate, the CE- 450 marking rate, etc. Metadata is often important to understand the 451 context under which the data was collected, including the time, 452 observation point, and way in which metrics were accumulated. The 453 RTCP protocol directly reports some of this information in a form 454 that can be directly visible in the network. A user of summary 455 measurement data needs to trust the source of this data and the 456 method used to generate the summary information. 458 When encryption conceals information in packet headers, measurements 459 need to rely on pattern inferences and other heuristics grows, and 460 accuracy suffers [I-D.mm-wg-effect-encrypt]. 462 1.1.1.3. Metrics derived from Network Layer Headers 464 Some transport information is made visible in the network-layer 465 protocol header. These header fields are not encrypted and can be 466 used to make flow observations. 468 Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose 469 flow information in the IPv6 Flow Label field of the network-layer 470 header (e..g. [RFC8085]). This can be used to inform network- 471 layer queuing, forwarding (e.g., for equal cost multi-path (ECMP) 472 routing, and Link Aggregation, LAG). This can provide useful 473 information to assign packets to flows in the data collected by 474 measurement campaigns. Although important to characterising a 475 path, it does not directly provide any performance data. 477 Use Network-Layer Differentiated Services Code Point Point: Applicati 478 on can expose their delivery expectations to the network by 479 setting the Differentiated Services Code Point (DSCP) field of 480 IPv4 and IPv6 packets. This can be used to inform network-layer 481 queuing and forwarding, and can also provide information on the 482 relative importance of packet information collected by measurement 483 campaigns, but does not directly provide any performance data. 485 This field provides explicit information that can be used in place 486 of inferring traffic requirements (e.g., by inferring QoS 487 requirements from port information via a multi-field classifier). 488 The DSCP value can therefore impact the quality of experience for 489 a flow. Observations of service performance need to consider this 490 field when a network path has support for differentiated service 491 treatment. 493 Use of Explicit Congestion Marking: ECN[RFC3168] is an optional 494 transport mechanism that uses a code point in the network-layer 495 header. Use of ECN can offer gains in terms of increased 496 throughput, reduced delay, and other benefits when used over a 497 path that includes equipment that supports an AQM method that 498 performs Congestion Experienced (CE) marking of IP packets 499 [RFC8087]. 501 ECN exposes the presence of congestion on a network path to the 502 transport and network layer. The reception of CE-marked packets 503 can therefore be used to monitor the presence and estimate the 504 level of incipient congestion on the upstream portion of the path 505 from the point of observation (Section 2.5 of [RFC8087]). Because 506 ECN marks carried in the IP protocol header, it is much easier to 507 measure ECN than metering packet loss. However, interpreting the 508 marking behaviour (i.e., assessing congestion and diagnosing 509 faults) requires context from the transport layer (path RTT, 510 visibility of loss - that could be due to queue overflow, 511 congestion response, etc) [RFC7567]. 513 Some ECN-capable network devices can provide richer (more frequent 514 and fine-grained) indication of their congestion state. Setting 515 congestion marks proportional to the level of congestion (e.g., 516 Data Center TCP, DCTP [I-D.ietf-tcpm-dctcp], and Low Latency Low 517 Loss Scalable throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. 519 Use of ECN requires feedback a transport to feed back reception 520 information on the path towards the data sender. Exposure of this 521 Transport ECN feedback provides an additional powerful tool to 522 understand ECN-enabled AQM-based networks [RFC8087]. 524 AQM and ECN offer a range of algorithms and configuration options, 525 it is therefore important for tools to be available to network 526 operators and researchers to understand the implication of 527 configuration choices and transport behaviour as use of ECN 528 increases and new methods emerge [RFC7567] [RFC8087]. ECN- 529 monitoring is expected to become important as AQM is deployed that 530 supports ECN [RFC8087]. 532 1.1.2. Transport Measurement 534 The common language between network operators and application/content 535 providers/users is packet transfer performance at a layer that all 536 can view and analyse. For most packets, this has been transport 537 layer, until the emergence of QUIC, with the obvious exception of 538 VPNs and IPsec. When encryption conceals more layers in a packet, 539 people seeking understanding of the network operation need to rely 540 more on pattern inferences and other heuristics. The accuracy of 541 measurements therefore suffers, as does the ability to investigate 542 and troubleshoot interactions between different anomalies. For 543 example, the traffic patterns between a web server and a browser are 544 dependent on browser supplier and version, even use of the 545 application (e.g., web e-mail access). Even when measurement datasets 546 are made available (e.g., from endpoints) additional metadata, such 547 as the state of the network, is often required to interpret the data. 548 Collecting and coordinating such metadata is more difficult when the 549 observation point is at a different location to the bottleneck/device 550 under evaluation. 552 Packet sampling techniques can be used to scale the processing 553 involved in observing packets on high rate links. This exports only 554 the packet header information of (randomly) selected packets. The 555 utility of these measurements depends on the type of bearer and 556 number of mechanisms used by network devices. Simple routers are 557 relatively easy to manage, a device with more complexity demands 558 understanding of the choice of many system parameters. This level of 559 complexity exists when several network methods are combined. 561 This section discusses topics concerning observation of transport 562 flows, with a focus on transport measurement. 564 1.1.2.1. Point of Measurement 566 Often measurements can only be understood in the context of the other 567 flows that share a bottleneck. A simple example is monitoring of 568 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 569 queues (statistically assigned per flow), management of the queue 570 length (CODEL), flow-scheduling, and a starvation prevention 571 mechanism. Usually such algorithms are designed to be self-tuning, 572 but current methods typically employ heuristics that can result in 573 more loss under certain path conditions (e.g., large RTT, effects of 574 multiple bottlenecks [RFC7567]). 576 In-network measurements can distinguish between upstream and 577 downstream metrics with respect to the measurement point. These are 578 particularly useful for locating the source of problems or to assess 579 the performance of a network segment or a particular device 580 configuration. 582 By correlating observations at multiple points along the path (e.g., 583 at the ingress and egress of a network segment), an observer can 584 determine the contribution of a portion of the path to an observed 585 metric (to locate a source of delay, jitter, loss, reordering, 586 congestion marking, etc.). 588 1.1.2.2. Use by Operators to Plan and Provision Networks 590 Traffic measurements (e.g., traffic volume, loss, latency) is used by 591 operators to help plan deployment of new equipment and configurations 592 in their networks. Data is also important to equipment vendors who 593 need to understand traffic trends traffic and patterns of usage as 594 inputs to decisions about planning products and provisioning for new 595 deployments. This measurement information can also be correlated 596 with billing information when this is also collected by an operator. 598 A network operator supporting traffic that uses transport header 599 encryption may not have access to per-flow measurement data. Trends 600 in aggregate traffic can be observed and can be related this to the 601 endpoint addresses being used, but it may not be possible to 602 correlate patterns in measurements with changes in transport 603 protocols (e.g., the impact of changes in introducing a new transport 604 protocol mechanism). This increases the dependency on other indirect 605 sources of information to inform planning and provisioning. 607 1.1.2.3. Service Performance Measurement 609 Traffic measurements (e.g., traffic volume, loss, latency) can be 610 used by various actors to help analyse the performance available to 611 users of a network segment, and inform operational practice. While 612 active measurements may be used in-network passive measurements can 613 have advantages in terms of eliminating unproductive traffic, 614 reducing the influence of test traffic on the overall traffic mix, 615 and the ability to choose the point of measurement Section 1.1.2.1. 617 1.1.2.4. Measuring Transport to Support Network Operations 618 Information provided by tools observing transport headers can help 619 determine whether mechanisms are needed in the network to prevent 620 flows from acquiring excessive network capacity. Operators can 621 implement operational practices to manage traffic flows (e.g., to 622 prevent flows from acquiring excessive network capacity under severe 623 congestion) by deploying rate-limiters, traffic shaping or network 624 transport circuit breakers [RFC8084]. 626 Congestion Control Compliance of Traffic: Congestion control is a key 627 transport function. Many network operators implicitly accept that 628 TCP traffic to comply with a behaviour that is acceptable for use 629 in the shared Internet. TCP algorithms have been continuously 630 improved over decades, and they have reached a level of efficiency 631 and correctness that custom application-layer mechanisms will 632 struggle to easily duplicate [RFC8085]. 634 A standards-compliant TCP stack provides congestion control may 635 therefore be judged safe for use across the Internet. 636 Applications developed on top of well-designed transports can be 637 expected to appropriately control their network usage, reacting 638 when the network experiences congestion, by back-off and reduce 639 the load placed on the network. This is the normal expected 640 behaviour for TCP and SCTP. 642 However when anomolies are detected, tools can interpret the 643 transport protocol header information to help understand the 644 impact of specific transport protocols (or protocol mechanisms) on 645 the other traffic that shares a network. An observation in the 646 network can gain understanding of the dynamics of a flow and its 647 congestion control behaviour. Analysing observed packet sequence 648 numbers can be used to help build confidence that an application 649 flow backs-off its share of the network load in the face of 650 persistent congestion, and hence to understand whether the 651 behaviour is appropriate for sharing limited network capacity. 652 For example, it is common to visualise plots of TCP sequence 653 numbers versus time for a flow to understand how a flow shares 654 available capacity, deduce its dynamics in response to congestion, 655 etc. 657 Congestion Control Compliance for UDP Traffic UDP provides a minimal 658 message-passing transport that has no inherent congestion control 659 mechanisms. Because congestion control is critical to the stable 660 operation of the Internet, applications and other protocols that 661 choose to use UDP as an Internet transport are required to employ 662 mechanisms to prevent congestion collapse, avoid unacceptable 663 contributions to jitter/latency, and to establish an acceptable 664 share of capacity with concurrent traffic [RFC8085]. 666 A network operator needs tools to understand if UDP flows comply 667 with congestion control expectations and therefore whether there 668 is a need to deploy methods such as rate-limiters, transport 669 circuit breakers or other methods to enforce acceptable usage for 670 the offered service. 672 UDP flows that expose a well-known header by specifying the format 673 of header fields can allow information to be observed to gain 674 understanding of the dynamics of a flow and its congestion control 675 behaviour. For example, tools exist to monitor various aspects of 676 the RTP and RTCP header information of real-time flows (see 677 Section 1.1.1.2. 679 1.1.3. Use for Network Diagnostics and Troubleshooting 681 Transport header information is useful for a variety of operational 682 tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, 683 assess performance, capacity planning, management of denial of 684 service threats, and responding to user performance questions. These 685 tasks seldom involve the need to determine the contents of the 686 transport payload, or other application details. 688 A network operator supporting traffic that uses transport header 689 encryption can see only encrypted transport headers. This prevents 690 deployment of performance measurement tools that rely on transport 691 protocol information. Choosing to encrypt all information may be 692 expected to reduce the ability for networks to "help" (e.g., in 693 response to tracing issues, making appropriate Quality of Service, 694 QoS, decisions). For some this will be blessing, for others it may be 695 a curse. For example, operational performance data about encrypted 696 flows needs to be determined by traffic pattern analysis, rather than 697 relying on traditional tools. This can impact the ability of the 698 operator to respond to faults, it could require reliance on endpoint 699 diagnostic tools or user involvement in diagnosing and 700 troubleshooting unusual use cases or non-trivial problems. A key 701 need here is that tools need to provide useful information during 702 network anomalies (e.g., significant reordering, high or intermittent 703 loss). Although many network operators utilise transport information 704 as a part of their operational practice, the network will not break 705 because transport headers are encrypted. 707 1.1.4. Observing Headers to Implement Network Policy 709 Information from the transport protocol can be used by a multi-field 710 classifier as a part of policy framework. Policies are commonly used 711 for QoS management for resource-constrained networks and by firewalls 712 that use the information to implement access rules. Traffic that 713 cannot be classified, will typically receive a default treatment. 715 2. Encryption and Authentication of Transport Headers 716 End-to-end encryption can be applied at various protocol layers. It 717 can be applied above the transport to encrypt the transport payload. 718 Encryption methods can hide information from an eavesdropper in the 719 network. Encryption can also help protect the privacy of a user, by 720 hiding data relating to user/device identity or location. Neither an 721 integrity check nor encryption methods prevent traffic analysis, and 722 usage needs to reflect that profiling of users, identification of 723 location and fingerprinting of behaviour can take place even on 724 encrypted traffic flows. 726 One motive to use encryption is a response to perceptions that the 727 network has become ossified by over-reliance on middleboxes that 728 prevent new protocols and mechanisms from being deployed. This has 729 lead to a common perception that there is too much "manipulation" of 730 protocol headers within the network, and that designing to deploy in 731 such networks is preventing transport evolution. In the light of 732 this, a method that authenticates transport headers may help improve 733 the pace of transport development, by eliminating the need to always 734 consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or 735 potentially to only explicitly enable middlebox use for particular 736 paths with particular middleboxes that are deliberately deployed to 737 realise a useful function for the network and/or users[RFC3135]. 739 Another motivation stems from increased concerns about privacy and 740 surveillance. Some Internet users have valued the ability to protect 741 identity, user location, and defend against traffic analysis, and 742 have used methods such as IPsec ESP and Tor [Tor]. Revelations about 743 the use of pervasive surveillance [RFC7624] have, to some extent, 744 eroded trust in the service offered by network operators, and 745 following the Snowden revelation in the USA in 2013 has led to an 746 increased desire for people to employ encryption to avoid unwanted 747 "eavesdropping" on their communications. Whatever the reasons, there 748 are now activities in the IETF to design new protocols that may 749 include some form of transport header encryption (e.g., QUIC [I-D 750 .ietf-quic-transport]). 752 Authentication methods (that provide integrity checks of protocols 753 fields) have also been specified at the network layer, and this also 754 protects transport header fields. The network layer itself carries 755 protocol header fields that are increasingly used to help forwarding 756 decisions reflect the need of transport protocols, such the IPv6 Flow 757 Label [RFC6437], the Differentiated Services Code Point (DSCP) 758 [RFC2474] and Explicit Congestion Notification (ECN) [RFC3168]. 760 The use of transport layer authentication and encryption exposes a 761 tussle between middlebox vendors, operators, applications developers 762 and users. 764 o On the one hand, future Internet protocols that enable large-scale 765 encryption assist in the restoration of the end-to-end nature of 766 the Internet by returning complex processing to the endpoints, 767 since middleboxes cannot modify what they cannot see. 769 o On the other hand, encryption of transport layer header 770 information has implications for people who are responsible for 771 operating networks and researchers and analysts seeking to 772 understand the dynamics of protocols and traffic patterns. 774 Whatever the motives, a decision to use pervasive of transport header 775 encryption will have implications on the way in which design and 776 evaluation is performed, and which can in turn impact the direction 777 of evolution of the TCP/IP stack. 779 The next subsections briefly review some security design options for 780 transport protocols. 782 2.1. Authenticating the Transport Protocol Header 784 Transport layer header information can be authenticated. An 785 integrity check that protects the immutable transport header fields, 786 but can still expose the transport protocol header information in the 787 clear, allowing in-network devices to observes these fields. An 788 integrity check can not prevent in-network modification, but can 789 avoid a receiving accepting changes and avoid impact on the transport 790 protocol operation. 792 An example transport authentication mechanism is TCP-Authentication 793 (TCP-AO) [RFC5925]. This TCP option authenticates TCP segments, 794 including the IP pseudo header, TCP header, and TCP data. TCP-AO 795 protects the transport layer, preventing attacks from disabling the 796 TCP connection itself. TCP-AO may interact with middleboxes, 797 depending on their behaviour [RFC3234]. 799 The IPsec Authentication Header (AH) [RFC4302] works at the network 800 layer and authenticates the IP payload. This therefore also 801 authenticates all transport headers, and verifies their integrity at 802 the receiver, preventing in-network modification. 804 2.2. Encrypting the Transport Payload 806 The transport layer payload can be encrypted to protect the content 807 of transport segments. This leaves transport protocol header 808 information in the clear. The integrity of immutable transport 809 header fields could be protected by combining this with an integrity 810 check (Section 2.1). 812 Examples of encrypting the payload include Transport Layer Security 813 (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP 814 [RFC6347] [RFC7525]. 816 2.3. Encrypting the Transport Header 818 The network layer payload could be encrypted (including the entire 819 transport header and payload). This method does not expose any 820 transport information to devices in the network, which also prevents 821 modification along the network path. 823 The IPsec Encapsulating Security Payload (ESP) [RFC4303] is an 824 example of encryption at the network layer, it encrypts and 825 authenticates all transport headers, preventing visibility of the 826 headers by in-network devices. Some Virtual Private Network (VPN) 827 methods also encrypt these headers. 829 2.4. Authenticating Transport Information and Selectively Encrypting 830 the Transport Header 832 A transport protocol design can encrypt selected header fields, while 833 also choosing to authenticate fields in the transport header. This 834 allows specific transport header fields to be made observable by 835 network devices. End-to end integrity checks can prevent an endpoint 836 from undetected modification of the immutable transport headers. 838 The choice of which fields to expose and which to encrypt is a design 839 choice for the transport protocol. Any selective encryption method 840 requires trading two conflicting goals for a transport protocol 841 designer to decide which header fields to encrypt. On the one hand, 842 security work typically employs a design technique that seeks to 843 expose only what is needed. On the other hand, there may be 844 performance and operational benefits in exposing selected information 845 to network tools. 847 Mutable fields in the transport header provide opportunities for 848 middleboxes to modify the transport behaviour (e.g., the extended 849 headers described in [I-D.trammell-plus-abstract-mech]). This 850 considers only immutable fields in the transport headers, that is, 851 fields that may be authenticated end-to-end across a path. 853 An example of a method that encrypts some, but not all, transport 854 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 856 2.5. Adding Transport Information to Network-Layer Protocol Headers 857 The transport information can be made visible in a network-layer 858 header. This has the advantage that this information can then be 859 observed by in-network devices. This has the advantage that a single 860 header can support all transport protocols, but there may also be 861 less desirable implications of separating the operation of the 862 transport protocol from the measurement framework. 864 Some measurements may be made by adding additional protocol headers 865 carrying operations, administration and management (OAM) information 866 to packets at the ingress to a maintenance domain (e.g., an Ethernet 867 protocol header with timestamps and sequence number information using 868 a method such as 802.11ag) and removing the additional header at the 869 egress of the maintenance domain. This approach enables some types 870 of measurements, but does not cover the entire range of measurements 871 described in this document. 873 Another example of a network-layer approach is the IPv6 Performance 874 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 875 pdm-option]. This allows a sender to optionally include a 876 destination option that caries header fields that can be used to 877 observe timestamps and packet sequence numbers. This information 878 could be authenticated by receiving transport endpoints when the 879 information is added at the sender and visible at the receiving 880 endpoint, although methods to do this have not currently been 881 proposed. This method needs to be explicitly enabled at the sender. 883 A drawback of using extension headers is that IPv4 network options 884 are often not supported (or are carried on a slower processing path) 885 and some IPv6 networks are also known to drop packets that set an 886 IPv6 header extension. Another disadvantage is that protocols that 887 separately expose header information do not necessarily have an 888 advantage to expose the information that is utilised by the protocol 889 itself, and could manipulate this header information to gain an 890 advantage from the network. 892 3. Implications of Protecting the Transport Headers 894 This section explores key implications of working with encrypted 895 transport protocols. 897 3.1. Independent Measurement 899 Independent observation by multiple actors is important for 900 scientific analysis. Encrypting transport header encryption changes 901 the ability for other actors to collect and independently analyse 902 data. Internet transport protocols employ a set of mechanisms. Some 903 of these need to work in cooperation with the network layer - loss 904 detection and recovery, congestion detection and congestion control, 905 some of these need to work only end-to-end (e.g., parameter 906 negotiation, flow-control). 908 When encryption conceals information in the transport header, it 909 could be possible for an applications to provide summary data on 910 performance and usage of the network. This data could be made 911 available to other actors. However, this data needs to contain 912 sufficient detail to understand (and possibly reconstruct the network 913 traffic pattern for further testing) and to be correlated with the 914 configuration of the network paths being measured. Sharing 915 information between actors needs also to consider the privacy of the 916 user and the incentives for providing accurate and detailed 917 information. Protocols that expose the state information used by the 918 transport protocol in their header information (e.g., timestamps used 919 to calculate the RTT, packet numbers used to asses congestion and 920 requests for retransmission) provide an incentive for the sending 921 endpoint to provide correct information, increasing confidence that 922 the observer understands the transport interaction with the network. 923 This becomes important when considering changes to transport 924 protocols, changes in network infrastructure, or the emergence of new 925 traffic patterns. 927 3.2. Characterising "Unknown" Network Traffic 929 The patterns and types of traffic that share Internet capacity 930 changes with time as networked applications, usage patterns and 931 protocols continue to evolve. 933 If "unknown" or "uncharacterised" traffic patterns form a small part 934 of the traffic aggregate passing through a network device or segment 935 of the network the path, the dynamics of the uncharacterised traffic 936 may not have a significant collateral impact on the performance of 937 other traffic that shares this network segment. Once the proportion 938 of this traffic increases, the need to monitor the traffic and 939 determine if appropriate safety measures need to be put in place. 941 Tracking the impact of new mechanisms and protocols requires traffic 942 volume to be measured and new transport behaviours to be identified. 943 This is especially true of protocols operating over a UDP substrate. 944 The level and style of encryption needs to be considered in 945 determining how this activity is performed. On a shorter timescale, 946 information may also need to be collected to manage denial of service 947 attacks against the infrastructure. 949 3.3. Accountability and Internet Transport Protocols 950 Information provided by tools observing transport headers can help 951 determine whether mechanisms are needed in the network to prevent 952 flows from acquiring excessive network capacity, and where needed to 953 deploy appropriate tools Section 1.1.2.4. Obfuscating or hiding this 954 information using encryption is expected to lead operators and 955 maintainers of middleboxes (firewalls, etc.) to seek other methods to 956 classify and mechanisms to condition network traffic. A lack of data 957 seems likely to reduce the level of precision with which these 958 mechanisms are applied, and this needs to be considered when 959 evaluating the impact of designs for transport encryption. 961 3.4. Impact on Research, Development and Deployment 963 Measurement data is increasingly being used to inform design 964 decisions in networking research, during development of new 965 mechanisms and protocols and in standardisation. Measurement has a 966 critical role in the design of transport protocol mechanisms and 967 their acceptance by the wider community (e.g., as a method to judge 968 the safety for Internet deployment). Observation of pathologies are 969 also important in understanding the interactions between cooperating 970 protocols and network mechanism, the implications of sharing capacity 971 with other traffic and the impact of different patterns of usage. 973 Attention needs to be paid to the expected scale of deployment of new 974 protocols and protocol mechanisms. Whatever the mechanism, 975 experience has shown that it is often difficult to correctly 976 implement combination of mechanisms [RFC8085]. These mechanisms 977 therefore typically evolve as a protocol matures, or in response to 978 changes in network conditions, changes in network traffic or changes 979 to application usage. 981 The growth and diversity of applications and protocols using the 982 Internet continues to expand - and there has been recent interest in 983 a wide range of new transport methods, e.g., Larger Initial Window, 984 Proportional Rate Reduction (PRR), congestion control methods based 985 on measuring bottleneck bandwidth and round-trip propagation time, 986 the introduction of AQM techniques and new forms of ECN response 987 (e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods 988 proposed for Low Latency Low Loss Scalable throughput, L4S). For 989 each new method it is desirable to build a body of data reflecting 990 its behaviour under a wide range of deployment scenarios, traffic 991 load, and interactions with other deployed/candidate methods. 993 Open standards motivate a desire for this evaluation to include 994 independent observation and evaluation of performance data, which in 995 turn suggests control over where and when measurement samples are 996 collected. This requires consideration of the appropriate balance 997 between encrypting all and no transport information. 999 4. Acknowledgements 1001 The author would like to thank all who have talked to him face-to- 1002 face or via email. ... 1004 This work has received funding from the European Union's Horizon 2020 1005 research and innovation programme under grant agreement No 688421.The 1006 opinions expressed and arguments employed reflect only the authors' 1007 view. The European Commission is not responsible for any use that 1008 may be made of that information. 1010 5. Security Considerations 1012 This document is about design and deployment considerations for 1013 transport protocols. Authentication, confidentiality protection, and 1014 integrity protection are identified as Transport Features by 1015 RFC8095". As currently deployed in the Internet, these features are 1016 generally provided by a protocol or layer on top of the transport 1017 protocol; no current full-featured standards-track transport protocol 1018 provides these features on its own. Therefore, these features are 1019 not considered in this document, with the exception of native 1020 authentication capabilities of TCP and SCTP for which the security 1021 considerations in RFC4895. 1023 Open data, and accessibility to tools that can help understand trends 1024 in application deployment, network traffic and usage patterns can all 1025 contribute to understanding security challenges. Standard protocols 1026 and understanding of the interactions between mechanisms and traffic 1027 patterns can also provide valuable insight into appropriate security 1028 design. Like congestion control mechanisms, security mechanisms are 1029 difficult to design and implement correctly. It is hence recommended 1030 that applications employ well-known standard security mechanisms such 1031 as DTLS, TLS or IPsec, rather than inventing their own. 1033 6. IANA Considerations 1035 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1037 This memo includes no request to IANA. 1039 7. References 1041 7.1. Normative References 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1045 RFC2119, March 1997, . 1048 7.2. Informative References 1050 [I-D.dolson-plus-middlebox-benefits] 1051 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1052 "Beneficial Functions of Middleboxes", Internet-Draft 1053 draft-dolson-plus-middlebox-benefits-03, March 2017. 1055 [I-D.ietf-aqm-codel] 1056 Nichols, K., Jacobson, V., McGregor, A. and J. Jana, 1057 "Controlled Delay Active Queue Management", Internet-Draft 1058 draft-ietf-aqm-codel-00, October 2014. 1060 [I-D.ietf-aqm-fq-codel] 1061 Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1062 J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft 1063 draft-ietf-aqm-fq-codel-00, January 2015. 1065 [I-D.ietf-aqm-pie] 1066 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1067 Lightweight Control Scheme To Address the Bufferbloat 1068 Problem", Internet-Draft draft-ietf-aqm-pie-00, October 1069 2014. 1071 [I-D.ietf-ippm-6man-pdm-option] 1072 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1073 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1074 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1075 option-10, May 2017. 1077 [I-D.ietf-quic-transport] 1078 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1079 and Secure Transport", Internet-Draft draft-ietf-quic- 1080 transport-03, May 2017. 1082 [I-D.ietf-tcpm-accurate-ecn] 1083 Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More 1084 Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- 1085 tcpm-accurate-ecn-00, December 2015. 1087 [I-D.ietf-tcpm-dctcp] 1088 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1089 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 1090 Control for Datacenters", Internet-Draft draft-ietf-tcpm- 1091 dctcp-06, May 2017. 1093 [I-D.ietf-tsvwg-l4s-arch] 1094 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1095 Low Loss, Scalable Throughput (L4S) Internet Service: 1096 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1097 arch-00, May 2017. 1099 [I-D.mm-wg-effect-encrypt] 1100 Moriarty, K. and A. Morton, "Effect of Pervasive 1101 Encryption on Operators", Internet-Draft draft-mm-wg- 1102 effect-encrypt-11, April 2017. 1104 [I-D.trammell-plus-abstract-mech] 1105 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1106 Layer under Endpoint Control", Internet-Draft draft- 1107 trammell-plus-abstract-mech-00, September 2016. 1109 [I-D.trammell-plus-statefulness] 1110 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1111 "Transport-Independent Path Layer State Management", 1112 Internet-Draft draft-trammell-plus-statefulness-02, 1113 December 2016. 1115 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1116 Techniques and Their Merits", November 2014. 1118 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1119 based Protocol Design", June 2017. 1121 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1122 "Definition of the Differentiated Services Field (DS 1123 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1124 10.17487/RFC2474, December 1998, . 1127 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1128 Shelby, "Performance Enhancing Proxies Intended to 1129 Mitigate Link-Related Degradations", RFC 3135, DOI 1130 10.17487/RFC3135, June 2001, . 1133 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1134 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1135 DOI 10.17487/RFC3168, September 2001, . 1138 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1139 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1140 . 1142 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1143 Sooriyabandara, "TCP Performance Implications of Network 1144 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1145 December 2002, . 1147 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1148 Jacobson, "RTP: A Transport Protocol for Real-Time 1149 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1150 July 2003, . 1152 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1153 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 1154 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1155 RFC 3819, DOI 10.17487/RFC3819, July 2004, . 1158 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1159 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1160 December 2005, . 1162 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1163 10.17487/RFC4302, December 2005, . 1166 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1167 4303, DOI 10.17487/RFC4303, December 2005, . 1170 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1171 "Extended RTP Profile for Real-time Transport Control 1172 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1173 10.17487/RFC4585, July 2006, . 1176 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1177 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1178 10.17487/RFC4737, November 2006, . 1181 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1182 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1183 DOI 10.17487/RFC5236, June 2008, . 1186 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1187 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1188 RFC5246, August 2008, . 1191 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1192 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1193 . 1195 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1196 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1197 June 2010, . 1199 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1200 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1201 January 2012, . 1203 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1204 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1205 RFC6437, November 2011, . 1208 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1209 and K. Carlberg, "Explicit Congestion Notification (ECN) 1210 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1211 2012, . 1213 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1214 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1215 2014, . 1217 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1218 for Secure Use of Transport Layer Security (TLS) and 1219 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1220 7525, DOI 10.17487/RFC7525, May 2015, . 1223 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1224 Recommendations Regarding Active Queue Management", BCP 1225 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1228 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1229 Trammell, B., Huitema, C. and D. Borkmann, 1230 "Confidentiality in the Face of Pervasive Surveillance: A 1231 Threat Model and Problem Statement", RFC 7624, DOI 1232 10.17487/RFC7624, August 2015, . 1235 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1236 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1237 DOI 10.17487/RFC7713, December 2015, . 1240 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1241 Ros, "Characterization Guidelines for Active Queue 1242 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1243 2016, . 1245 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1246 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1249 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1250 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1251 March 2017, . 1253 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1254 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1255 2017, . 1257 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1258 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1259 10.17487/RFC8087, March 2017, . 1262 [Tor] The Tor Project, ., "https://www.torproject.org", June 1263 2017. 1265 Appendix A. Revision information 1266 -00 This is an individual draft for the IETF community. 1268 -01 This draft was a result of walking away from the text for a few 1269 days and then reorganising the content. 1271 -02 This draft fixes textual errors. 1273 -03 This draft follows feedback from people reading this draft. 1275 -04 This adds an additional contributore and includes significant 1276 reworking to ready this for review by the wider IETF community Colin 1277 Perkins joined the author list. 1279 Comments from the community are welcome on the text and 1280 recommendations. 1282 Authors' Addresses 1284 Godred Fairhurst 1285 University of Aberdeen 1286 Department of Engineering 1287 Fraser Noble Building 1288 Aberdeen, AB24 3UE 1289 Scotland 1291 Email: gorry@erg.abdn.ac.uk 1292 URI: http://www.erg.abdn.ac.uk/ 1294 Colin Perkins 1295 University of Glasgow 1296 School of Computing Science 1297 Glasgow, G12 8QQ 1298 Scotland 1300 Email: csp@csperkins.org 1301 URI: https://csperkins.org//