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