idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines 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 (June 07, 2017) is 2513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1312, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aqm-codel' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1340, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-accurate-ecn' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1427, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1460, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-00 == Outdated reference: A later version (-06) exists of draft-ietf-aqm-fq-codel-00 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-00 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-00 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-06 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-00 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-11 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 18 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 June 07, 2017 5 Expires: December 07, 2017 7 The Impact of Transport Header Encryption on Operation and Evolution of 8 the Internet 9 draft-fairhurst-tsvwg-transport-encrypt-02 11 Abstract 13 This document describes the implications of applying end-to-end 14 encryption at the transport layer. It identifies some in-network 15 uses of transport layer header information that can be used with a 16 transport header integrity check. It reviews the implication of 17 developing encrypted end-to-end transport protocols and examines the 18 implication of developing and deploying encrypted end-to-end 19 transport protocols. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 07, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Internet Transports and Pervasive Encryption . . . . . . . . . 4 56 2.1. Authenticating the Transport Protocol Header . . . . . . . 5 57 2.2. Encrypting the Transport Payload . . . . . . . . . . . . . 6 58 2.3. Encrypting the Transport Header . . . . . . . . . . . . . 6 59 2.4. Authenticating Transport Information and Selectively 60 Encrypting the Transport Header . . . . . . . . . . . . . 6 61 2.5. Adding Transport Information to Network-Layer Protocol 62 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Use of Transport Headers in the Network . . . . . . . . . . . 8 64 3.1. Use to Identify Flows and Packet Formats . . . . . . . . . 9 65 3.2. Measurements derived from Transport Header Information . . 9 66 3.2.1. Use to Characterise Traffic Rate and Volume . . . . . 9 67 3.2.2. Measuring Loss Rate and Loss Pattern . . . . . . . . . 10 68 3.2.3. Measuring Throughput and Goodput . . . . . . . . . . . 10 69 3.2.4. Measuring Latency (Network Transit Delay and Jitter) . 10 70 3.2.5. Measuring Flow Reordering . . . . . . . . . . . . . . 11 71 3.3. Measurements derived from Network-Transport Information . 11 72 3.3.1. Use of IPv6 Network-Layer Flow Label . . . . . . . . . 12 73 3.3.2. Use Network-Layer Differentiated Services Code Point 74 Point . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.3.3. Use of Explicit Congestion Marking . . . . . . . . . . 12 76 4. Transport Measurement . . . . . . . . . . . . . . . . . . . . 13 77 4.1. Point of Measurement . . . . . . . . . . . . . . . . . . . 13 78 4.2. Use by Operators to Plan and Provision Networks . . . . . 14 79 4.3. Service Performance Measurement . . . . . . . . . . . . . 14 80 4.4. Use for Network Diagnostics and Troubleshooting . . . . . 14 81 4.5. Acceptable Response to Congestion . . . . . . . . . . . . 15 82 4.5.1. Measuring Compliance of UDP Traffic . . . . . . . . . 15 83 4.5.2. Measuring Transport to Support Network Operations . . 16 84 5. Observing Transport Flows with Encrypted Transport Header Fiel 16 85 5.1. Transport Information at the Network Layer . . . . . . . . 16 86 5.2. An Observable Transport Flow Identifier . . . . . . . . . 17 87 5.2.1. A Method to Determine Header Format . . . . . . . . . 17 88 5.2.2. Use of a Transport as a Substrate . . . . . . . . . . 17 89 5.2.3. Support for Mobility and Flow Migration . . . . . . . 18 90 5.2.4. Flow Start and Stop . . . . . . . . . . . . . . . . . 18 91 5.3. Observable Transport Sequence Number . . . . . . . . . . . 19 92 5.4. Observable Transport Reception . . . . . . . . . . . . . . 19 93 5.5. Observable Transport Timestamps . . . . . . . . . . . . . 20 94 5.6. Observable ECN Transport Feedback Information . . . . . . 20 95 5.7. Other Observable Transport Fields . . . . . . . . . . . . 20 96 5.8. Interpretation of Transport Header Fields . . . . . . . . 21 97 5.9. Requirements for Transport Measurement . . . . . . . . . . 21 98 6. The Effect of Encrypting Transport Header Fields . . . . . . . 22 99 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 22 100 6.2. Characterising "Unknown" Network Traffic . . . . . . . . . 23 101 6.3. Accountability and Internet Transport Portocols . . . . . 23 102 7. Implications on Evolution of the Internet Transport . . . . . 24 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 108 11.2. Informative References . . . . . . . . . . . . . . . . . 28 109 Appendix A. Revision information . . . . . . . . . . . . . . . . . 32 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 1. Introduction 114 This document discusses the implications of end-to-end encryption 115 applied at the transport layer, and examines the impact on transport 116 protocol design, transport use, and network operations and 117 management. It also considers some anticipated implications on 118 transport and application evolution. 120 The transport layer is the first end-to-end layer in the network 121 stack. Despite headers having end-to-end meaning, some transport 122 headers have come to be used in various ways within the Internet. In 123 response to pervasive monitoring [RFC7624] revelations and the IETF 124 consensus that "Pervasive Monitoring is an Attack" [RFC7258], efforts 125 are underway to increase encryption of Internet traffic, which would 126 prevent visibility of transport headers. This has implications on 127 how network protocols are designed and used [I-D.mm-wg-effect- 128 encrypt]. 130 Transport information that is sent without end-to-end integrity check 131 could be modified by "middleboxes" - defined as any intermediary box 132 performing functions apart from normal, standard functions of an IP 133 router on the data path between a source host and destination host 134 [RFC3234]. When transport headers are modified by network devices on 135 the path, this can change the end-to-end protocol transport protocol 136 behaviour in a way that may have benefits (e.g., to user performance/ 137 cost) or may hinder (e.g., disrupting application experience). 138 Whatever the outcome, modification of packets by a middlebox was not 139 usually intended when the protocol was specified and is usually not 140 known by the sending or receiving endpoints. 142 Middleboxes have been deployed for a variety of reasons [RFC3234], 143 including protocol enhancement, proxies such as Protocol Enhancing 144 Proxies (PEPs) [RFC3135], TCP acknowledgement (ACK) enhancement 145 [RFC3449], use by application protocol caches [I-D.mm-wg-effect- 146 encrypt], application layer gateways [I-D.mm-wg-effect-encrypt], etc. 147 [I-D.dolson-plus-middlebox-benefits] summarizes some of the functions 148 provided by such middleboxes, and benefits that may arise when used 149 in specific deployment scenarios. Such methods, which involve in- 150 network modification of transport headers, are not further discussed. 152 Transport protocols can be designed to encrypt or authenticate 153 transport header fields. Authentication methods at the transport 154 layer can detect any changes to an immutable header field that were 155 made by a network device along a path. These methods do not require 156 encryption of the header fields, and hence authenticated fields may 157 remain visible to network devices. A receiving transport endpoint 158 can use an integrity check to avoid accepting modified protocol 159 headers. This document therefore considers the case where transport 160 header fields are not altered as a packet traverses the network path. 162 Authentication methods (that provide integrity checks of protocols 163 fields) have also been specified at the network layer, and this also 164 protects transport header fields. The network layer itself carries 165 protocol header fields that are increasingly used to help forwarding 166 decisions reflect the need of transport protocols, such the IPv6 Flow 167 Label [RFC6437], the Differentiated Services Code Point (DSCP) 168 [RFC2474] and Explicit Congestion Notification (ECN) [RFC3168]. 170 Encryption methods can hide information from an eavesdropper in the 171 network. Encryption can also help protect the privacy of a user, by 172 hiding data relating to user/device identity or location. Neither an 173 integrity check nor encryption methods prevent traffic analysis, and 174 usage needs to reflect that profiling of users and fingerprinting of 175 behaviour can take place even on encrypted traffic flows. 177 This document seeks to identify the implications of various 178 approaches to transport protocol authentication and encryption. 180 2. Internet Transports and Pervasive Encryption 182 End-to-end encryption can be applied at various protocol layers. It 183 can be applied above the transport to encrypt the transport payload. 184 One motive to use encryption is a response to perceptions that the 185 network has become ossified by over-reliance on middleboxes that 186 prevent new protocols and mechanisms from being deployed. This has 187 lead to a common perception that there is too much "manipulation" of 188 protocol headers within the network, and that designing to deploy in 189 such networks is preventing transport evolution. In the light of 190 this, a method that authenticates transport headers may help improve 191 the pace of transport development, by eliminating the need to always 192 consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or 193 potentially to only explicitly enable middlebox use for particular 194 paths with particular middleboxes [RFC3135]. 196 Another perspective stems from increased concerns about privacy and 197 surveillance. Some Internet users have valued the ability to protect 198 identity and defend against traffic analysis, and have used methods 199 such as IPsec ESP and Tor [Tor]. Revelations about the use of 200 pervasive surveillance [RFC7624] have, to some extent, eroded trust 201 in the service offered by network operators, and following the 202 Snowden revelation in the USA in 2013 has led to an increased desire 203 for people to employ encryption to avoid unwanted "eavesdropping" on 204 their communications. Whatever the reasons, there are now activities 205 in the IETF to design new protocols that may include some form of 206 transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]). 208 The use of transport layer authentication and encryption exposes a 209 tussle between middlebox vendors, operators, applications developers 210 and users. 212 o On the one hand, future Internet protocols that enable large-scale 213 encryption assist in the restoration of the end-to-end nature of 214 the Internet by returning complex processing to the endpoints, 215 since middleboxes cannot modify what they cannot see. 216 o On the other hand, encryption of transport layer header 217 information has implications to people responsible for operating 218 networks and researchers and analysts seeking to understand the 219 dynamics of protocols and traffic patterns. 221 Whatever the motives, a decision to use pervasive of transport header 222 encryption will have implications on the way in which design and 223 evaluation is performed, and which can in turn impact the direction 224 of evolution of the TCP/IP stack. 226 The next subsections briefly review some security design options for 227 transport protocols. 229 2.1. Authenticating the Transport Protocol Header 231 Transport layer header information can be authenticated. An 232 integrity check that protects the immutable transport header fields, 233 but can still expose the transport protocol header information in the 234 clear, allowing in-network devices to observes these fields. An 235 integrity check can not prevent in-network modification, but can 236 avoid accepting changes and avoid impact on the transport protocol 237 operation. 239 An example transport authentication mechanism is TCP-Authentication 240 (TCP-AO) [RFC5925]. This TCP option authenticates TCP segments, 241 including the IP pseudo header, TCP header, and TCP data. TCP-AO 242 protects the transport layer, preventing attacks from disabling the 243 TCP connection itself. TCP-AO may interact with middleboxes, 244 depending on their behavior [RFC3234]. 246 The IPSec Authentication Header (AH) [RFC4302] works at the network 247 layer and authenticates the IP payload. This therefore also 248 authenticates all transport headers, and verifies their integrity at 249 the receiver, preventing in-network modification. 251 2.2. Encrypting the Transport Payload 253 The transport layer payload can be encrypted to protect the content 254 of transport segments. This leaves transport protocol header 255 information in the clear. The integrity of immutable transport 256 header fields could be protected by combining this with an integrity 257 check (Section 2.1). 259 Examples of encrypting the payload include Transport Layer Security 260 (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP 261 [RFC6347] [RFC7525]. 263 2.3. Encrypting the Transport Header 265 The network layer payload could be encrypted (including the entire 266 transport header and payload). This method does not expose any 267 transport information to devices in the network, which also prevents 268 modification along the network path. 270 The IPSec Encapsulating Security Payload (ESP) [RFC4303] is an 271 example of encryption at the network layer, it encrypts and 272 authenticates all transport headers, preventing visibility of the 273 headers by in-network devices. Some Virtual Private Network (VPN) 274 methods also encrypt these headers. 276 2.4. Authenticating Transport Information and Selectively Encrypting 277 the Transport Header 279 A transport protocol design can encrypt selected header fields, while 280 also choosing to authenticate fields in the transport header. This 281 allows specific transport header fields to be made observable by 282 network devices. End-to end integrity checks can prevent an endpoint 283 from undetected modification of the immutable transport headers. 285 The choice of which fields to expose and which to encrypt is a design 286 choice for the transport protocol. Any selective encryption method 287 requires trading two conflicting goals for a transport protocol 288 designer to decide which header fields to encrypt. On the one hand, 289 security work typically employs a design technique that seeks to 290 expose only what is needed. On the other hand, there may be 291 performance and operational benefits in exposing selected information 292 to network tools. 294 Mutable fields in the transport header provide opportunities for 295 middleboxes to modify the transport behaviour (e.g., the extended 296 headers described in [I-D.trammell-plus-abstract-mech]). This 297 considers only immutable fields in the transport headers, that is, 298 fields that may be authenticated end-to-end across a path. 300 An example of a method that encrypts some, but not all, transport 301 information is UDP-in-GRE [RFC8086] when used with GRE encryption. 303 2.5. Adding Transport Information to Network-Layer Protocol Headers 305 The transport information can be made visible in a network-layer 306 header. This has the advantage that this information can then be 307 observed by in-network devices. This has the advantage that a single 308 header can support all transport protocols, but there may also be 309 less desirable implications of separating the operation of the 310 transport protocol from the measurement framework. 312 Some measurements may be made by adding additional protocol headers 313 carrying operations, administration and management (OAM) information 314 to packets at the ingress to a maintenance domain (e.g., an Ethernet 315 protocol header with timestamps and sequence number information using 316 a method such as 802.11ag) and removing the additional header at the 317 egress of the maintenance domain. This approach enables some types 318 of measurements, but does not cover the entire range of measurements 319 described in this document. 321 Another example of a network-layer approach is the IPv6 Performance 322 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 323 pdm-option]. This allows a sender to optionally include a 324 destination option that caries header fields that can be used to 325 observe timestamps and packet sequence numbers. This information 326 could be authenticated by receiving transport endpoints when the 327 information is added at the sender and visible at the receiving 328 endpoint, although methods to do this have not currently been 329 proposed. This method needs to be explicitly enabled at the sender. 331 A drawback of using extension headers is that IPv4 network options 332 are often not supported (or are carried on a slower processing path) 333 and some IPv6 networks are also known to drop packets that set an 334 IPv6 header extension. Another disadvantage is that protocols that 335 separately expose header information do not necessarily have an 336 advantage to expose the information that is utilised by the protocol 337 itself, and could manipulate this header information to gain an 338 advantage from the network. 340 3. Use of Transport Headers in the Network 342 This section identifies ways that actors can benefit by observing 343 (non-encrypted) transport header fields at devices in the network. 344 The list of actors who perform measurements include: 346 o Protocol developers and implementors of TCP/IP stacks; 347 o Researchers working on new mechanisms; 348 o Use of new applications using existing applications; 349 o Analysis researching the impact of mechanisms on network equipment 350 or specific network topologies; 351 o Staff supporting operation of a network. 353 One approach is to use active measurement using dedicated tools to 354 generate and measure test traffic. To test a transport path, such 355 active tools need to be run from an endpoint, and most operators do 356 not have access to user equipment. There may also be costs 357 associated with running such tests (e.g., the implications of 358 bandwidth tests in a mobile network are obvious). Some active 359 measurements (e.g., response under load or particular workloads) may 360 perturb other traffic, and could require dedicated access to the 361 network segment. An alternative approach is to use in-network 362 techniques that observe transport packet headers in operational 363 networks to make the measurements. 365 Transport layer information can help identify whether the link/ 366 network tuning is effective and alert to potential problems that can 367 be hard to derive from link or device measurements alone. The design 368 trade offs for radio networks are often very different to those of 369 wired networks. A radio-based network (e.g., cellular mobile, 370 enterprise WiFi, satellite access/backhaul, point-to-point radio) has 371 the complexity of a subsystem that performs radio resource management 372 - with direct impact on the available capacity, and potentially loss/ 373 reordering of packets. The impact of the pattern of loss and 374 congestion, differs for different traffic types, correlation with 375 propagation and interference can all have significant impact on the 376 cost and performance of a provided service. The need for this type 377 of information is expected to increase as operators bring together 378 heterogeneous types of network equipment and seek to deploy 379 opportunistic methods to access radio spectrum. 381 In-network observation of transport protocol headers requires 382 knowledge of the format of the transport header: 384 o Flows, need to be identified at the level required for monitoring; 385 o The protocol and version of the header that is being used. As 386 protocols evolve over time and there may be a need to introduce 387 new transport headers. This may require interpretation of 388 protocol version information or connection setup information; 389 o The position and syntax of any transport headers that need to be 390 observed. IETF transport protocols specify this information. 392 The following subsections describe various ways that observable 393 transport information may be utilised. 395 3.1. Use to Identify Flows and Packet Formats 397 Transport protocol header information can identify a flow and the 398 connection state of the flow, together with the protocol options 399 being used. In some usages, a low-numbered (well-known ) port that 400 can identify a protocol (although port information alone is not 401 sufficient to guarantee identification of a protocol). Transport 402 protocols, such as TCP and SCTP specify a standard base header that 403 includes sequence number information and other data, with the 404 possibility to negotiate additional headers at connection setup and 405 identified by an option number in the transport header. UDP-based 406 protocols sometimes do not use well-known ports but also can instead 407 be identified by signalling protocols or through the use of magic 408 numbers placed in the first byte(s) of the datagram payload. 410 3.2. Measurements derived from Transport Header Information 412 Some actors have a need to characterise the performance of link/ 413 network segments. Passive monitoring uses observed traffic to makes 414 inferences from transport headers to derive measurements. A variety 415 of open source and commercial tools can utilise this information. 416 Transport fields in the Real Time Protocol (RTP) header[RFC3550] 417 [RFC4585] can be observed to derive traffic volume measurements and 418 provide information on the progress and quality of a session using 419 RTP. Key performance indicators are retransmission rate, packet drop 420 rate, sector utilization level, a measure of reordering, peak rate, 421 the CE-marking rate, etc. Metadata is often important to understand 422 the context under which the data was collected, including the time, 423 observation point, and way in which metrics were accumulated. 425 Some Internet transports report summary performance data that is 426 observable in the network (e.g., RTCP feedback[RFC3550]). A user of 427 summary measurement data needs to trust the source of this data and 428 the method used to generate the summary information. 430 When encryption conceals information in packet headers, measurements 431 need to rely on pattern inferences and other heuristics grows, and 432 accuracy suffers [I-D.mm-wg-effect-encrypt]. 434 3.2.1. Use to Characterise Traffic Rate and Volume 436 Transport headers may be observed to derive volume measures per- 437 application, to characterise the traffic using a network segment and 438 pattern of network usage. This may be measured per endpoint or 439 aggregate of endpoint (e.g., by an operator to assess subscriber 440 usage). This can also be used to trigger measurement-based traffic 441 shaping and to implement QoS support within the network and lower 442 layers. Volume measures can be valuable for capacity planning 443 (providing detail of trends rather than the volume per subscriber). 445 3.2.2. Measuring Loss Rate and Loss Pattern 447 Flow loss rate is often used as a metric for performance assessment 448 and to characterise the transport behaviour. Understanding the root 449 cause of loss can help an operator determine whether this requires 450 corrective action. 452 There are various cause of loss, including: corruption on a link 453 (e.g., interference on a radio link), buffer overflow (e.g., due to 454 congestion), policing (traffic management), buffer management (e.g., 455 Active Queue Management (AQM). Loss can be monitored at the interface 456 level by devices in the network. It is often important to understand 457 the conditions under which packet loss occurs, which usually means 458 relating loss to the traffic flowing on the network segment at the 459 time of loss. Understanding flow loss rate requires either 460 maintaining per flow packet counters or by observing sequence numbers 461 in transport headers. 463 Observation of transport feedback information (observing loss 464 reports, e.g., RTCP, TCP SACK) can increase understanding of the 465 impact of loss and help identify cases where loss may have been 466 wrongly identified, or the transport did not require the lost packet. 467 It is sometimes more important to understand the pattern of loss, 468 than the loss rate - since losses can often occur as bursts, rather 469 than randomly timed events. 471 3.2.3. Measuring Throughput and Goodput 473 The throughput observed by a flow can be determined even when a flow 474 is encrypted, providing the individual flow can be identified. 475 Goodput [RFC7928] is a measure of useful data exchanged (the ratio of 476 useful/total volume of traffic sent by a flow), which requires 477 ability to differentiate loss and retransmission of packets (e.g., by 478 observing packet sequence numbers in TCP or RTP). 480 3.2.4. Measuring Latency (Network Transit Delay and Jitter) 482 Latency is a key performance metric that impacts application response 483 time and user-perceived response time. It also often indirectly 484 impacts throughput and flow completion time. Latency determines the 485 reaction time of the transport protocol itself, impacting flow setup, 486 congestion control, loss recovery, and other transport mechanisms. 487 The observed latency can have many components [Latency]. Of these, 488 unnecessary/unwanted queuing in network buffers has often been 489 observed as a significant factor. Once the cause of unwanted latency 490 has been identified, this can often be eliminated, and determining 491 latency metrics is a key driver in the deployment of AQM [RFC7567], 492 DiffServ [RFC2474], and ECN [RFC3168] [RFC8087]. 494 To measure latency across a part of the path, an observation point 495 can measure the experienced round trip time (RTT) using packet 496 sequence numbers, and acknowledgements, or by observing header 497 timestamp information. Such information allows an observation point 498 in the network to determine not only the path RTT, but also to 499 measure the upstream and downstream contribution to the RTT. This may 500 be used to locate a source of latency, e.g., by observing cases where 501 the ratio of median to minimum RTT is large for a part of a path. 503 An example usage of this method could be to identify excessive 504 buffers and to deploy or configure Active Queue Management (AQM) 505 [RFC7567] [RFC7928]. Operators deploying such tools can effectively 506 eliminate unnecessary queuing in routers and other devices. AQM 507 methods need to be deployed at the capacity bottleneck, but are often 508 deployed in combination with other techniques, such as scheduling 509 [RFC7567] [I-D.ietf-aqm-fq-codel] and although parameter-less methods 510 are desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D 511 .ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all 512 possible deployment scenarios. The service offered by operators can 513 therefore benefit from latency information to understand the impact 514 of deployment and tune deployed services. 516 Some network applications are sensitive to packet jitter, and it can 517 be necessary to measure the jitter observed along a portion of the 518 path. The requirements to measure jitter resemble those for the 519 measurement of latency. 521 3.2.5. Measuring Flow Reordering 523 Significant flow reordering can impact time-critical applications and 524 can be interpreted as loss by reliable transports. Many transport 525 protocol techniques are impacted by reordering (e.g., triggering TCP 526 retransmission, or rebuffering of real-time applications). Packet 527 reordering can occur for many reasons (from equipment design to 528 misconfiguration of forwarding rules). 530 As in the drive to reduce network latency, there is a need for 531 operational tools to be able to detect misordered packet flows and 532 quantify the degree or reordering. Techniques for measuring 533 reordering typically observe packet sequence numbers. Metrics have 534 been defined that evaluate whether a network has maintained packet 535 order on a packet-by-packet basis [RFC4737] and [RFC5236]. 537 There has been initiatives in the IETF transport area to reduce the 538 impact of reordering withing a transport flow, possibly leading to 539 reduced the requirements for ordering. These have promise to 540 simplify network equipment design as well as the potential to improve 541 robustness of the transport service. Measurements of reordering can 542 help understand the level of reordering within deployed 543 infrastructure, and inform decisions about how to progress such 544 mechanisms. 546 3.3. Measurements derived from Network-Transport Information 547 This section describes transport information that is already 548 observable in network-layer header fields. 550 3.3.1. Use of IPv6 Network-Layer Flow Label 552 Endpoints should expose flow information in the IPv6 Flow Label field 553 of the network-layer header (e..g. [RFC8085]). This can be used to 554 inform network-layer queuing, forwarding (e.g., for equal cost multi- 555 path (ECMP) routing, and Link Aggregation (LAG)). This can provide 556 useful information to assign packets to flows in the data collected 557 by measurement campaigns. Although important to characterising a 558 path, it does not directly provide any performance data. 560 3.3.2. Use Network-Layer Differentiated Services Code Point Point 562 Application can expose their delivery expectations to the network, by 563 setting the Differentiated Services Code Point (DSCP) field of IPv4 564 and IPv6 packets. This can be used to inform network-layer queuing 565 and forwarding, and can also provide information on the relative 566 importance of packet information collected by measurement campaigns, 567 but does not directly provide any performance data. 569 This field provides explicit information that can be used in place of 570 inferring traffic requirements (e.g., by inferring QoS requirements 571 from port information via a multi-field classifier). The DSCP value 572 can therefore impact the quality of experience for a flow. 573 Observations of service performance need to consider this field when 574 a network path has support for differentiated service treatment. 576 3.3.3. Use of Explicit Congestion Marking 578 Explicit Congestion Notification (ECN)[RFC3168] uses a codepoint in 579 the network-layer header. Use of ECN can offer gains in terms of 580 increased throughput, reduced delay, and other benefits when used 581 over a path that includes equipment that supports an AQM method that 582 performs Congestion Experienced (CE) marking of IP packets [RFC8087]. 584 This exposes the presence of congestion on a network path to the 585 transport and network layer. The reception of Congestion Experienced 586 (CE) marked packets can therefore be used to monitor the presence and 587 estimate the level of incipient congestion on the upstream portion of 588 the path from the point of observation (Section 2.5 of [RFC8087]). 589 Because ECN marks carried in the IP protocol header, measuring ECN 590 can be much easier than metering packet loss. However, interpreting 591 the marking behaviour (i.e., assessing congestion and diagnosing 592 faults) requires context from the transport layer (path RTT, 593 visibility of loss - that could be due to queue overflow, congestion 594 response, etc)[RFC7567]. 596 Some ECN-capable network devices can provide richer (more frequent 597 and fine-grained) indication of their congestion state. Setting 598 congestion marks proportional to the level of congestion (e.g., DCTP 599 [I-D.ietf-tcpm-dctcp], and L4S [I-D.ietf-tsvwg-l4s-arch]). 601 AQM and ECN offer a range of algorithms and configuration options, it 602 is therefore important for tools to be available to network operators 603 and researchers to understand the implication of configuration 604 choices and transport behaviour as use of ECN increases and new 605 methods emerge [RFC7567] [RFC8087]. ECN-monitoring is expected to 606 become important as AQM is deployed that supports ECN [RFC8087] 608 Section 5.6 describes the transport layer feedback information that 609 accompanies the use of ECN. 611 4. Transport Measurement 613 The common language between network operators and application/content 614 providers/users is packet transfer performance at a layer that all 615 can view and analyze. For most packets, this has been transport 616 layer, until the emergence of QUIC, with the obvious exception of 617 VPNs and IPsec. When encryption conceals more layers in a packet, 618 people seeking understanding of the network operation need to rely 619 more on pattern inferences and other heuristics. The accuracy of 620 measurements therefore suffers, as does the ability to investigate 621 and troubleshoot interactions between different anomalies. For 622 example, the traffic patterns between server and browser are 623 dependent on browser supplier and version, even when the sessions use 624 the same server application (e.g., web e-mail access). Even when 625 measurement datasets are made available (e.g., from endpoints) 626 additional metadata, such as the state of the network, is often 627 required to interpret the data. Collecting and coordinating such 628 metadata is more difficult when the observation point is at a 629 different location to the bottleneck/device under evaluation. 631 Packet sampling techniques can be used to scale processing involved 632 in observing packets on high rate links. This only exports the 633 packet header information of (randomly) selected packets. The 634 utility of these measurements depends on the type of bearer and 635 number of mechanisms used by network devices. Simple routers are 636 relatively easy to manage, a device with more complexity demands 637 understanding of the choice of many system parameters. This level of 638 complexity exists when several network methods are combined. 640 This section discusses topics concerning transport measurement. 642 4.1. Point of Measurement 643 Often measurements can only be understood in the context of the other 644 flows that share a bottleneck. A simple example is the monitoring of 645 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 646 queues (statistically assigned per flow), management of the queue 647 length (CODEL), flow-scheduling, and a starvation prevention 648 mechanism. Usually such algorithms are designed to be self-tuning, 649 but current methods typically employ heuristics that can result in 650 more loss under certain path conditions (e.g., large RTT, effects of 651 multiple bottlenecks [RFC7567]). 653 In-network measurements that can distinguish between upstream and 654 downstream metrics with respect to the measurement point. They are 655 particularly useful for locating the source of problems or to assess 656 the performance of a network segment or a particular device 657 configuration. 659 4.2. Use by Operators to Plan and Provision Networks 661 Traffic measurements (e.g. Traffic volume, loss, latency) is used by 662 operators to help plan deployment of new equipment and configurations 663 in their networks. Data is also important to equipment vendors who 664 need to understand traffic trends traffic and patterns of usage as 665 inputs to decisions about planning products and provisioning for new 666 deployments. This measurement information can also be correlated 667 with billing information when this is also collected by an operator. 669 A network operator supporting traffic that uses transport header 670 encryption may not have access to per-flow measurement data. Trends 671 in aggregate traffic can be observed and can be related this to the 672 endpoint addresses being used, but it may not be possible to 673 correlate patterns in measurements with changes in transport 674 protocols (e.g., the impact of changes in introducing a new transport 675 protocol mechanism). This increases the dependency on other indirect 676 sources of information to inform planning and provisioning. 678 4.3. Service Performance Measurement 680 Traffic measurements (e.g., traffic volume, loss, latency) can be 681 used by various actors to help understand the performance available 682 to users of a network segment. While active measurements may be used 683 in-network passive measurements can have advantages in terms of 684 eliminating unproductive traffic, reducing the influence of test 685 traffic on the overall traffic mix, and the ability to choose the 686 point of measurement Section 4.1. 688 4.4. Use for Network Diagnostics and Troubleshooting 690 Transport header information is useful for a variety of operational 691 tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, 692 assess performance, capacity planning, management of denial of 693 service threats, and responding to user performance questions. These 694 tasks seldom involve the need to determine the contents of the 695 transport payload, or other application details. 697 A network operator supporting traffic that uses transport header 698 encryption can see only encrypted transport headers. This prevents 699 deployment of performance measurement tools that rely on transport 700 protocol information. Choosing to encrypt all information may be 701 expected to reduce the ability for networks to "help" (e.g., in 702 response to tracing issues, making appropriate Quality of Service, 703 QoS, decisions). For some this will be blessing, for others it may be 704 a curse. For example, operational performance data about encrypted 705 flows needs to be determined by traffic pattern analysis, rather than 706 relying on traditional tools. This can impact the ability of the 707 operator to respond to faults, it could require reliance on endpoint 708 diagnostic tools or user involvement in diagnosing and 709 troubleshooting unusual use cases or non-trivial problems. Although 710 many network operators utilise transport information as a part of 711 their operational practice, the network will not break because 712 transport headers are encrypted. 714 4.5. Acceptable Response to Congestion 716 Congestion control is a key transport function. Many network 717 operators implicitly accept that TCP traffic to comply with a 718 behaviour that is acceptable for use in the shared Internet. TCP 719 algorithms have been continuously improved over decades, and they 720 have reached a level of efficiency and correctness that custom 721 application-layer mechanisms will struggle to easily duplicate 722 [RFC8085]. A standards-compliant TCP stack provides congestion 723 control that is therefore judged safe for use across the Internet. 724 Applications developed on top of well-designed transports can be 725 expected to appropriately control their network usage, reacting when 726 the network experiences congestion, by back-off and reduce the load 727 placed on the network. This is the normal expected behaviour for TCP 728 and other IETF-defined transports. 730 Tools exist that can interpret the transport protocol header 731 information to help understand the impact of specific transport 732 protocols (or protocol mechanisms) on other traffic that shares their 733 network. An observation in the network can gain understanding of the 734 dynamics of a flow and its congestion control behaviour. Analysing 735 observed packet sequence numbers can be used to help build confidence 736 that an application flow backs-off its share of the network load in 737 the face of persistent congestion, and hence to understand whether 738 the behaviour is appropriate for sharing limited network capacity. 739 For example, it is common to visualise plots of TCP sequence numbers 740 versus time for a flow to understand how a flow shares available 741 capacity, deduce its dynamics in response to congestion, etc. 743 4.5.1. Measuring Compliance of UDP Traffic 744 UDP provides a minimal message-passing transport that has no inherent 745 congestion control mechanisms. Because congestion control is 746 critical to the stable operation of the Internet, applications and 747 other protocols that choose to use UDP as an Internet transport must 748 employ mechanisms to prevent congestion collapse, avoid unacceptable 749 contributions to jitter/latency, and to establish an acceptable share 750 of capacity with concurrent traffic [RFC8085]. 752 A network operator has no way of knowing the specific methods used by 753 a UDP application, unless the header format can be determined. Tools 754 are needed to understand if UDP flows comply with congestion control 755 expectations and therefore whether there is a need to deploy methods 756 such as rate-limiters, transport circuit breakers or other methods to 757 enforce acceptable usage. UDP flows that expose a well-known header 758 by specifying the format of header fields can allow information to be 759 observed that gains understanding of the dynamics of a flow and its 760 congestion control behaviour. For example, tools exist to monitor 761 various aspects of the RTP and RTCP header information of real-time 762 flows (see Section 3.2). 764 4.5.2. Measuring Transport to Support Network Operations 766 By correlating observations at multiple points along the path (e.g., 767 at the ingress and egress of a network segment), an observer can 768 determine the contribution of a portion of the path to an observed 769 metric (to locate a source of delay, jitter, loss, reordering, 770 congestion marking, etc). 772 Information provided by tools can help determine whether mechanisms 773 are needed in the network to prevent flows from acquiring excessive 774 network capacity. Operators can manage traffic flows (e.g., to 775 prevent flows from acquiring excessive network capacity under severe 776 congestion) by deploying rate-limiters, traffic shaping or network 777 transport circuit breakers [RFC8084]. 779 5. Observing Transport Flows with Encrypted Transport Header Fields 781 This section examines implications of encrypting specific transport 782 header information. 784 5.1. Transport Information at the Network Layer 785 Some transport information is made visible in the network-layer 786 protocol header. These header fields are not encrypted and can be 787 used to make flow observations. Endpoints should expose flow 788 information in the IPv6 Flow Label Section 3.3.1 in the network-layer 789 header. This can be used to inform network-layer queuing, forwarding 790 (e.g., for equal cost multi-path (ECMP) routing, and Link Aggregation 791 (LAG)). For transport measurement, this can provide useful 792 information to assign packets to flows in the data collected by 793 measurement campaigns, but does not directly provide any performance 794 data. Similarly the Differentiated Services CodePoint (DCSP) 795 indicates expected forwarding treatment Section 3.3.2. The ECN field 796 provides observable congestion data and can help inform measurement 797 of flow congestion Section 3.3.3. 799 5.2. An Observable Transport Flow Identifier 801 To measure and analyse a transport protocol, a measurement tool needs 802 to be able to identify traffic flows. Aggregation of sessions, and 803 persistent use of established transport flows by multiple sessions 804 means that a flow at the transport layer is not necessarily the same 805 as a flow seen at the application layer. This is usually not a 806 consequence. Data is measured for the aggregate transport flow. 808 Some measurement methods sample traffic, rather than collecting all 809 packets passing through a measurement point. These methods still 810 require a way to determine the presence, size and position of any 811 observable header fields - but may need to do this without observing 812 a protocol exchange for a connection setup. 814 5.2.1. A Method to Determine Header Format 816 If flow information is observed from transport headers, then there 817 needs to be a way to identify the format of the header Section 3.1. 818 Some IETF transport protocols are identified by an IP protocol number 819 (e.g. ,TCP, SCTP, UDP). All IETF-defined transport protocols include 820 a transport port field in their transport header. Higher layer 821 protocols (e.g., HTTP) can be sometimes be observed by a well-known 822 port value, which can be indicative of the protocol being 823 encapsulated, but there is no way to enforce this usage. This can be 824 used to configure decapsulation, alternatives include a "magic" 825 number placed at the start of each UDP datagram. 827 Once the protocol has been determined, the transport header can be 828 determined from a published specification. If multiple formats are 829 permitted, this may also require observing the protocol version being 830 used and possibly parameter negotiation at connection setup. 832 5.2.2. Use of a Transport as a Substrate 833 When a transport is used as a substrate, the transport provides an 834 encapsulation that allows another transport flow to be within the 835 payload of a transport flow. The transported protocol header may 836 provide additional information for multiplexing multiple flows over 837 the same 5-tuple. The UDP Guidelines [RFC8085] provides some 838 guidance on using UDP as a substrate protocol. If there is no 839 additional information about the protocol transported by the 840 substrate, this may be viewed as an opaque traffic aggregate, and 841 prevents transport measurement in the network. Examples include GRE- 842 in-UDP [RFC8086], SCTP-in-UDP. The GRE-in-UDP encapsulation may 843 encrypt the payload, but does not encrypt the GRE protocol header. 845 5.2.3. Support for Mobility and Flow Migration 847 With the proliferation of mobile connected devices, there is a stated 848 need for connection-oriented protocols to maintain connections after 849 a network migration by an endpoint. The ability and desirability of 850 in-network devices to track such migration depends on the context. 851 On the one hand, a load-balancer device in front of server may find 852 it useful to map a migrated connection to the same server endpoint. 853 On the other hand, a user performing migration to avoid detection may 854 prefer the network not to be able to correlate the different parts of 855 a migrating session. Care must then be exercised to make sure that 856 the information encoded by the endpoints is not sufficient to 857 identify unique flows and facilitate a persistent surveillance attack 858 vector [I-D.mm-wg-effect-encrypt]. 860 The impact of flow migration on measurement activities depends on the 861 data being measured, rate of migration and level of encryption that 862 is employed. Requirements for load balancing and mobility can lead 863 to complex protocol interactions. 865 5.2.4. Flow Start and Stop 867 Transports can expose that start and end of flows in a transport 868 header field (e.g., TCP SYN, FIN, RST). This can also help 869 measurement devices identify the start of flows, or to remove stale 870 flow information. This information is supplemental - flows can start 871 and end at any time, the Internet network layer provides only a best 872 effort service that allows alternate routing, reordering, loss, etc, 873 so a network measurement tool can not rely upon observing these 874 indicators. The time to complete a protocol connection and/or 875 session setup can be reported. 877 Flow information can provide in-network devices to manage their 878 forwarding state [I-D.trammell-plus-statefulness]. It can assist a 879 firewall in deciding which flows are permitted through a security 880 gateway, or to help maintain the network address translation (NAT) 881 bindings in a NAPT or application layer gateway. This information 882 may also find use in load balancers, where visibility of the 5-tuple 883 could assist in selecting a server [I-D.mm-wg-effect-encrypt]. 885 Access to flow information and an observable start/stop indication 886 [I-D.trammell-plus-statefulness] can avoid stateful middleboxes 887 relying on timeouts to remove old state. Without this, middleboxes 888 are unaware when a particular flow ceases to be used by an 889 application[RFC8085]. This can lead to the state table entries 890 keeping state for less time for flows that are not identifiable. 892 5.3. Observable Transport Sequence Number 894 The TCP or RTP sequence number can be observed in one direction (the 895 direction that carries data segments). An authenticated header 896 prevents this field being modified or terminated/split [RFC3135] by a 897 network device, but allows this still to be used to observe progress 898 of the network flow. 900 An incrementing sequence number enables detection of loss (either by 901 correlating ingress and egress value, or when assuming that all 902 packets follow a single path), duplication and reordering (with 903 understanding that not necessarily all packets of a flow follow the 904 same path, and reordering can complicate processing of observations). 905 Tools are widely available to interpret RTP and TCP sequence numbers, 906 ranging from open source tools to dedicated commercial packages. As 907 for TCP, use by in-network measurement devices needs to account for 908 the impact of load-balancing of flows, changes in forwarding 909 behaviour, measurement loss (rather than observed packet loss), etc. 911 5.4. Observable Transport Reception 913 Acknowledgement (ACK) data provides information about the path from 914 the network device to the remote endpoint. The information can help 915 identify packet loss (or the point of loss), RTT, and other network- 916 related performance parameters (e.g., throughput, jitter, 917 reordering). Unless this information is correlated with other data 918 there is no way to disambiguate the cause of impairments (congestion 919 loss, link transmission loss, equipment failure). 921 An in-network device must not modify the flow of end-to-end ACK data 922 when using an authenticated protocol. That is, must not use the in- 923 network methods described in [RFC3449]. This can impact the 924 performance and/or efficiency (e.g., cost) of using paths where the 925 return capacity is limited or has implications on the overall design 926 (e.g., using TCP with cellular mobile uplinks, DOCSIS uplinks). 928 The TCP stream can be observed by correlating the stream of TCP ACKs 929 that flow from a receiver in the return direction. Although these 930 ACKs are cumulative, and are not necessarily sent on the same path as 931 the forward data, when visible, their sequence can confirm successful 932 transmission and the path RTT. In the case of TCP they may also 933 indicate packet loss (duplicate ACKs). 935 An RTP session can provide reception information [RFC3550] [RFC4585] 936 feedback using the RTCP framework. This reception information and 937 can be observed by in-network measurement devices and can be 938 interpreted to provide a variety of quality of experience information 939 for the related RTP flow, as well as basic network performance data 940 (RTT, loss, jitter, etc). 942 5.5. Observable Transport Timestamps 944 The use of timestamps for latency and jitter measurements Section 945 3.2.4 is discussed in other sections of the current version of the 946 document. 948 5.6. Observable ECN Transport Feedback Information 950 Transport protocols that use ECN Section 3.3.3 need to provide ECN 951 feedback information in the transport header to inform the sender 952 whether packets have been received with an ECN CE-mark [RFC3819]. 953 This information can be in the form of feedback once each RTT 954 [RFC3819] or more frequent. The latter may involve sending a 955 detailed list of all ECN-marked packets (e.g., [I-D.ietf-tcpm- 956 accurate-ecn] and [RFC6679]). The detailed information can provide 957 detail about the pattern and rate of marking. The information 958 provided in these protocol headers can help a network operator to 959 understand the congestion status of the forward path and the impact 960 of marking algorithms on the traffic that is carried [RFC8087]. 962 IETF specifications for Congestion Exposure (CONVEX) [RFC7713] is an 963 example of a framework that monitors reception reports for CE-marked 964 packets to support network operations. 966 5.7. Other Observable Transport Fields 967 This section is not complete - later revision may determine other 968 fields or remove this section. 970 5.8. Interpretation of Transport Header Fields 972 Understanding and analysing transport protocol behaviour typically 973 demands tracking changes to the protocol state at the transport 974 endpoints. Although protocols communicate state information in their 975 protocol headers, a protocol implementation typically also contains 976 internal state that is not directly visible from observing transport 977 protocol headers. Effective measurement tools need to consider that 978 not all packets may be observed (due to drops at the capture tap or 979 because packets take an alternate route that does not pass the tap). 980 Some flows of packets may also be encapsulated within a maintenance 981 domain in other protocols, which further complicates analysis. 983 Some examples of using network measurements of transport headers to 984 infer internal TCP transport state information include: 986 o The TCP congestion window (cwnd) and slow start threshold 987 (ssthresh). Tools for analysing in-network performance of TCP may 988 observe sequence number to infer the current congestion controller 989 state. 990 o The TCP RTT estimator and TCP Retransmission Time Out (RTO) value. 991 This can be estimated by correlating sequence and acknowledgement 992 numbers, or possibly by observing TCP timestamp options. 993 o Use of pacing (and pacing rate) and use of methods such as 994 Proportional Rate Reduction (PRR) and Congestion Window validation 995 (CWV). This may be estimated from observing timing of segments 996 with TCP sequence numbers. This is important to some congestion 997 control mechanisms and can be important for applications that are 998 rate limited or send traffic bursts. 999 o Receiver window and flow control state. This may be inferred from 1000 information in TCP ACK segments. It is important to applications 1001 where the remote endpoint is resource constrained, or the path 1002 exhibits a large RTT. 1003 o Retransmission state and receiver buffer. This may be inferred 1004 from information in TCP ACK segments (especially when SACK blocks 1005 are provided), this can be important to the performance of 1006 applications that send traffic bursts. 1007 o Use of ACK delay and Nagle algorithm. This may be estimated from 1008 observing timing of segments with TCP sequence numbers, and is 1009 important to the performance of thin application flows. 1011 5.9. Requirements for Transport Measurement 1012 Transport measurement introduces the following requirements to 1013 identify the observable information: 1015 o Observable protocol type and version information is needed to 1016 identify the protocol being used when characterising the traffic, 1017 and to enable further observation of the flow. 1018 o Observable format information is needed to allow an observer to 1019 determine the presence of any observable header fields. 1020 o A published specification is needed to allow an observer to 1021 determine the size and position of any observable header fields so 1022 that these fields may be decoded by a measurement tool. 1023 o Observable flow start/stop information can assist some forms of 1024 measurement and has utility for middleboxes that track state. 1026 The need for in-network transport measurement introduces the 1027 following requirements for observable information in transport header 1028 fields: 1030 o Observable transport information to determine the progress of 1031 flows for each direction of communication. This requires 1032 observable packet numbers. 1033 o Observable transport information to determine loss, and understand 1034 the response to congestion for a network segment. This requires 1035 observable reception information (e.g., packet acknowledgment 1036 information). 1037 o Observable transport information is needed for more advanced 1038 measurement of latency, jitter, etc. This requires an observable 1039 field and a method to correlating return information with the 1040 observed field. This could utilise a packet number and/or 1041 transmission timestamp information. This information needs to be 1042 available in both directions of transmission. 1043 o Exposure of Transport ECN feedback provides a powerful tool to 1044 understand ECN-enabled AQM-based networks. (Forward ECN 1045 information is already observable in the network header). 1047 6. The Effect of Encrypting Transport Header Fields 1049 This section explores key implications of working with encrypted 1050 transport protocols. 1052 6.1. Independent Measurement 1054 Independent observation by multiple actors is important for 1055 scientific analysis. Encrypting transport header encryption changes 1056 the ability for other actors to collect and independently analyse 1057 data. Internet transport protocols employ a set of mechanisms. Some 1058 of these need to work in cooperation with the network layer - loss 1059 detection and recovery, congestion detection and congestion control, 1060 some of these need to work only end-to-end (e.g., parameter 1061 negotiation, flow-control). 1063 When encryption conceals information in the transport header, it 1064 could be possible for an applications to provide summary data on 1065 performance and usage of the network. This data could be made 1066 available to other actors. However, this data needs to contain 1067 sufficient detail to understand (and possibly reconstruct the network 1068 traffic pattern for further testing) and to be correlated with the 1069 configuration of the network paths being measured. Sharing 1070 information between actors needs also to consider the privacy of the 1071 user and the incentives for providing accurate and detailed 1072 information. Protocols that expose the state information used by the 1073 transport protocol in their header information (e.g., timestamps used 1074 to calculate RTT, packet numbers used to asses congestion and 1075 requests for retransmission) provide an incentive for the sending 1076 endpoint to provide correct information, increasing confidence that 1077 the observer understands the transport interaction with the network. 1078 This becomes important when considering changes to transport 1079 protocols, changes in network infrastructure, or the emergence of new 1080 traffic patterns. 1082 6.2. Characterising "Unknown" Network Traffic 1084 If "unknown" or "uncharacterised" traffic patterns form a small part 1085 of the traffic aggregate passing through a network device or segment 1086 of the network the path, the dynamics of the uncharacterised traffic 1087 may not have a significant collateral impact on the performance of 1088 other traffic that shares this network segment. Once the proportion 1089 of this traffic increases, the need to monitor the traffic and 1090 determine if appropriate safety measures need to be put in place. 1092 Tracking the impact of new mechanisms and protocols requires traffic 1093 volume to be measured and new transport behaviours to be identified. 1094 This is especially true of protocols operating over a UDP substrate. 1095 The level and style of encryption needs to be considered in 1096 determining how this activity is performed. On a shorter timescale, 1097 information may also need to be collected to manage denial of service 1098 attacks against the infrastructure. 1100 6.3. Accountability and Internet Transport Portocols 1102 Attention therefore needs to be paid to the expected scale of 1103 deployment of new protocols and protocol mechanisms. Whatever the 1104 mechanism, experience has shown that it is often difficult to 1105 correctly implement combination of mechanisms [RFC8085]. These 1106 mechanisms therefore typically evolve as a protocol matures, or in 1107 response to changes in network conditions, changes in network traffic 1108 or changes to application usage. 1110 The growth and diversity of applications and protocols using the 1111 Internet continues to expand - and there has been recent interest in 1112 a wide range of new transport methods, e.g., Larger Initial Window, 1113 Proportional Rate Reduction (PRR), congestion control methods based 1114 on measuring bottleneck bandwidth and round-trip propagation time, 1115 the introduction of AQM techniques and new forms of ECN response 1116 (e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods 1117 proposed for Low Latency Low Loss Scalable throughput, L4S). For 1118 each new method it is desirable to build a body of data reflecting 1119 its behaviour under a wide range of deployment scenarios, traffic 1120 load, and interactions with other deployed/candidate methods. 1122 Measurement therefore has a critical role in the design of transport 1123 protocol mechanisms and their acceptance by the wider community 1124 (e.g., as a method to judge the safety for Internet deployment. Open 1125 standards suggest that such evaluation needs to include independent 1126 observation and evaluation of performance data. 1128 7. Implications on Evolution of the Internet Transport 1130 The transport layer provides the first end-to-end interactions across 1131 the Internet. Transport protocols are layered directly over the 1132 network service and are sent in the payload of network-layer packets. 1133 However, this simple architectural view hides one of the core 1134 functions of the transport - to discover and adapt to the properties 1135 of the Internet path that is currently being used. The design of 1136 Internet transport protocols is as much about trying to avoid the 1137 unwanted side effects of congestion on a flow and other capacity- 1138 sharing flows, avoiding congestion collapse, adapting to changes in 1139 the path characteristics, etc., as it is about end-to-end feature 1140 negotiation, flow control and optimising for performance of a 1141 specific application. 1143 To achieve stable Internet operations the IETF transport community, 1144 has to date, relied heavily on measurement and insight provided from 1145 the wider community to understand the trade-offs and to inform 1146 selection of select appropriate mechanisms to ensure a safe, reliable 1147 and robust Internet since the 1990's. 1149 There are many motivations for deploying encrypted transports, and 1150 encryption of transport payloads. The increasing public concerns 1151 about the interference with Internet traffic have led to a rapidly 1152 expanding deployment of encryption to protect end-user privacy, in 1153 protocols like QUIC. At the same time, network operators and access 1154 providers, especially in mobile networks, have come to rely on the 1155 in-network functionality provided by middleboxes both to enhance 1156 performance and support network operations. 1158 This document has expanded upon the expected implications on 1159 operational practices when working with encrypted transport 1160 protocols, and offers insight into the potential benefit of 1161 authentication, encryption and techniques that require in-network 1162 devices to interpret specific protocol header fields. It presents a 1163 need for architectural changes and consideration of approaches to the 1164 way network transport protocols are designed when using 1165 encryption[Measure]. 1167 The use of encryption at the transport layer comes with implications 1168 that need to be considered: 1170 Troubleshooting and diagnostics: Encrypting all transport information 1171 eliminates the incentive for operators to troubleshoot what they 1172 cannot interpret: one flow experiencing packet loss looks like any 1173 other. When transport header encryption prevents decoding the 1174 transport header (if sequence numbers and flow ID are obscured), 1175 and hence understanding the impact on a particular flow or flows 1176 that share a common network segment. Encrypted traffic therefore 1177 implies "don't touch", and a likely first response will be "can't 1178 help, no trouble found", or the need to add complexity that comes 1179 with an additional operational cost [I-D.mm-wg-effect-encrypt]. 1181 Open verifyable data: The use of transport header encryption may 1182 reduce the range of actors who can capture useful measurement 1183 data. This may in future restrict the information sources 1184 available to the Internet community to understand the operation of 1185 the network and transport protocols, necessary to inform 1186 standardisation and design decisions for new protocols, equipment 1187 and operational practices. There are dangers in a model where 1188 transport information is only observable at endpoints: i.e., at 1189 user devices and within service platforms and a need for 1190 independently captured data to develop open standards and 1191 stimulate research into new methods. 1193 Operational practice: Published transport specifications allow 1194 operators to check compliance. This can bring assurance to those 1195 operating networks, often avoiding the need to deploy complex 1196 techniques that routinely monitor and manage TCP/IP traffic flows 1197 (e.g. Avoiding the capital and operational costs of deploying 1198 flow rate-limiting and network circuit-breaker methods). This 1199 should continue when encrypted transport headers are used, but 1200 methods need to confirm that the traffic produced conforms to the 1201 expectations of the operator or developer. 1203 Traffic analysis: The use of encryption could make it harder to 1204 determine which transport methods are being used across a network 1205 segment and the trends in usage. This could impact the ability 1206 for an operator to anticipate the need for network upgrades and 1207 roll-out. It can also impact on-going traffic engineering 1208 activities. Although the impact in many case may be small, there 1209 are cases where operators directly support services (e.g., in 1210 radio links, or to troubleshoot QoS-related issues). The more 1211 complex the underlying infrastructure the more important this 1212 impact. 1214 Interactions between mechanisms: An appropriate vantage point, 1215 coupled with timing information for the flow (fine-grained 1216 timestamps) is a valuable tool in benchmarking equipment/ 1217 configurations and understanding non-trivial interactions. 1218 Encryption restricts the ability to explore interactions between 1219 functions at different protocol layers. This is a side-effect of 1220 not allowing a choice of the vantage point from which this 1221 information is observed. This can be important (e.g., in 1222 examining collateral impact of flows sharing a bottleneck, or 1223 where the intention is to understand the interaction between a 1224 layer 2 function (e.g., radio resource management policy, a 1225 channel impairment, an AQM configuration, a Per Hop Behaviour 1226 (PHB) or scheduling method, and a transport protocol). 1228 Common specifications: Since the introduction of congestion control, 1229 TCP has continued to be the predominate transport, with a 1230 consistent approach to avoiding congestion collapse. There is a 1231 risk that the diversity of transport mechanisms could also 1232 increase, with incentives to use a wide range of methods, this is 1233 not in itself a problem, nor is this a direct result of 1234 encryption. Encryption of all headers places the onus on 1235 validation in the hands of developers. While there is little to 1236 doubt that developers will seek to produce high quality code for 1237 their target use, it is not clear whether there is sufficient 1238 incentive to ensure good practice that benefits the wide diversity 1239 of requirements from the Internet community as a whole. The use 1240 of encryption needs to be weighed against the reduced visibility 1241 of the interactions between traffic, the network and the 1242 mechanisms. Especially, if a development cycle could focus on 1243 specific protocols/applications and then offer incentives for 1244 optimisations that could prove suboptimal for users or operators 1245 that utilise a network segments with different characteristics 1246 than targeted by the developer. 1248 Restricting research and development: The use of encryption may 1249 impede independent research into new mechanisms, measurement of 1250 behaviour, and development initiatives. Experience shows that 1251 transport protocols are complicated to design and complex to 1252 deploy, and that individual mechanisms need to be evaluated while 1253 considering other mechanism, across a broad range of network 1254 topologies and with attention to the impact on traffic sharing the 1255 capacity. Adopting pervasive encryption of transport information 1256 could eliminate the independent self-checks that have previously 1257 been in place from research and academic contributors (e.g., the 1258 role of the IRTF ICCRG, and research publications in reviewing new 1259 transport mechanisms and assessing the impact of their 1260 experimental deployment). 1262 Pervasive use of transport header encryption can impact the ways that 1263 future protocols are designed and deployed. The choice of whether 1264 candidate transport designs should encrypt their protocol headers 1265 therefore needs to be taken based not just on security 1266 considerations, but also on the impact on operating networks and the 1267 constrictions this may place on evolution of Internet protocols. 1268 While encryption of all transport information can help reduce 1269 ossification of the transport layer, it could result in ossification 1270 of the network service. There can be advantages in providing a level 1271 of ossification of the header in terms of providing a set of open 1272 specified header fields that are observable from in-network devices. 1274 8. Acknowledgements 1276 The author would like to thank all who have talked to him face-to- 1277 face or via email. ... 1279 This work has received funding from the European Union's Horizon 2020 1280 research and innovation programme under grant agreement No 688421.The 1281 opinions expressed and arguments employed reflect only the authors' 1282 view. The European Commission is not responsible for any use that 1283 may be made of that information. 1285 9. IANA Considerations 1287 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1289 This memo includes no request to IANA. 1291 10. Security Considerations 1292 This document is about design and deployment considerations for 1293 transport protocols. Authentication, confidentiality protection, and 1294 integrity protection are identified as Transport Features by 1295 RFC8095". As currently deployed in the Internet, these features are 1296 generally provided by a protocol or layer on top of the transport 1297 protocol; no current full-featured standards-track transport protocol 1298 provides these features on its own. Therefore, these features are 1299 not considered in this document, with the exception of native 1300 authentication capabilities of TCP and SCTP for which the security 1301 considerations in RFC4895. 1303 Like congestion control mechanisms, security mechanisms are difficult 1304 to design and implement correctly. It is hence recommended that 1305 applications employ well-known standard security mechanisms such as 1306 DTLS, TLS or IPsec, rather than inventing their own. 1308 11. References 1310 11.1. Normative References 1312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1314 RFC2119, March 1997, . 1317 11.2. Informative References 1319 [I-D.dolson-plus-middlebox-benefits] 1320 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1321 "Beneficial Functions of Middleboxes", Internet-Draft 1322 draft-dolson-plus-middlebox-benefits-03, March 2017. 1324 [I-D.ietf-aqm-codel] 1325 Nichols, K., Jacobson, V., McGregor, A. and J. Jana, 1326 "Controlled Delay Active Queue Management", Internet-Draft 1327 draft-ietf-aqm-codel-00, October 2014. 1329 [I-D.ietf-aqm-fq-codel] 1330 Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1331 J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft 1332 draft-ietf-aqm-fq-codel-00, January 2015. 1334 [I-D.ietf-aqm-pie] 1335 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1336 Lightweight Control Scheme To Address the Bufferbloat 1337 Problem", Internet-Draft draft-ietf-aqm-pie-00, October 1338 2014. 1340 [I-D.ietf-ippm-6man-pdm-option] 1341 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1342 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1343 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1344 option-10, May 2017. 1346 [I-D.ietf-quic-transport] 1347 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1348 and Secure Transport", Internet-Draft draft-ietf-quic- 1349 transport-03, May 2017. 1351 [I-D.ietf-tcpm-accurate-ecn] 1352 Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More 1353 Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- 1354 tcpm-accurate-ecn-00, December 2015. 1356 [I-D.ietf-tcpm-dctcp] 1357 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1358 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 1359 Control for Datacenters", Internet-Draft draft-ietf-tcpm- 1360 dctcp-06, May 2017. 1362 [I-D.ietf-tsvwg-l4s-arch] 1363 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1364 Low Loss, Scalable Throughput (L4S) Internet Service: 1365 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1366 arch-00, May 2017. 1368 [I-D.mm-wg-effect-encrypt] 1369 Moriarty, K. and A. Morton, "Effect of Pervasive 1370 Encryption on Operators", Internet-Draft draft-mm-wg- 1371 effect-encrypt-11, April 2017. 1373 [I-D.trammell-plus-abstract-mech] 1374 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1375 Layer under Endpoint Control", Internet-Draft draft- 1376 trammell-plus-abstract-mech-00, September 2016. 1378 [I-D.trammell-plus-statefulness] 1379 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1380 "Transport-Independent Path Layer State Management", 1381 Internet-Draft draft-trammell-plus-statefulness-02, 1382 December 2016. 1384 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1385 Techniques and Their Merits", November 2014. 1387 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1388 based Protocol Design", June 2017. 1390 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1391 "Definition of the Differentiated Services Field (DS 1392 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1393 10.17487/RFC2474, December 1998, . 1396 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1397 Shelby, "Performance Enhancing Proxies Intended to 1398 Mitigate Link-Related Degradations", RFC 3135, DOI 1399 10.17487/RFC3135, June 2001, . 1402 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1403 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1404 DOI 10.17487/RFC3168, September 2001, . 1407 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1408 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1409 . 1411 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1412 Sooriyabandara, "TCP Performance Implications of Network 1413 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1414 December 2002, . 1416 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1417 Jacobson, "RTP: A Transport Protocol for Real-Time 1418 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1419 July 2003, . 1421 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1422 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 1423 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1424 RFC 3819, DOI 10.17487/RFC3819, July 2004, . 1427 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1428 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1429 December 2005, . 1431 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1432 10.17487/RFC4302, December 2005, . 1435 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1436 4303, DOI 10.17487/RFC4303, December 2005, . 1439 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1440 "Extended RTP Profile for Real-time Transport Control 1441 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1442 10.17487/RFC4585, July 2006, . 1445 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1446 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1447 10.17487/RFC4737, November 2006, . 1450 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1451 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1452 DOI 10.17487/RFC5236, June 2008, . 1455 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1456 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1457 RFC5246, August 2008, . 1460 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1461 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1462 . 1464 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1465 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1466 June 2010, . 1468 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1469 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1470 January 2012, . 1472 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1473 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1474 RFC6437, November 2011, . 1477 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1478 and K. Carlberg, "Explicit Congestion Notification (ECN) 1479 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1480 2012, . 1482 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1483 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1484 2014, . 1486 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1487 for Secure Use of Transport Layer Security (TLS) and 1488 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1489 7525, DOI 10.17487/RFC7525, May 2015, . 1492 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1493 Recommendations Regarding Active Queue Management", BCP 1494 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1497 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1498 Trammell, B., Huitema, C. and D. Borkmann, 1499 "Confidentiality in the Face of Pervasive Surveillance: A 1500 Threat Model and Problem Statement", RFC 7624, DOI 1501 10.17487/RFC7624, August 2015, . 1504 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1505 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1506 DOI 10.17487/RFC7713, December 2015, . 1509 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1510 Ros, "Characterization Guidelines for Active Queue 1511 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1512 2016, . 1514 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1515 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1518 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1519 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1520 March 2017, . 1522 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1523 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1524 2017, . 1526 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1527 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1528 10.17487/RFC8087, March 2017, . 1531 [Tor] The Tor Project, ., "https://www.torproject.org", June 1532 2017. 1534 Appendix A. Revision information 1536 -00 This is an individual draft for the IETF community 1538 -01 This draft was a result of walking away from the text for a few 1539 days and then reorganising the content. 1541 -01 This draft fixes textua errors. 1543 Comments from the community are welcome on the text and 1544 recommendations. 1546 Author's Address 1548 Godred Fairhurst 1549 University of Aberdeen 1550 Department of Engineering 1551 Fraser Noble Building 1552 Aberdeen, AB24 3UE 1553 Scotland 1555 Email: gorry@erg.abdn.ac.uk 1556 URI: http://www.erg.abdn.ac.uk/