idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-08.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 (May 22, 2018) is 2165 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1377, but no explicit reference was found in the text == Unused Reference: 'I-D.dolson-plus-middlebox-benefits' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aqm-codel' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-taps-transport-security' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-accurate-ecn' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-plus-statefulness' is defined on line 1462, but no explicit reference was found in the text == Unused Reference: 'RFC3449' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1561, but no explicit reference was found in the text == Unused Reference: 'RFC6679' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'Tor' is defined on line 1642, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-01 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-11 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-06 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-01 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-24 == 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 (~~), 21 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: November 21, 2018 University of Glasgow 6 May 22, 2018 8 The Impact of Transport Header Confidentiality on Network Operation and 9 Evolution of the Internet 10 draft-fairhurst-tsvwg-transport-encrypt-08 12 Abstract 14 This document describes implications of applying end-to-end 15 encryption at the transport layer. It identifies in-network uses of 16 transport layer header information. It then reviews the implications 17 of developing end-to-end transport protocols that use authentication 18 to protect the integrity of transport information or encryption to 19 provide confidentiality of the transport protocol header and expected 20 implications of transport protocol design and network operation. 21 Since transport measurement and analysis of the impact of network 22 characteristics have been important to the design of current 23 transport protocols, it also considers the impact on transport and 24 application evolution. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 21, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Current uses of Transport Headers within the Network . . . . . 8 61 2.1. Observing Transport Information in the Network . . . . . . 9 62 2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9 63 2.1.2. Metrics derived from Transport Layer Headers . . . . . 10 64 2.1.3. Metrics derived from Network Layer Headers . . . . . . 13 65 2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14 66 2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 15 67 2.2.2. Use by Operators to Plan and Provision Networks . . . 15 68 2.2.3. Service Performance Measurement . . . . . . . . . . . 16 69 2.2.4. Measuring Transport to Support Network Operations . . 16 70 2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17 71 2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18 72 2.4. Observing Headers to Implement Network Policy . . . . . . 19 73 3. Encryption and Authentication of Transport Headers . . . . . . 19 74 3.1. Authenticating the Transport Protocol Header . . . . . . . 21 75 3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21 76 3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21 77 3.4. Authenticating Transport Information and Selectively 78 Encrypting the Transport Header . . . . . . . . . . . . . 22 79 3.5. Optional Encryption of Header Information . . . . . . . . 22 80 4. Addition of Transport Information to Network-Layer Protocol 81 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5. Implications of Protecting the Transport Headers . . . . . . . 23 83 5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23 84 5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24 85 5.3. Accountability and Internet Transport Protocols . . . . . 25 86 5.4. Impact on Research, Development and Deployment . . . . . . 25 87 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 93 10.2. Informative References . . . . . . . . . . . . . . . . . 30 94 Appendix A. Revision information . . . . . . . . . . . . . . . . . 35 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 97 1. Introduction 98 This document describes implications of applying end-to-end 99 encryption at the transport layer. It reviews the implications of 100 developing end-to-end transport protocols that use encryption to 101 provide confidentiality of the transport protocol header and expected 102 implications of transport protocol design and network operation. It 103 also considers anticipated implications on transport and application 104 evolution. 106 The transport layer provides end-to-end interactions between 107 endpoints (processes) using an Internet path. Transport protocols 108 layer directly over the network-layer service and are sent in the 109 payload of network-layer packets. They support end-to-end 110 communication between applications, supported by higher-layer 111 protocols, running on the end systems (or transport endpoints). This 112 simple architectural view hides one of the core functions of the 113 transport, however, to discover and adapt to the properties of the 114 Internet path that is currently being used. The design of Internet 115 transport protocols is as much about trying to avoid the unwanted 116 side effects of congestion on a flow and other capacity-sharing 117 flows, avoiding congestion collapse, adapting to changes in the path 118 characteristics, etc., as it is about end-to-end feature negotiation, 119 flow control and optimising for performance of a specific 120 application. 122 To achieve stable Internet operations the IETF transport community 123 has to date relied heavily on measurement and insights of the network 124 operations community to understand the trade-offs, and to inform 125 selection of appropriate mechanisms, to ensure a safe, reliable, and 126 robust Internet (e.g., [RFC1273]). In turn, the network operations 127 community relies on being able to understand the pattern and 128 requirements of traffic passing over the Internet, both in aggregate 129 and at the flow level. 131 There are many motivations for deploying encrypted transports 132 [RFC7624] (i.e., transport protocols that use encryption to provide 133 confidentiality of some or all of the transport-layer header 134 information), and encryption of transport payloads (i.e. 135 confidentiality of the payload data). The increasing public concerns 136 about the interference with Internet traffic have led to a rapidly 137 expanding deployment of encryption to protect end-user privacy, in 138 protocols like QUIC [I-D.ietf-quic-transport], but also expected to 139 form a basis of future protocol designs. 141 Some network operators and access providers, have come to rely on the 142 in-network measurement of transport properties and the functionality 143 provided by middleboxes to both support network operations and 144 enhance performance. There can therefore be implications when 145 working with encrypted transport protocols that hide transport header 146 information from the network. These present architectural challenges 147 and considerations in the way transport protocols are designed, and 148 ability to characterise and compare different transport solutions 149 [Measure], Section 2.2. Implementations of network devices are 150 encouraged to avoid side-effects when protocols are updated. 151 Introducing cryptographic integrity checks to header fields can also 152 prevent undetected manipulation of the field by network devices, or 153 undetected addition of information to a packet. However, this does 154 not prevent inspection of the information by a device on path, and it 155 is possible that such devices could develop mechanisms that rely on 156 the presence of such a field, or a known value in the field. 158 Reliance on the presence and semantics of specific header information 159 leads to ossification: An endpoint could be required to supply a 160 specific header to receive the network service that it desires. In 161 some cases, this could be benign or advantageous to the protocol 162 (e.g., recognising the start of a connection, or explicitly exposing 163 protocol information can be expected to provide more consistent 164 decisions by on-path devices than the use of diverse methods to infer 165 semantics from other flow properties). In some cases, this is not 166 beneficial (e.g., a mechanism implemented in a network device, such 167 as a firewall, that required a header field to have only a specific 168 known set of values could prevent the device from forwarding packets 169 using a different version of a protocol that introduces a new feature 170 that changes the value present in this field, preventing evolution of 171 the protocol). 173 A protocol design that uses header encryption can provide 174 confidentiality of some or all of the protocol header information. 175 This prevents an on-path device from knowledge of the header field. 176 It therefore prevents mechanisms being built that directly rely on 177 the information or seeks to imply semantics of an exposed header 178 field. Using encryption to provide confidentiality of the transport 179 layer brings some well-known privacy and security benefits and can 180 therefore help reduce ossification of the transport layer. In 181 particular, it is important that protocols either do not expose 182 information where the usage may change in future protocols, or that 183 methods that utilise the information are robust to potential changes 184 as protocols evolve over time. To avoid unwanted inspection, a 185 protocol could also intentionally vary the format and value of header 186 fields (sometimes known as Greasing [I-D.thomson-quic-grease]). 188 However, while encryption hides the protocol header information, it 189 does not prevent ossification of the network service: People seeking 190 understanding of network traffic could come to rely on pattern 191 inferences and other heuristics as the basis for network decision and 192 to derive measurement data, creating new dependencies on the 193 transport protocol. 195 A level of ossification of the transport header can offer trade-offs 196 around authentication, and confidentiality of transport protocol 197 headers and has the potential to explicitly support for other uses of 198 this header information. For example, a design that provides 199 confidentiality of protocol header information can impact the 200 following activities that rely on measurement and analysis of traffic 201 flows: 203 Network Operations and Research: Observable transport headers enable 204 both operators and the research community to measure and analyse 205 protocol performance, network anomalies, and failure pathologies. 207 This information can help inform capacity planning, and assist in 208 determining the need for equipment and/or configuration changes by 209 network operators. 211 The data can also inform Internet engineering research, and help 212 the development of new protocols, methodologies, and procedures. 213 Concealing the transport protocol header information makes the 214 stream performance unavailable to passive observers along the 215 path, and likely leads to the development of alternative methods 216 to collect or infer that data. 218 Providing confidentiality of the transport payload, but leaving 219 some, or all, of the transport headers unencrypted, possibly with 220 authentication, can provide the majority of the privacy and 221 security benefits while allowing some measurement. 223 Protection from Denial of Service: Observable transport headers 224 currently provide useful input to classify traffic and detect 225 anomalous events (e.g., changes in application behaviour, 226 distributed denial of service attacks). To be effective, this 227 protection needs to be able to uniquely disambiguate unwanted 228 traffic. An inability to separate this traffic using packet 229 header information may result in less-efficient identification of 230 unwanted traffic or development of different methods (e.g. rate- 231 limiting of uncharacterised traffic). 233 Network Troubleshooting and Diagnostics: Encrypting transport header 234 information eliminates the incentive for operators to troubleshoot 235 what they cannot interpret. A flow experiencing packet loss or 236 jitter looks like an unaffected flow when only observing network 237 layer headers (if transport sequence numbers and flow identifiers 238 are obscured). This limits understanding of the impact of packet 239 loss or latency on the flows, or even localizing the network 240 segment causing the packet loss or latency. Encrypted traffic may 241 imply "don't touch" to some, and could limit a trouble-shooting 242 response to "can't help, no trouble found". The additional 243 mechanisms that will need to be introduced to help reconstruct 244 transport-level metrics add complexity and operational costs 245 (e.g., in deploying additional functions in equipment or adding 246 traffic overhead). 248 Network Traffic Analysis: Hiding transport protocol header 249 information can make it harder to determine which transport 250 protocols and features are being used across a network segment and 251 to measure trends in the pattern of usage. This could impact the 252 ability for an operator to anticipate the need for network 253 upgrades and roll-out. It can also impact the on-going traffic 254 engineering activities performed by operators (such as determining 255 which parts of the path contribute delay, jitter or loss). While 256 the impact may, in many cases, be small there are scenarios where 257 operators directly support particular services (e.g., to 258 troubleshoot issues relating to Quality of Service, QoS; the 259 ability to perform fast re-routing of critical traffic, or support 260 to mitigate the characteristics of specific radio links). The more 261 complex the underlying infrastructure the more important this 262 impact. 264 Open and Verifiable Network Data: Hiding transport protocol header 265 information can reduce the range of actors that can capture useful 266 measurement data. For example, one approach could be to employ an 267 existing transport protocol that reveals little information (e.g., 268 UDP), and perform traditional transport functions at higher layers 269 protecting the confidentiality of transport information. Such a 270 design, limits the information sources available to the Internet 271 community to understand the operation of new transport protocols, 272 so preventing access to the information necessary to inform design 273 decisions and standardisation of the new protocols and related 274 operational practices. 276 The cooperating dependence of network, application, and host to 277 provide communication performance on the Internet is uncertain 278 when only endpoints (i.e., at user devices and within service 279 platforms) can observe performance, and performance cannot be 280 independently verified by all parties. The ability of other 281 stakeholders to review code can help develop deeper insight. In 282 the heterogeneous Internet, this helps extend the range of 283 topologies, vendor equipment, and traffic patterns that are 284 evaluated. 286 Independently captured data is important to help ensure the health 287 of the research and development communities. It can provide input 288 and test scenarios to support development of new transport 289 protocol mechanisms, especially when this analysis can be based on 290 the behaviour experienced in a diversity of deployed networks. 292 Independently verifiable performance metrics might also be 293 important to demonstrate regulatory compliance in some 294 jurisdictions, and provides an important basis for informing 295 design decisions. 297 The last point leads us to consider the impact of hiding transport 298 headers in the specification and development of protocols and 299 standards. This has potential impact on: 301 o Understanding Feature Interactions: An appropriate vantage point, 302 coupled with timing information about traffic flows, provides a 303 valuable tool for benchmarking equipment, functions, and/or 304 configurations, and to understand complex feature interactions. 305 An inability to observe transport protocol information can limit 306 the ability to diagnose and explore interactions between features 307 at different protocol layers, a side-effect of not allowing a 308 choice of vantage point from which this information is observed. 310 o Supporting Common Specifications: The Transmission Control 311 Protocol (TCP) is currently the predominant transport protocol 312 used over Internet paths. Its many variants have broadly 313 consistent approaches to avoiding congestion collapse, and to 314 ensuring the stability of the Internet. Increased use of 315 transport layer encryption can overcome ossification, allowing 316 deployment of new transports and different types of congestion 317 control. This flexibility can be beneficial, but it can come at 318 the cost of fragmenting the ecosystem. There is little doubt that 319 developers will try to produce high quality transports for their 320 intended target uses, but it is not clear there are sufficient 321 incentives to ensure good practice that benefits the wide 322 diversity of requirements for the Internet community as a whole. 323 Increased diversity, and the ability to innovate without public 324 scrutiny, risks point solutions that optimise for specific needs, 325 but accidentally disrupt operations of/in different parts of the 326 network. The social contract that maintains the stability of the 327 Internet relies on accepting common specifications, and on the 328 ability to verify that others also conform. 330 o Operational practice: Published transport specifications allow 331 operators to check compliance. This can bring assurance to those 332 operating networks, often avoiding the need to deploy complex 333 techniques that routinely monitor and manage TCP/IP traffic flows 334 (e.g. Avoiding the capital and operational costs of deploying 335 flow rate-limiting and network circuit-breaker methods [RFC8084]). 336 When it is not possible to observe transport header information, 337 methods are still needed to confirm that the traffic produced 338 conforms to the expectations of the operator or developer. 340 o Restricting research and development: Hiding transport information 341 can impede independent research into new mechanisms, measurement 342 of behaviour, and development initiatives. Experience shows that 343 transport protocols are complicated to design and complex to 344 deploy, and that individual mechanisms need to be evaluated while 345 considering other mechanisms, across a broad range of network 346 topologies and with attention to the impact on traffic sharing the 347 capacity. If this results in reduced availability of open data, 348 it could eliminate the independent self-checks to the 349 standardisation process that have previously been in place from 350 research and academic contributors (e.g., the role of the IRTF 351 ICCRG, and research publications in reviewing new transport 352 mechanisms and assessing the impact of their experimental 353 deployment) 355 In summary, there are tradeoffs. On the one hand, protocol designers 356 have often ignored the implications of whether the information in 357 transport header fields can or will be used by in-network devices, 358 and the implications this places on protocol evolution. This 359 motivates a design that provides confidentiality of the header 360 information. On the other hand, it can be expected that a lack of 361 visibility of transport header information can impact the ways that 362 protocols are deployed, standardised, and their operational support. 363 The choice of whether future transport protocols encrypt their 364 protocol headers therefore needs to be taken based not solely on 365 security and privacy considerations, but also taking into account the 366 impact on operations, standards, and research. Any new Internet 367 transport need to provide appropriate transport mechanisms and 368 operational support to assure the resulting traffic can not result in 369 persistent congestion collapse [RFC2914]. This document suggests 370 that the balance between information exposed and concealed should be 371 carefully considered when specifying new protocols. 373 2. Current uses of Transport Headers within the Network 374 Despite transport headers having end-to-end meaning, some of these 375 transport headers have come to be used in various ways within the 376 Internet. In response to pervasive monitoring [RFC7624] revelations 377 and the IETF consensus that "Pervasive Monitoring is an Attack" 378 [RFC7258], efforts are underway to increase encryption of Internet 379 traffic,. Applying confidentiality to transport header fields would 380 affect how protocol information is used [I-D.mm-wg-effect-encrypt]. 381 To understand these implications, it is first necessary to understand 382 how transport layer headers are currently observed and/or modified by 383 middleboxes within the network. 385 Transport protocols can be designed to encrypt or authenticate 386 transport header fields. Authentication at the transport layer can 387 be used to detect any changes to an immutable header field that were 388 made by a network device along a path. The intentional modification 389 of transport headers by middleboxes (such as Network Address 390 Translation, NAT, or Firewalls) is not considered. Common issues 391 concerning IP address sharing are described in [RFC6269]. 393 2.1. Observing Transport Information in the Network 395 If in-network observation of transport protocol headers is needed, 396 this requires knowledge of the format of the transport header: 398 o Flows need to be identified at the level required to perform the 399 observation; 401 o The protocol and version of the header need to be visible. As 402 protocols evolve over time and there may be a need to introduce 403 new transport headers. This may require interpretation of 404 protocol version information or connection setup information; 406 o The location and syntax of any observed transport headers needs to 407 be known. IETF transport protocols can specify this information. 409 The following subsections describe various ways that observable 410 transport information has been utilised. 412 2.1.1. Flow Identification 413 Transport protocol header information (together with information in 414 the network header), has been used to identify a flow and the 415 connection state of the flow, together with the protocol options 416 being used. In some usages, a low-numbered (well-known) transport 417 port number has been used to identify a protocol (although port 418 information alone is not sufficient to guarantee identification of a 419 protocol). Transport protocols, such as TCP and Stream Control 420 Transport Protocol (SCTP) specify a standard base header that 421 includes sequence number information and other data, with the 422 possibility to negotiate additional headers at connection setup, 423 identified by an option number in the transport header. UDP-based 424 protocols can use, but sometimes do not use, well-known port numbers. 425 Some can instead be identified by signalling protocols or through the 426 use of magic numbers placed in the first byte(s) of the datagram 427 payload. 429 Flow identification is more complex and less easily achieved when 430 multiplexing is used at or above the transport layer. 432 2.1.2. Metrics derived from Transport Layer Headers 434 Some actors manage their portion of the Internet by characterizing 435 the performance of link/network segments. Passive monitoring uses 436 observed traffic to makes inferences from transport headers to derive 437 these measurements. A variety of open source and commercial tools 438 have been deployed that utilise this information. The following 439 metrics can be derived from transport header information: 441 Traffic Rate and Volume: Header information e.g., (sequence number, 442 length) allows derivation of volume measures per-application, to 443 characterise the traffic that uses a network segment or the 444 pattern of network usage. This may be measured per endpoint or 445 for an aggregate of endpoints (e.g., by an operator to assess 446 subscriber usage). It can also be used to trigger measurement- 447 based traffic shaping and to implement QoS support within the 448 network and lower layers. Volume measures can be valuable for 449 capacity planning (providing detail of trends rather than the 450 volume per subscriber). 452 Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from 453 sequence number) and has been used as a metric for performance 454 assessment and to characterise transport behaviour. Understanding 455 the root cause of loss can help an operator determine whether this 456 requires corrective action. Network operators have used the 457 variation in patterns of loss as a key performance metric, 458 utilising this to detect changes in the offered service. 460 There are various causes of loss, including: corruption of link 461 frames (e.g., interference on a radio link), buffer overflow 462 (e.g., due to congestion), policing (traffic management), buffer 463 management (e.g., Active Queue Management, AQM), inadequate 464 provision of traffic preemption. Understanding flow loss rate 465 requires either maintaining per flow packet counters or by 466 observing sequence numbers in transport headers. Loss can be 467 monitored at the interface level by devices in the network. It is 468 often important to understand the conditions under which packet 469 loss occurs. This usually requires relating loss to the traffic 470 flowing on the network node/segment at the time of loss. 472 Observation of transport feedback information (observing loss 473 reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase 474 understanding of the impact of loss and help identify cases where 475 loss may have been wrongly identified, or the transport did not 476 require the lost packet. It is sometimes more important to 477 understand the pattern of loss, than the loss rate, because losses 478 can often occur as bursts, rather than randomly-timed events. 480 Throughput and Goodput: The throughput achieved by a flow can be 481 determined even when a flow is encrypted, providing the individual 482 flow can be identified. Goodput [RFC7928] is a measure of useful 483 data exchanged (the ratio of useful/total volume of traffic sent 484 by a flow). This requires ability to differentiate loss and 485 retransmission of packets (e.g., by observing packet sequence 486 numbers in the TCP or the Real Time Protocol, RTP, headers 487 [RFC3550]). 489 Latency: Latency is a key performance metric that impacts application 490 response time and user-perceived response time. It often 491 indirectly impacts throughput and flow completion time. Latency 492 determines the reaction time of the transport protocol itself, 493 impacting flow setup, congestion control, loss recovery, and other 494 transport mechanisms. The observed latency can have many 495 components [Latency]. Of these, unnecessary/unwanted queuing in 496 network buffers has often been observed as a significant factor. 497 Once the cause of unwanted latency has been identified, this can 498 often be eliminated. 500 To measure latency across a part of a path, an observation point 501 can measure the experienced round trip time (RTT) using packet 502 sequence numbers, and acknowledgements, or by observing header 503 timestamp information. Such information allows an observation 504 point in the network to determine not only the path RTT, but also 505 to measure the upstream and downstream contribution to the RTT. 506 This has been used to locate a source of latency, e.g., by 507 observing cases where the ratio of median to minimum RTT is large 508 for a part of a path. 510 The service offered by operators can benefit from latency 511 information to understand the impact of deployment and tune 512 deployed services. Latency metrics are key to evaluating and 513 deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit 514 Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements 515 could identify excessively large buffers, indicating where to 516 deploy or configure AQM. An AQM method is often deployed in 517 combination with other techniques, such as scheduling [RFC7567] 518 [I-D.ietf-aqm-fq-codel] and although parameter-less methods are 519 desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D 520 .ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all 521 possible deployment scenarios. 523 Variation in delay: Some network applications are sensitive to small 524 changes in packet timing. To assess the performance of such 525 applications, it can be necessary to measure the variation in 526 delay observed along a portion of the path [RFC3393] [RFC5481]. 527 The requirements resemble those for the measurement of latency. 529 Flow Reordering: Significant flow reordering can impact time-critical 530 applications and can be interpreted as loss by reliable 531 transports. Many transport protocol techniques are impacted by 532 reordering (e.g., triggering TCP retransmission, or re-buffering 533 of real-time applications). Packet reordering can occur for many 534 reasons (from equipment design to misconfiguration of forwarding 535 rules). Since this impacts transport performance, network tools 536 are needed to detect and measure unwanted/excessive reordering. 538 There have been initiatives in the IETF transport area to reduce 539 the impact of reordering within a transport flow, possibly leading 540 to a reduction in the requirements for preserving ordering. These 541 have promise to simplify network equipment design as well as the 542 potential to improve robustness of the transport service. 543 Measurements of reordering can help understand the present level 544 of reordering within deployed infrastructure, and inform decisions 545 about how to progress such mechanisms. 547 Operational tools to detect mis-ordered packet flows and quantify the 548 degree or reordering. Key performance indicators are retransmission 549 rate, packet drop rate, sector utilisation level, a measure of 550 reordering, peak rate, the CE-marking rate, etc. 552 Metrics have been defined that evaluate whether a network has 553 maintained packet order on a packet-by-packet basis [RFC4737] and 554 [RFC5236]. 556 Techniques for measuring reordering typically observe packet sequence 557 numbers. Some protocols provide in-built monitoring and reporting 558 functions. Transport fields in the RTP header [RFC3550] [RFC4585] 559 can be observed to derive traffic volume measurements and provide 560 information on the progress and quality of a session using RTP. As 561 with other measurement, metadata is often important to understand the 562 context under which the data was collected, including the time, 563 observation point, and way in which metrics were accumulated. The 564 RTCP protocol directly reports some of this information in a form 565 that can be directly visible in the network. A user of summary 566 measurement data needs to trust the source of this data and the 567 method used to generate the summary information. 569 2.1.3. Metrics derived from Network Layer Headers 571 Some transport information is made visible in the network-layer 572 protocol header. These header fields are not encrypted and have been 573 utilised to make flow observations. 575 Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose 576 flow information in the IPv6 Flow Label field of the network-layer 577 header (e.g., [RFC8085]). This can be used to inform network-layer 578 queuing, forwarding (e.g., for equal cost multi-path, ECMP, 579 routing, and Link Aggregation, LAG). This can provide useful 580 information to assign packets to flows in the data collected by 581 measurement campaigns. Although important to characterising a 582 path, it does not directly provide performance data. 584 Use Network-Layer Differentiated Services Code Point Point: Applicati 585 ons can expose their delivery expectations to the network by 586 setting the Differentiated Services Code Point (DSCP) field of 587 IPv4 and IPv6 packets. This can be used to inform network-layer 588 queuing and forwarding, and can also provide information on the 589 relative importance of packet information collected by measurement 590 campaigns, but does not directly provide performance data. 592 This field provides explicit information that can be used in place 593 of inferring traffic requirements (e.g., by inferring QoS 594 requirements from port information via a multi-field classifier). 595 The DSCP value can therefore impact the quality of experience for 596 a flow. Observations of service performance need to consider this 597 field when a network path has support for differentiated service 598 treatment. 600 Use of Explicit Congestion Marking: ECN [RFC3168] is an optional 601 transport mechanism that uses a code point in the network-layer 602 header. Use of ECN can offer gains in terms of increased 603 throughput, reduced delay, and other benefits when used over a 604 path that includes equipment that supports an AQM method that 605 performs Congestion Experienced (CE) marking of IP packets 606 [RFC8087]. 608 ECN exposes the presence of congestion on a network path to the 609 transport and network layer. The reception of CE-marked packets 610 can therefore be used to monitor the presence and estimate the 611 level of incipient congestion on the upstream portion of the path 612 from the point of observation (Section 2.5 of [RFC8087]). Because 613 ECN marks are carried in the IP protocol header, it is much easier 614 to measure ECN than to measure packet loss. However, interpreting 615 the marking behaviour (i.e., assessing congestion and diagnosing 616 faults) requires context from the transport layer (path RTT, 617 visibility of loss - that could be due to queue overflow, 618 congestion response, etc) [RFC7567]. 620 Some ECN-capable network devices can provide richer (more frequent 621 and fine-grained) indication of their congestion state. Setting 622 congestion marks proportional to the level of congestion (e.g., 623 Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable 624 throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. 626 Use of ECN requires a transport to feed back reception information 627 on the path towards the data sender. Exposure of this Transport 628 ECN feedback provides an additional powerful tool to understand 629 ECN-enabled AQM-based networks [RFC8087]. 631 AQM and ECN offer a range of algorithms and configuration options, 632 it is therefore important for tools to be available to network 633 operators and researchers to understand the implication of 634 configuration choices and transport behaviour as use of ECN 635 increases and new methods emerge [RFC7567] [RFC8087]. ECN- 636 monitoring is expected to become important as AQM is deployed that 637 supports ECN [RFC8087]. 639 2.2. Transport Measurement 641 The common language between network operators and application/content 642 providers/users is packet transfer performance at a layer that all 643 can view and analyse. For most packets, this has been transport 644 layer, until the emergence of QUIC, with the obvious exception of 645 Virtual Private Networks (VPNs) and IPsec. 647 When encryption conceals more layers in each packet, people seeking 648 understanding of the network operation rely more on pattern 649 inferences and other heuristics reliance on pattern inferences and 650 accuracy suffers. For example, the traffic patterns between server 651 and browser are dependent on browser supplier and version, even when 652 the sessions use the same server application (e.g., web e-mail 653 access). It remains to be seen whether more complex inferences can be 654 mastered to produce the same monitoring accuracy (see section 2.1.1 655 of [I-D.mm-wg-effect-encrypt]). 657 When measurement datasets are made available by servers or client 658 endpoints, additional metadata, such as the state of the network, is 659 often required to interpret this data. Collecting and coordinating 660 such metadata is more difficult when the observation point is at a 661 different location to the bottleneck/device under evaluation. 663 Packet sampling techniques can be used to scale the processing 664 involved in observing packets on high rate links. This exports only 665 the packet header information of (randomly) selected packets. The 666 utility of these measurements depends on the type of bearer and 667 number of mechanisms used by network devices. Simple routers are 668 relatively easy to manage, a device with more complexity demands 669 understanding of the choice of many system parameters. This level of 670 complexity exists when several network methods are combined. 672 This section discusses topics concerning observation of transport 673 flows, with a focus on transport measurement. 675 2.2.1. Point of Measurement 677 Often measurements can only be understood in the context of the other 678 flows that share a bottleneck. A simple example is monitoring of 679 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 680 queues (statistically assigned per flow), management of the queue 681 length (CODEL), flow-scheduling, and a starvation prevention 682 mechanism. Usually such algorithms are designed to be self-tuning, 683 but current methods typically employ heuristics that can result in 684 more loss under certain path conditions (e.g., large RTT, effects of 685 multiple bottlenecks [RFC7567]). 687 In-network measurements can distinguish between upstream and 688 downstream metrics with respect to a measurement point. These are 689 particularly useful for locating the source of problems or to assess 690 the performance of a network segment or a particular device 691 configuration. By correlating observations of headers at multiple 692 points along the path (e.g., at the ingress and egress of a network 693 segment), an observer can determine the contribution of a portion of 694 the path to an observed metric (to locate a source of delay, jitter, 695 loss, reordering, congestion marking, etc.). 697 2.2.2. Use by Operators to Plan and Provision Networks 698 Traffic measurements (e.g., traffic volume, loss, latency) is used by 699 operators to help plan deployment of new equipment and configurations 700 in their networks. Data is also important to equipment vendors who 701 need to understand traffic trends and patterns of usage as inputs to 702 decisions about planning products and provisioning for new 703 deployments. This measurement information can also be correlated 704 with billing information when this is also collected by an operator. 706 A network operator supporting traffic that uses transport header 707 encryption may not have access to per-flow measurement data. Trends 708 in aggregate traffic can be observed and can be related to the 709 endpoint addresses being used, but it may not be possible to 710 correlate patterns in measurements with changes in transport 711 protocols (e.g., the impact of changes in introducing a new transport 712 protocol mechanism). This increases the dependency on other indirect 713 sources of information to inform planning and provisioning. 715 2.2.3. Service Performance Measurement 717 Traffic measurements (e.g., traffic volume, loss, latency) can be 718 used by various actors to help analyse the performance offered to the 719 users of a network segment, and inform operational practice. 721 While active measurements may be used in-network passive measurements 722 can have advantages in terms of eliminating unproductive traffic, 723 reducing the influence of test traffic on the overall traffic mix, 724 and the ability to choose the point of measurement Section 2.2.1. 725 However, passive measurements may rely on observing transport 726 headers. 728 2.2.4. Measuring Transport to Support Network Operations 730 Information provided by tools observing transport headers can help 731 determine whether mechanisms are needed in the network to prevent 732 flows from acquiring excessive network capacity. Operators can 733 implement operational practices to manage traffic flows (e.g., to 734 prevent flows from acquiring excessive network capacity under severe 735 congestion) by deploying rate-limiters, traffic shaping or network 736 transport circuit breakers [RFC8084]. 738 Congestion Control Compliance of Traffic: Congestion control is a key 739 transport function [RFC2914]. Many network operators implicitly 740 accept that TCP traffic to comply with a behaviour that is 741 acceptable for use in the shared Internet. TCP algorithms have 742 been continuously improved over decades, and they have reached a 743 level of efficiency and correctness that custom application-layer 744 mechanisms will struggle to easily duplicate [RFC8085]. 746 A standards-compliant TCP stack provides congestion control may 747 therefore be judged safe for use across the Internet. 748 Applications developed on top of well-designed transports can be 749 expected to appropriately control their network usage, reacting 750 when the network experiences congestion, by back-off and reduce 751 the load placed on the network. This is the normal expected 752 behaviour for IETF-specified transport (e.g., TCP and SCTP). 754 However, when anomalies are detected, tools can interpret the 755 transport protocol header information to help understand the 756 impact of specific transport protocols (or protocol mechanisms) on 757 the other traffic that shares a network. An observation in the 758 network can gain understanding of the dynamics of a flow and its 759 congestion control behaviour. Analysing observed packet sequence 760 numbers can be used to help build confidence that an application 761 flow backs-off its share of the network load in the face of 762 persistent congestion, and hence to understand whether the 763 behaviour is appropriate for sharing limited network capacity. 764 For example, it is common to visualise plots of TCP sequence 765 numbers versus time for a flow to understand how a flow shares 766 available capacity, deduce its dynamics in response to congestion, 767 etc. 769 Congestion Control Compliance for UDP traffic UDP provides a minimal 770 message-passing datagram transport that has no inherent congestion 771 control mechanisms. Because congestion control is critical to the 772 stable operation of the Internet, applications and other protocols 773 that choose to use UDP as a transport are required to employ 774 mechanisms to prevent congestion collapse, avoid unacceptable 775 contributions to jitter/latency, and to establish an acceptable 776 share of capacity with concurrent traffic [RFC8085]. 778 A network operator needs tools to understand if datagram flows 779 comply with congestion control expectations and therefore whether 780 there is a need to deploy methods such as rate-limiters, transport 781 circuit breakers or other methods to enforce acceptable usage for 782 the offered service. 784 UDP flows that expose a well-known header by specifying the format 785 of header fields can allow information to be observed to gain 786 understanding of the dynamics of a flow and its congestion control 787 behaviour. For example, tools exist to monitor various aspects of 788 the RTP and RTCP header information of real-time flows (see 789 Section 2.1.2. 791 2.3. Use for Network Diagnostics and Troubleshooting 792 Transport header information can be useful for a variety of 793 operational tasks [I-D.mm-wg-effect-encrypt]: to diagnose network 794 problems, assess network provider performance, evaluate equipment/ 795 protocol performance, capacity planning, management of security 796 threats (including denial of service), and responding to user 797 performance questions. Sections 3.1.2 and 5 of [I-D.mm-wg-effect- 798 encrypt] provide further examples. These tasks seldom involve the 799 need to determine the contents of the transport payload, or other 800 application details. 802 A network operator supporting traffic that uses transport header 803 encryption can see only encrypted transport headers. This prevents 804 deployment of performance measurement tools that rely on transport 805 protocol information. Choosing to encrypt all the information 806 reduces the operator's ability to observe transport performance, and 807 may limit the ability of network operators to trace problems, make 808 appropriate QoS decisions, or response to other queries about the 809 network service. For some this will be blessing, for others it may 810 be a curse. For example, operational performance data about 811 encrypted flows needs to be determined by traffic pattern analysis, 812 rather than relying on traditional tools. This can impact the 813 ability of the operator to respond to faults, it could require 814 reliance on endpoint diagnostic tools or user involvement in 815 diagnosing and troubleshooting unusual use cases or non-trivial 816 problems. A key need here is for tools to provide useful information 817 during network anomalies (e.g., significant reordering, high or 818 intermittent loss). Although many network operators utilise transport 819 information as a part of their operational practice, the network will 820 not break because transport headers are encrypted, and this may 821 require alternative tools may need to be developed and deployed. 823 2.3.1. Examples of measurements 825 Measurements can be used to monitor the health of a portion of the 826 Internet, to provide early warning of the need to take action. They 827 can assist in debugging and diagnosing the root causes of faults that 828 concern a particular user's traffic. They can also be used to 829 support post-mortem investigation after an anomaly to determine the 830 root cause of a problem. 832 In some case, measurements may involve active injection of test 833 traffic to complete a measurement. However, most operators do not 834 have access to user equipment, and injection of test traffic may be 835 associated with costs in running such tests (e.g., the implications 836 of bandwidth tests in a mobile network are obvious). Some active 837 measurements (e.g., response under load or particular workloads) 838 perturb other traffic, and could require dedicated access to the 839 network segment. An alternative approach is to use in-network 840 techniques that observe transport packet headers in operational 841 networks to make the measurements. 843 In other cases, measurement involves dissecting network traffic 844 flows. The observed transport layer information can help identify 845 whether the link/network tuning is effective and alert to potential 846 problems that can be hard to derive from link or device measurements 847 alone. The design trade-offs for radio networks are often very 848 different to those of wired networks. A radio-based network (e.g., 849 cellular mobile, enterprise WiFi, satellite access/back-haul, point- 850 to-point radio) has the complexity of a subsystem that performs radio 851 resource management,s with direct impact on the available capacity, 852 and potentially loss/reordering of packets. The impact of the 853 pattern of loss and congestion, differs for different traffic types, 854 correlation with propagation and interference can all have 855 significant impact on the cost and performance of a provided service. 856 The need for this type of information is expected to increase as 857 operators bring together heterogeneous types of network equipment and 858 seek to deploy opportunistic methods to access radio spectrum. 860 2.4. Observing Headers to Implement Network Policy 862 Information from the transport protocol can be used by a multi-field 863 classifier as a part of policy framework. Policies are commonly used 864 for management of the QoS or Quality of Experience (QoE) in resource- 865 constrained networks and by firewalls that use the information to 866 implement access rules (see also section 2.2.2 of [I-D.mm-wg-effect- 867 encrypt]). Traffic that cannot be classified, will typically receive 868 a default treatment. 870 3. Encryption and Authentication of Transport Headers 872 End-to-end encryption can be applied at various protocol layers. It 873 can be applied above the transport to encrypt the transport payload. 874 Encryption methods can hide information from an eavesdropper in the 875 network. Encryption can also help protect the privacy of a user, by 876 hiding data relating to user/device identity or location. Neither an 877 integrity check nor encryption methods prevent traffic analysis, and 878 usage needs to reflect that profiling of users, identification of 879 location and fingerprinting of behaviour can take place even on 880 encrypted traffic flows. 882 There are several motivations: 884 o One motive to use encryption is a response to perceptions that the 885 network has become ossified by over-reliance on middleboxes that 886 prevent new protocols and mechanisms from being deployed. This 887 has lead to a perception that there is too much "manipulation" of 888 protocol headers within the network, and that designing to deploy 889 in such networks is preventing transport evolution. In the light 890 of this, a method that authenticates transport headers may help 891 improve the pace of transport development, by eliminating the need 892 to always consider deployed middleboxes [I-D.trammell-plus- 893 abstract-mech], or potentially to only explicitly enable middlebox 894 use for particular paths with particular middleboxes that are 895 deliberately deployed to realise a useful function for the network 896 and/or users[RFC3135]. 898 o Another motivation stems from increased concerns about privacy and 899 surveillance. Some Internet users have valued the ability to 900 protect identity, user location, and defend against traffic 901 analysis, and have used methods such as IPsec Encapsulated 902 Security Payload (ESP), Virtual Private Networks (VPNs) and other 903 encrypted tunnel technologies. Revelations about the use of 904 pervasive surveillance [RFC7624] have, to some extent, eroded 905 trust in the service offered by network operators, and following 906 the Snowden revelation in the USA in 2013 has led to an increased 907 desire for people to employ encryption to avoid unwanted 908 "eavesdropping" on their communications. Concerns have also been 909 voiced about the addition of information to packets by third 910 parties to provide analytics, customization, advertising, cross- 911 site tracking of users, to bill the customer, or to selectively 912 allow or block content. Whatever the reasons, there are now 913 activities in the IETF to design new protocols that may include 914 some form of transport header encryption (e.g., QUIC [I-D.ietf- 915 quic-transport]). 917 Authentication methods (that provide integrity checks of protocols 918 fields) have also been specified at the network layer, and this also 919 protects transport header fields. The network layer itself carries 920 protocol header fields that are increasingly used to help forwarding 921 decisions reflect the need of transport protocols, such as the IPv6 922 Flow Label [RFC6437], the DSCP and ECN. 924 The use of transport layer authentication and encryption exposes a 925 tussle between middlebox vendors, operators, applications developers 926 and users. 928 o On the one hand, future Internet protocols that enable large-scale 929 encryption assist in the restoration of the end-to-end nature of 930 the Internet by returning complex processing to the endpoints, 931 since middleboxes cannot modify what they cannot see. 933 o On the other hand, encryption of transport layer header 934 information has implications for people who are responsible for 935 operating networks and researchers and analysts seeking to 936 understand the dynamics of protocols and traffic patterns. 938 Whatever the motives, a decision to use pervasive of transport header 939 encryption will have implications on the way in which design and 940 evaluation is performed, and which can in turn impact the direction 941 of evolution of the TCP/IP stack. While the IETF can specify 942 protocols, the success in actual deployment is often determined by 943 many factors [RFC5218] that are not always clear at the time when 944 protocols are being defined. 946 The next subsections briefly review some security design options for 947 transport protocols. A Survey of Transport Security Protocols [I-D 948 .ietf-taps-transport-security] provides more details concerning 949 commonly used encryption methods at the transport layer. 951 3.1. Authenticating the Transport Protocol Header 953 Transport layer header information can be authenticated. An 954 integrity check that protects the immutable transport header fields, 955 but can still expose the transport protocol header information in the 956 clear, allowing in-network devices to observes these fields. An 957 integrity check can not prevent in-network modification, but can 958 avoid a receiving accepting changes and avoid impact on the transport 959 protocol operation. 961 An example transport authentication mechanism is TCP-Authentication 962 (TCP-AO) [RFC5925]. This TCP option authenticates the IP pseudo 963 header, TCP header, and TCP data. TCP-AO protects the transport 964 layer, preventing attacks from disabling the TCP connection itself 965 and provides replay protection. TCP-AO may interact with 966 middleboxes, depending on their behaviour [RFC3234]. 968 The IPsec Authentication Header (AH) [RFC4302] was designed to work 969 at the network layer and authenticate the IP payload. This approach 970 authenticates all transport headers, and verifies their integrity at 971 the receiver, preventing in-network modification. 973 3.2. Encrypting the Transport Payload 975 The transport layer payload can be encrypted to protect the content 976 of transport segments. This leaves transport protocol header 977 information in the clear. The integrity of immutable transport 978 header fields could be protected by combining this with an integrity 979 check (Section 3.1). 981 Examples of encrypting the payload include Transport Layer Security 982 (TLS) over TCP [RFC5246] [RFC7525], Datagram TLS (DTLS) over UDP 983 [RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which 984 permits opportunistic encryption of the TCP transport payload. 986 3.3. Encrypting the Transport Header 987 The network layer payload could be encrypted (including the entire 988 transport header and the payload). This method provides 989 confidentiality of the entire transport packet. It therefore does 990 not expose any transport information to devices in the network, which 991 also prevents modification along a network path. 993 One example of encryption at the network layer is use of IPsec 994 Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This 995 encrypts and authenticates all transport headers, preventing 996 visibility of the transport headers by in-network devices. Some 997 Virtual Private Network (VPN) methods also encrypt these headers. 999 3.4. Authenticating Transport Information and Selectively Encrypting 1000 the Transport Header 1002 A transport protocol design can encrypt selected header fields, while 1003 also choosing to authenticate fields in the transport header. This 1004 allows specific transport header fields to be made observable by 1005 network devices. End-to end integrity checks can prevent an endpoint 1006 from undetected modification of the immutable transport headers. 1008 Mutable fields in the transport header provide opportunities for 1009 middleboxes to modify the transport behaviour (e.g., the extended 1010 headers described in [I-D.trammell-plus-abstract-mech]). This 1011 considers only immutable fields in the transport headers, that is, 1012 fields that may be authenticated End-to-End across a path. 1014 An example of a method that encrypts some, but not all, transport 1015 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 1017 3.5. Optional Encryption of Header Information 1019 There are implications to the use of optional header encryption in 1020 the design of a transport protocol, where support of optional 1021 mechanisms can increase the complexity of the protocol and its 1022 implementation and in the management decisions that are required to 1023 use variable format fields. Instead, fields of a specific type ought 1024 to always be sent with the same level of confidentiality or integrity 1025 protection. 1027 4. Addition of Transport Information to Network-Layer Protocol Headers 1029 Transport protocol information can be made visible in a network-layer 1030 header. This has the advantage that this information can then be 1031 observed by in-network devices. This has the advantage that a single 1032 header can support all transport protocols, but there may also be 1033 less desirable implications of separating the operation of the 1034 transport protocol from the measurement framework. 1036 Some measurements may be made by adding additional protocol headers 1037 carrying operations, administration and management (OAM) information 1038 to packets at the ingress to a maintenance domain (e.g., an Ethernet 1039 protocol header with timestamps and sequence number information using 1040 a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) 1041 and removing the additional header at the egress of the maintenance 1042 domain. This approach enables some types of measurements, but does 1043 not cover the entire range of measurements described in this 1044 document. In some cases, it can be difficult to position measurement 1045 tools at the required segments/nodes and there can be challenges in 1046 correlating the downsream/upstream information when in-band OAM data 1047 is inserted by an on-path device. 1049 Another example of a network-layer approach is the IPv6 Performance 1050 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 1051 pdm-option]. This allows a sender to optionally include a 1052 destination option that caries header fields that can be used to 1053 observe timestamps and packet sequence numbers. This information 1054 could be authenticated by receiving transport endpoints when the 1055 information is added at the sender and visible at the receiving 1056 endpoint, although methods to do this have not currently been 1057 proposed. This method needs to be explicitly enabled at the sender. 1059 It can be undesirable to rely on methods requiring the presence of 1060 network options or extension headers. IPv4 network options are often 1061 not supported (or are carried on a slower processing path) and some 1062 IPv6 networks are also known to drop packets that set an IPv6 header 1063 extension (e.g., [RFC7872]). Another disadvantage is that protocols 1064 that separately expose header information do not necessarily have an 1065 advantage to expose the information that is utilised by the protocol 1066 itself, and could manipulate this header information to gain an 1067 advantage from the network. 1069 5. Implications of Protecting the Transport Headers 1071 The choice of which fields to expose and which to encrypt is a design 1072 choice for the transport protocol. Any selective encryption method 1073 requires trading two conflicting goals for a transport protocol 1074 designer to decide which header fields to encrypt. Security work 1075 typically employs a design technique that seeks to expose only what 1076 is needed. However, there can be performance and operational 1077 benefits in exposing selected information to network tools. 1079 This section explores key implications of working with encrypted 1080 transport protocols. 1082 5.1. Independent Measurement 1083 Independent observation by multiple actors is important for 1084 scientific analysis. Encrypting transport header encryption changes 1085 the ability for other actors to collect and independently analyse 1086 data. Internet transport protocols employ a set of mechanisms. Some 1087 of these need to work in cooperation with the network layer - loss 1088 detection and recovery, congestion detection and congestion control, 1089 some of these need to work only End-to-End (e.g., parameter 1090 negotiation, flow-control). 1092 When encryption conceals information in the transport header, it 1093 could be possible for an applications to provide summary data on 1094 performance and usage of the network. This data could be made 1095 available to other actors. However, this data needs to contain 1096 sufficient detail to understand (and possibly reconstruct the network 1097 traffic pattern for further testing) and to be correlated with the 1098 configuration of the network paths being measured. 1100 Sharing information between actors needs also to consider the privacy 1101 of the user and the incentives for providing accurate and detailed 1102 information. Protocols that expose the state information used by the 1103 transport protocol in their header information (e.g., timestamps used 1104 to calculate the RTT, packet numbers used to asses congestion and 1105 requests for retransmission) provide an incentive for the sending 1106 endpoint to provide correct information, increasing confidence that 1107 the observer understands the transport interaction with the network. 1108 This becomes important when considering changes to transport 1109 protocols, changes in network infrastructure, or the emergence of new 1110 traffic patterns. 1112 5.2. Characterising "Unknown" Network Traffic 1114 The patterns and types of traffic that share Internet capacity 1115 changes with time as networked applications, usage patterns and 1116 protocols continue to evolve. 1118 If "unknown" or "uncharacterised" traffic patterns form a small part 1119 of the traffic aggregate passing through a network device or segment 1120 of the network the path, the dynamics of the uncharacterised traffic 1121 may not have a significant collateral impact on the performance of 1122 other traffic that shares this network segment. Once the proportion 1123 of this traffic increases, the need to monitor the traffic and 1124 determine if appropriate safety measures need to be put in place. 1126 Tracking the impact of new mechanisms and protocols requires traffic 1127 volume to be measured and new transport behaviours to be identified. 1128 This is especially true of protocols operating over a UDP substrate. 1130 The level and style of encryption needs to be considered in 1131 determining how this activity is performed. On a shorter timescale, 1132 information may also need to be collected to manage denial of service 1133 attacks against the infrastructure. 1135 5.3. Accountability and Internet Transport Protocols 1137 Information provided by tools observing transport headers can be used 1138 to classify traffic, and to limit the network capacity used by 1139 certain flows. Operators can potentially use this information to 1140 prioritise or de-prioritise certain flows or classes of flow, with 1141 potential implications for network neutrality, or to rate limit 1142 malicious or otherwise undesirable flows (e.g., for DDoS protection, 1143 or to ensure compliance with a traffic profile Section 2.2.4). 1144 Equally, operators could use analysis of transport headers and 1145 transport flow state to demonstrate that they are not providing 1146 differential treatment to certain flows. Obfuscating or hiding this 1147 information using encryption is expected to lead operators and 1148 maintainers of middleboxes (firewalls, etc.) to seek other methods to 1149 classify, and potentially other mechanisms to condition, network 1150 traffic. 1152 A lack of data reduces the level of precision with which flows can be 1153 classified and conditioning mechanisms are applied (e.g., rate 1154 limiting, circuit breaker techniques [RFC8084], or blocking of 1155 uncharacterised traffic), and this needs to be considered when 1156 evaluating the impact of designs for transport encryption [RFC5218]. 1158 5.4. Impact on Research, Development and Deployment 1160 The majority of present Internet applications use two well-known 1161 transport protocols: e.g., TCP and UDP. Although TCP represents the 1162 majority of current traffic, some important real-time applications 1163 use UDP, and much of this traffic utilises RTP format headers in the 1164 payload of the UDP datagram. Since these protocol headers have been 1165 fixed for decades, a range of tools and analysis methods have became 1166 common and well-understood. Over this period, the transport protocol 1167 headers have mostly changed slowly, and so also the need to develop 1168 tools track new versions of the protocol. 1170 Looking ahead, there will be a need to update these protocols and to 1171 develop and deploy new transport mechanisms and protocols. There are 1172 both opportunities and also challenges to the design, evaluation and 1173 deployment of new transport protocol mechanisms. 1175 Integrity checks can protect an endpoint from undetected modification 1176 of protocol fields by network devices, whereas encryption and 1177 obfuscation can further prevent these headers being utilised by 1178 network devices. Hiding headers can therefore provide the 1179 opportunity for greater freedom to update the protocols and can ease 1180 experimentation with new techniques and their final deployment in 1181 endpoints. 1183 Hiding headers can limit the ability to measure and characterise 1184 traffic. Measurement data is increasingly being used to inform 1185 design decisions in networking research, during development of new 1186 mechanisms and protocols and in standardisation. Measurement has a 1187 critical role in the design of transport protocol mechanisms and 1188 their acceptance by the wider community (e.g., as a method to judge 1189 the safety for Internet deployment). Observation of pathologies are 1190 also important in understanding the interactions between cooperating 1191 protocols and network mechanism, the implications of sharing capacity 1192 with other traffic and the impact of different patterns of usage. 1194 Evolution and the ability to understand (measure) the impact need to 1195 proceed hand-in-hand. Attention needs to be paid to the expected 1196 scale of deployment of new protocols and protocol mechanisms. 1197 Whatever the mechanism, experience has shown that it is often 1198 difficult to correctly implement combination of mechanisms [RFC8085]. 1199 These mechanisms therefore typically evolve as a protocol matures, or 1200 in response to changes in network conditions, changes in network 1201 traffic or changes to application usage. 1203 New transport protocol formats are expected to facilitate an 1204 increased pace of transport evolution, and with it the possibility to 1205 experiment with and deploy a wide range of protocol mechanisms. 1206 There has been recent interest in a wide range of new transport 1207 methods, e.g., Larger Initial Window, Proportional Rate Reduction 1208 (PRR), congestion control methods based on measuring bottleneck 1209 bandwidth and round-trip propagation time, the introduction of AQM 1210 techniques and new forms of ECN response (e.g., Data Centre TCP, 1211 DCTP, and methods proposed for L4S).The growth and diversity of 1212 applications and protocols using the Internet also continues to 1213 expand. For each new method or application it is desirable to build 1214 a body of data reflecting its behaviour under a wide range of 1215 deployment scenarios, traffic load, and interactions with other 1216 deployed/candidate methods. 1218 Open standards motivate a desire for this evaluation to include 1219 independent observation and evaluation of performance data, which in 1220 turn suggests control over where and when measurement samples are 1221 collected. This requires consideration of the appropriate balance 1222 between encrypting all and no transport information. 1224 6. Conclusions 1226 The majority of present Internet applications use two well-known 1227 transport protocols: e.g., TCP and UDP. Although TCP represents the 1228 majority of current traffic, some important real-time applications 1229 have used UDP, and much of this traffic utilises RTP format headers 1230 in the payload of the UDP datagram. Since these protocol headers 1231 have been fixed for decades, a range of tools and analysis methods 1232 have became common and well-understood. Over this period, the 1233 transport protocol headers have mostly changed slowly, and so also 1234 the need to develop tools track new versions of the protocol. 1236 Confidentiality and strong integrity checks have properties that are 1237 being incorporated into new protocols and which have important 1238 benefits. The pace of development of transports using the WebRTC 1239 data channel and the rapid deployment of QUIC prototype transports 1240 can both be attributed to using a combination of UDP transport and 1241 confidentiality of the UDP payload. 1243 The traffic that can be observed by on-path network devices is a 1244 function of transport protocol design/options, network use, 1245 applications and user characteristics. In general, when only a small 1246 proportion of the traffic has a specific (different) characteristic. 1247 Such traffic seldom leads to an operational issue although the 1248 ability to measure and monitor it is less. The desire to understand 1249 the traffic and protocol interactions typically grows as the 1250 proportion of traffic increases in volume. The challenges increase 1251 when multiple instances of an evolving protocol contribute to the 1252 traffic that share network capacity. 1254 An increased pace of evolution therefore needs to be accompanied by 1255 methods that can be successfully deployed and used across operational 1256 networks. This leads to a need for network operators (at various 1257 level (ISPs, enterprises, firewall maintainer, etc) to identify 1258 appropriate operational support functions and procedures. 1260 Protocols that change their transport header format (wire format) or 1261 their behaviour (e.g., algorithms that are needed to classify and 1262 characterise the protocol), will require new tooling needs to be 1263 developed to catch-up with the changes. If the currently deployed 1264 tools and methods are no longer relevant and performance may not be 1265 correctly measured. This can increase the response-time after 1266 faults, and can impact the ability to manage the network resulting in 1267 traffic causing traffic to be treated inappropriately (e.g., rate 1268 limiting because of being incorrectly classified/monitored). There 1269 are benefits in exposing consistent information to the network that 1270 avoids traffic being mis-classified and then receiving a default 1271 treatment by the network. 1273 As a part of its design a new protocol specification therefore needs 1274 to weigh the benefits of ossifying common headers, versus the 1275 potential demerits of exposing specific information that could be 1276 observed along the network path to provide tools to manage new 1277 variants of protocols. Several scenarios to illustrate different 1278 ways this could evolve are provided below: 1280 o One scenario is when transport protocols provide consistent 1281 information to the network by intentionally exposing a part of the 1282 transport header. The design fixes the format of this information 1283 between versions of the protocol. This ossification of the 1284 transport header allows an operator to establish tooling and 1285 procedures that enable it to provide consistent traffic management 1286 as the protocol evolves. In contrast to TCP (where all protocol 1287 information is exposed), evolution of the transport is facilitated 1288 by providing cryptographic integrity checks of the transport 1289 header fields (preventing undetected middlebox changes) and 1290 encryption of other protocol information (preventing observation 1291 within the network, or incentivising the use of the exposed 1292 information, rather than inferring information from other 1293 characteristics of the flow traffic). The exposed transport 1294 information can be used by operators to provide troubleshooting, 1295 measurement and any necessary functions appropriate to the class 1296 of traffic (priority, retransmission, reordering, circuit 1297 breakers, etc). 1299 o An alternative scenario adopts different design goals, with a 1300 different outcome. A protocol that encrypts all header 1301 information forces network operators to act independently from 1302 apps/transport developments to provide the transport information 1303 they need. A range of approaches may proliferate, as in current 1304 networks, operators can add a shim header to each packet as a flow 1305 as it crosses the network; other operators/managers could develop 1306 heuristics and pattern recognition to derive information that 1307 classifies flows and estimates quality metrics for the service 1308 being used; some could decide to rate-limit or block traffic until 1309 new tooling is in place. In many cases, the derived information 1310 can be used by operators to provide necessary functions 1311 appropriate to the class of traffic (priority, retransmission, 1312 reordering, circuit breakers, etc). Troubleshooting, and 1313 measurement becomes more difficult, and more diverse. This could 1314 require additional information beyond that visible in the packet 1315 header and when this information is used to inform decisions by 1316 on-path devices it can lead to dependency on other characteristics 1317 of the flow. In some cases, operators might need access to keying 1318 information to interpret encrypted data that they observe. Some 1319 use cases could demand use of transports that do not use 1320 encryption. 1322 The outcome could have significant implications on the way the 1323 Internet architecture develops. It exposes a risk that significant 1324 actors (e.g., developers and transport designers) achieve more 1325 control of the way in which the Internet architecture develops.In 1326 particular, there is a possibility that designs could evolve to 1327 significantly benefit of customers for a specific vendor, and that 1328 communities with very different network, applications or platforms 1329 could then suffer at the expense of benefits to their vendors own 1330 customer base. In such a scenario, there could be no incentive to 1331 support other applications/products or to work in other networks 1332 leading to reduced access for new approaches. 1334 7. Acknowledgements 1336 The author would like to thank all who have talked to him face-to- 1337 face or via email. ... 1339 This work has received funding from the European Union's Horizon 2020 1340 research and innovation programme under grant agreement No 688421.The 1341 opinions expressed and arguments employed reflect only the authors' 1342 view. The European Commission is not responsible for any use that 1343 may be made of that information. 1345 8. Security Considerations 1346 This document is about design and deployment considerations for 1347 transport protocols. Authentication, confidentiality protection, and 1348 integrity protection are identified as Transport Features by 1349 RFC8095". As currently deployed in the Internet, these features are 1350 generally provided by a protocol or layer on top of the transport 1351 protocol; no current full-featured standards-track transport protocol 1352 provides these features on its own. Therefore, these features are 1353 not considered in this document, with the exception of native 1354 authentication capabilities of TCP and SCTP for which the security 1355 considerations in RFC4895. 1357 Open data, and accessibility to tools that can help understand trends 1358 in application deployment, network traffic and usage patterns can all 1359 contribute to understanding security challenges. Standard protocols 1360 and understanding of the interactions between mechanisms and traffic 1361 patterns can also provide valuable insight into appropriate security 1362 design. Like congestion control mechanisms, security mechanisms are 1363 difficult to design and implement correctly. It is hence recommended 1364 that applications employ well-known standard security mechanisms such 1365 as DTLS, TLS or IPsec, rather than inventing their own. 1367 9. IANA Considerations 1369 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1371 This memo includes no request to IANA. 1373 10. References 1375 10.1. Normative References 1377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1378 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1379 RFC2119, March 1997, . 1382 10.2. Informative References 1384 [I-D.dolson-plus-middlebox-benefits] 1385 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1386 "Beneficial Functions of Middleboxes", Internet-Draft 1387 draft-dolson-plus-middlebox-benefits-03, March 2017. 1389 [I-D.ietf-aqm-codel] 1390 Nichols, K., Jacobson, V., McGregor, A. and J. Iyengar, 1391 "Controlled Delay Active Queue Management", Internet-Draft 1392 draft-ietf-aqm-codel-10, October 2017. 1394 [I-D.ietf-aqm-fq-codel] 1395 Hoeiland-Joergensen, T., McKenney, P., 1396 dave.taht@gmail.com, d., Gettys, J. and E. Dumazet, "The 1397 FlowQueue-CoDel Packet Scheduler and Active Queue 1398 Management Algorithm", Internet-Draft draft-ietf-aqm-fq- 1399 codel-06, March 2016. 1401 [I-D.ietf-aqm-pie] 1402 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1403 Lightweight Control Scheme To Address the Bufferbloat 1404 Problem", Internet-Draft draft-ietf-aqm-pie-10, September 1405 2016. 1407 [I-D.ietf-ippm-6man-pdm-option] 1408 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1409 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1410 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1411 option-13, June 2017. 1413 [I-D.ietf-ippm-ioam-data] 1414 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1415 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1416 P., Chang, R., daniel.bernier@bell.ca, d. and J. Lemon, 1417 "Data Fields for In-situ OAM", Internet-Draft draft-ietf- 1418 ippm-ioam-data-02, March 2018. 1420 [I-D.ietf-quic-transport] 1421 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1422 and Secure Transport", Internet-Draft draft-ietf-quic- 1423 transport-03, May 2017. 1425 [I-D.ietf-taps-transport-security] 1426 Pauly, T., Perkins, C., Rose, K. and C. Wood, "A Survey of 1427 Transport Security Protocols", Internet-Draft draft-ietf- 1428 taps-transport-security-01, May 2018. 1430 [I-D.ietf-tcpinc-tcpcrypt] 1431 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1432 Q. and E. Smith, "Cryptographic protection of TCP Streams 1433 (tcpcrypt)", Internet-Draft draft-ietf-tcpinc-tcpcrypt-11, 1434 November 2017. 1436 [I-D.ietf-tcpm-accurate-ecn] 1437 Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More 1438 Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- 1439 tcpm-accurate-ecn-06, March 2018. 1441 [I-D.ietf-tsvwg-l4s-arch] 1442 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1443 Low Loss, Scalable Throughput (L4S) Internet Service: 1444 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1445 arch-01, October 2017. 1447 [I-D.mm-wg-effect-encrypt] 1448 Moriarty, K. and A. Morton, "Effects of Pervasive 1449 Encryption on Operators", Internet-Draft draft-mm-wg- 1450 effect-encrypt-24, March 2018. 1452 [I-D.thomson-quic-grease] 1453 Thomson, M., "More Apparent Randomization for QUIC", 1454 Internet-Draft draft-thomson-quic-grease-00, December 1455 2017. 1457 [I-D.trammell-plus-abstract-mech] 1458 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1459 Layer under Endpoint Control", Internet-Draft draft- 1460 trammell-plus-abstract-mech-00, September 2016. 1462 [I-D.trammell-plus-statefulness] 1463 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1464 "Transport-Independent Path Layer State Management", 1465 Internet-Draft draft-trammell-plus-statefulness-02, 1466 December 2016. 1468 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1469 Techniques and Their Merits", November 2014. 1471 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1472 based Protocol Design", June 2017. 1474 [RFC1273] Schwartz, M.F., "Measurement Study of Changes in Service- 1475 Level Reachability in the Global TCP/IP Internet: Goals, 1476 Experimental Design, Implementation, and Policy 1477 Considerations", RFC 1273, DOI 10.17487/RFC1273, November 1478 1991, . 1480 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1481 "Definition of the Differentiated Services Field (DS 1482 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1483 10.17487/RFC2474, December 1998, . 1486 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1487 2914, DOI 10.17487/RFC2914, September 2000, . 1490 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1491 Shelby, "Performance Enhancing Proxies Intended to 1492 Mitigate Link-Related Degradations", RFC 3135, DOI 1493 10.17487/RFC3135, June 2001, . 1496 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1497 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1498 DOI 10.17487/RFC3168, September 2001, . 1501 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1502 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1503 . 1505 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1506 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1507 10.17487/RFC3393, November 2002, . 1510 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1511 Sooriyabandara, "TCP Performance Implications of Network 1512 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1513 December 2002, . 1515 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1516 Jacobson, "RTP: A Transport Protocol for Real-Time 1517 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1518 July 2003, . 1520 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1521 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1522 December 2005, . 1524 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1525 10.17487/RFC4302, December 2005, . 1528 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1529 4303, DOI 10.17487/RFC4303, December 2005, . 1532 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1533 "Extended RTP Profile for Real-time Transport Control 1534 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1535 10.17487/RFC4585, July 2006, . 1538 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1539 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1540 10.17487/RFC4737, November 2006, . 1543 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1544 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1545 . 1547 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1548 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1549 DOI 10.17487/RFC5236, June 2008, . 1552 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1553 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1554 RFC5246, August 2008, . 1557 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1558 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1559 March 2009, . 1561 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1562 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1563 . 1565 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1566 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1567 June 2010, . 1569 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. 1570 Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 1571 10.17487/RFC6269, June 2011, . 1574 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1575 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1576 January 2012, . 1578 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1579 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1580 RFC6437, November 2011, . 1583 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1584 and K. Carlberg, "Explicit Congestion Notification (ECN) 1585 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1586 2012, . 1588 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1589 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1590 2014, . 1592 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1593 for Secure Use of Transport Layer Security (TLS) and 1594 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1595 7525, DOI 10.17487/RFC7525, May 2015, . 1598 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1599 Recommendations Regarding Active Queue Management", BCP 1600 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1603 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1604 Trammell, B., Huitema, C. and D. Borkmann, 1605 "Confidentiality in the Face of Pervasive Surveillance: A 1606 Threat Model and Problem Statement", RFC 7624, DOI 1607 10.17487/RFC7624, August 2015, . 1610 [RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations 1611 on the Dropping of Packets with IPv6 Extension Headers in 1612 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 1613 2016, . 1615 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1616 Ros, "Characterization Guidelines for Active Queue 1617 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1618 2016, . 1620 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1621 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1624 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1625 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1626 March 2017, . 1628 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1629 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1630 2017, . 1632 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1633 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1634 10.17487/RFC8087, March 2017, . 1637 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1638 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 1639 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 1640 October 2017, . 1642 [Tor] The Tor Project, ., "https://www.torproject.org", June 1643 2017. 1645 Appendix A. Revision information 1647 -00 This is an individual draft for the IETF community. 1649 -01 This draft was a result of walking away from the text for a few 1650 days and then reorganising the content. 1652 -02 This draft fixes textual errors. 1654 -03 This draft follows feedback from people reading this draft. 1656 -04 This adds an additional contributor and includes significant 1657 reworking to ready this for review by the wider IETF community Colin 1658 Perkins joined the author list. 1660 Comments from the community are welcome on the text and 1661 recommendations. 1663 -05 Corrections received and helpful inputs from Mohamed Boucadair. 1665 -06 Updated following comments from Stephen Farrell, and feedback via 1666 email. Added a draft conclusion section to sketch some strawman 1667 scenarios that could emerge. 1669 -07 Updated following comments from Al Morton, Chris Seal, and other 1670 feedback via email. 1672 -08 Updated to address comments sent to the TSVWG mailing list by 1673 Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on 11/05/ 1674 2018, and Spencer Dawkins. 1676 Authors' Addresses 1678 Godred Fairhurst 1679 University of Aberdeen 1680 Department of Engineering 1681 Fraser Noble Building 1682 Aberdeen, AB24 3UE 1683 Scotland 1685 Email: gorry@erg.abdn.ac.uk 1686 URI: http://www.erg.abdn.ac.uk/ 1688 Colin Perkins 1689 University of Glasgow 1690 School of Computing Science 1691 Glasgow, G12 8QQ 1692 Scotland 1694 Email: csp@csperkins.org 1695 URI: https://csperkins.org//