idnits 2.17.1 draft-ohanlon-transport-info-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: With most web server deployments an origin server sits behind some form of CDN, with varying levels of fan-out to a point where an edge server is connected on the last hop to clients. The Transport-Info header SHOULD only be inserted into an HTTP stream by the last hop edge server that is connected to clients so that it conveys information pertinent to the client's direct transport path. The Transport-Info header MUST not be cached. -- The document date (March 3, 2020) is 1515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 498 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-client-hints-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-httpbis-client-hints (ref. 'I-D.ietf-httpbis-client-hints') == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-15 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP P. O'Hanlon 3 Internet-Draft J. Gruessing 4 Intended status: Standards Track British Broadcasting Corporation 5 Expires: September 4, 2020 March 3, 2020 7 The Transport-Info HTTP Header 8 draft-ohanlon-transport-info-header-01 10 Abstract 12 The Transport-Info header provides a mechanism to transmit network 13 transport related information such as current delivery rate and 14 round-trip time, from a server or a client. This information has a 15 wide range of uses such as client monitoring and diagnostics, or 16 allowing a client to adapt to current network conditions. 18 Note to Readers 20 _RFC Editor: please remove this section before publication_ 22 Source code and issues for this draft can be found at 23 https://github.com/bbc/draft-ohanlon-transport-info-header [1]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 4, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 4 63 2. The Transport-Info HTTP Header . . . . . . . . . . . . . . . 4 64 2.1. Utilisation of Transport-Info header metrics . . . . . . 6 65 3. Server based behaviour . . . . . . . . . . . . . . . . . . . 7 66 4. Client based behaviour . . . . . . . . . . . . . . . . . . . 7 67 4.1. Client side proxy considerations . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 71 6.2. Information control . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 10 75 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 77 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 11 78 B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The Transport-Info header provides for relaying of transport protocol 84 related information from either a server or client entity with the 85 aim of informing the sender's view on the transport state. The state 86 of a connection is dependent upon information based upon packet 87 exchanges during the transport processes. Firstly, there is 88 information that is common to both client and server, such as the 89 calculated round-trip time (RTT), although it may be measured using 90 different packets at each end. Secondly, there is state information 91 that exists only at each endpoint, such as the size of the 92 congestion, and receive windows. Thus certain transport state 93 information is only available at the server which can be useful to 94 the client, for example, to calculate the current transport rate. 95 This information may then be used to better inform a client of the 96 state of the network path and make appropriate adaptations. 98 The information can also be utilised by a client to provide for 99 application level client oriented metric logging to back-end systems 100 for monitoring and analysis purposes. Such data could be utilised in 101 a manner not unlike that proposed in [RFC4898]. 103 This approach is directly applicable to TCP but also can be utilised 104 with other related transport protocols, such as QUIC 105 [I-D.ietf-quic-transport]. 107 1.1. Motivation 109 This work is motivated, in part, by the fact that even modern web 110 browser-based web applications are not currently able to obtain such 111 low level information about specific connections. Additionally, some 112 information is only available at the server, such as the size of the 113 server congestion window. As a result clients often resort to 114 application level measurements, to infer such things as the current 115 delivery rate. However, these are not always indicative of the 116 performance of the transport layer, and may not be sufficiently 117 precise due to a couple of issues; Firstly, browser based timing is 118 limited by the granularity of the JavaScript timers, which were 119 reduced in the light of timing based side-channel attacks, although 120 due to new mitigations such timer limits are currently of the order 121 5us-1ms. These limits can be an issue for higher rate connections 122 and/or those with smaller transactions. Secondly, with flows where 123 the content-length is unknown, such as with chunked transfer 124 encoding, it is currently difficult to correctly measure the 125 bandwidth in the browser as the even the fetch/streams APIs do not 126 provide for sufficient information. 128 There exist W3C specifications such as the Network Information API 129 [network-info-api], which provides estimates of metrics, including 130 downlink rate and RTT, that are measured "across recently active 131 connections", but are platform and browser dependent, with limited 132 cross-browser support. In practice the downlink measurement is is 133 generally of low accuracy and of little use for informing an 134 application of dynamic network conditions, and the RTT measurement is 135 also of low accuracy. However, it is implemented in Chrome and the 136 utilisation of the API is now seen in a large proportion of websites, 137 mainly due to adoption of the API by widely used libraries. 139 This information is already being sent by servers and clients so this 140 document specifies a standard way for entities to encode and 141 transport such information. 143 1.2. Use Cases 145 The header can be used to provide sender specific transport 146 information that can inform a range of functions: 148 o Assist or drive the media quality selection algorithms for 149 streaming media. 150 o Inform initial rate selection. 151 o Provide better bandwidth information for shorter requests (e.g. 152 gRPC, audio) which are harder to measure. 154 * Could be used to drive scheduling of different flows in systems 155 such as Traefik. 156 o The RTT values are useful for informing the operation of latency 157 sensitive applications. 158 o The RTTVAR could be used to provide an estimate of 'reliability' 159 of rtt and bandwidth estimates. 160 o Inform client/browser media/data caching strategies. 161 o Use by intermediate nodes for traffic analytics and control. 163 1.3. Notational Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 This document uses the Augmented Backus-Naur Form (ABNF) notation of 172 [RFC5234] with the list rule extension defined in [RFC7230], 173 Appendix B. It includes by reference the DIGIT rule from [RFC5234] 174 and the OWS and field-name rules from [RFC7230]. 176 2. The Transport-Info HTTP Header 178 The Transport-Info header uses the proposed Structured Header draft 179 [I-D.ietf-httpbis-header-structure] 181 Transport-Info = sh-list 183 Each member of the parameterised list represents an entry that 184 contains a set of metrics reported. 186 The list members identify either the server or client that inserted 187 the value, and MUST have a type of either sh-string or sh-token. 188 Depending on the deployment, this might be a product or service name 189 (e.g., ExampleEdge or "Example CDN"), a hostname ("edge- 190 1.example.com"), and IP address, or a generated string. 192 Each member of the list can also have a number of parameters that 193 contain metrics. While all but one of these parameters are OPTIONAL, 194 implementations are encouraged to only provide as much information as 195 necessary. 197 o Exactly one parameter whose name is "ts", and whose value is an 198 sh-string indicating the measurement timestamp in [RFC3339] 199 format. 200 o Optionally one parameter whose name is "alpn", and whose value is 201 an sh-string representing the ALPN protocol identifier [alpn-ids]. 202 o Optionally one parameter whose name is "cc_algo", and whose value 203 is sh-string, conveying the name of congestion control algorithm 204 used for this connection. 205 o Optionally one parameter whose name is "cwnd", and whose value is 206 a sh-integer, conveying the size of the congestion window 207 [RFC5681] in packets. 208 o Optionally one parameter whose name is "rcv_space", and whose 209 value is a sh-integer, conveying the size of the receiver's window 210 in bytes. 211 o Optionally one parameter whose name is "dstport", and whose value 212 is a sh-integer, conveying the destination port of this connection 213 for correlation of measurements between requests. 214 o Optionally one parameter whose name is "mss", and whose value is a 215 sh-integer, conveying the size of the Maximum Segment Size in 216 bytes. 217 o Optionally one parameter whose name is "rtt", and whose value is 218 an sh-float, in milliseconds, indicating the estimate of the 219 Round-Trip Time from its transport layer. 220 o Optionally one parameter whose name is "rttvar", and whose value 221 is an sh-float, in milliseconds, indicating the estimate of the 222 variation of the Round-Trip Time [RFC6298] from its transport 223 layer. 224 o Optionally one parameter whose name is "send_rate", and whose 225 value is a sh-float, in kilobits per second, conveying the 226 calculation of the sending rate for this connection. 228 Here is an example of a header with a single set of metrics: 230 Transport-Info = ExampleEdge; ts="2019-08-30T14:56:08.069Z"; 231 alpn="h2"; send_rate="5100" 233 Whilst it is understood that such metrics may only provide an 234 instantaneous view on the transport state, the Transport-Info header 235 is designed to allow for delivery of multiple timestamped entries in 236 a single header. 238 Here is an example of the header with multiple entries, utilising the 239 structured header inner-list type: 241 Transport-Info = "edge-1.example.com"; ts="2019-08-30T14:56:08Z"; 242 cwnd=24; rtt=50; mss=1452; rttvar=10; dstport=8065, 243 "edge-1.example.com"; ts="2019-08-30T14:57:08Z"; 244 cwnd=23; rtt=55; mss=1452; rttvar=12; dstport=8065 246 If the end points support HTTP/2, and later, another technique to 247 increase temporal coverage for an ongoing session is for the client 248 to issue additional HEAD requests for the resource at the same 249 origin. This works with HTTP/2, and later, as all requests to the 250 same origin usually utilise one TCP or QUIC connection. Whilst the 251 HTTP priorities can affect the allocation of capacity between streams 252 the header will still provide an estimate of the maximum available 253 capacity. Likewise, in some cases with HTTP/2, and later, there may 254 be multiple flows traversing the same transport connection to 255 different origins if connection reuse (Section 9.1.1 of [RFC7540]) is 256 utilised, which could have a similar effect on interpretation of the 257 metrics to HTTP priorities, but may have privacy implications which 258 are addressed in the privacy section Section 6.1. 260 2.1. Utilisation of Transport-Info header metrics 262 The metrics may be used directly to inform entities that receive the 263 header. The calculation of the send rate maybe performed by the 264 sender of the header and included in the send_rate parameter, or the 265 receiver may calculate it as described below. The decision may 266 depend upon a variety of factors including the privacy consideration 267 of transporting any required parameters. 269 In the case of TCP, calculation of the transport transmission rate is 270 possible using the cwnd and rtt, and knowledge of the mss. The 271 equation being as follows: 273 send_rate = 8 * send_window / rtt 275 Where send_window = min (cwnd * mss, rcv_space) 277 If the mss is not available then it is possible to perform the 278 calculation using an estimate of the mss, or a common value such as 279 1460 for IPv4. It is understood there can be some variation for 280 different network and tunnelled paths (e.g. 1452 for IPv4 PPPoE) as 281 can been seen in recent studies [exploring-mtu], although the large 282 proportion of mss values fall within a range 1220-1460. The 283 send_window is preferably calculated using a minimum of the cwnd and 284 rcv_space, but if the rcv_space is not available it may be 285 approximated by just using the cwnd. 287 This equation maybe applied for other related window based transport 288 protocols (e.g. QUIC [I-D.ietf-quic-transport]) with similar 289 information, although it may need some modification. 291 3. Server based behaviour 293 With most web server deployments an origin server sits behind some 294 form of CDN, with varying levels of fan-out to a point where an edge 295 server is connected on the last hop to clients. The Transport-Info 296 header SHOULD only be inserted into an HTTP stream by the last hop 297 edge server that is connected to clients so that it conveys 298 information pertinent to the client's direct transport path. The 299 Transport-Info header MUST not be cached. 301 With respect to use in CORS [cors] enabled environments access to the 302 header will be subject to restrictions in cross domain requests, 303 which may be controlled through the inclusion of the Transport-Info 304 header in the Access-Control-Request-Headers header. 306 The use of the header is expected to comply with data minimisation 307 approaches where servers only send the necessary information on 308 relevant flows. 310 _RFC Editor: please remove this section before publication_ 312 The provision of the Transport-Info header is possible using a number 313 of existing server systems that already provide support for such 314 metrics, which currently utilise operating system support for the 315 "tcp_info" data structure which is available on Linux and BSD based 316 systems. 318 In terms of current implementations there is in-built support in 319 Nginx/Openresty using its variables "var.tcpinfo_rtt" etc. Apache 320 Traffic Server provides support using the TCPInfo plugin. Varnish 321 provides access to "tcp_info" using their "vmod_tcp" module. Node.js 322 has libraries such as "nodejs_tcpinfo" which provide support. Whilst 323 most of the implementations do not provide access to the TCP MSS it 324 is available via the underlying kernel "tcp_info" data structure so 325 it would be fairly straightforward to provide access to such 326 information. 328 4. Client based behaviour 330 The use of the header by a client is envisaged as a less common use- 331 case since such information is generally less readily available on 332 clients, and its general use might have privacy implications, 333 although servers will be aware of most transport state already. We 334 propose that use of the header could be controlled through the use of 335 the Allow-CH header [I-D.ietf-httpbis-client-hints]. The header can 336 enable the server to make better informed decisions based upon client 337 based transport information. In the case of non-browser clients 338 which have access to transport information directly through operating 339 system interfaces, this information can be relayed using the header. 340 Whilst with browser based clients such information could be obtained 341 through the use of the JavaScript Network Information API. 343 4.1. Client side proxy considerations 345 In the case where a client is configured to utilise a proxy directly, 346 or through the use of the HTTP CONNECT pseudo-method, this proxy 347 should be configured according to local policy as to whether it 348 passes through, modifies, or drops the Transport-Info header. This 349 decision can depend on a number of factors, including whether the 350 flows are encrypted, the utility of the header given local network 351 configuration, and also whether the header might reveal unwanted 352 information to end clients, since the Transport-Info header would 353 relate to the connection between the edge CDN node and the proxy. 355 5. IANA Considerations 357 This specification registers the following entry in the Permanent 358 Message Header Field Names registry established by [RFC3864]: 360 o Header field name: Transport-Info 361 o Applicable protocol: http 362 o Status: standard 363 o Author/Change Controller: IETF 364 o Specification document(s): [this document] 365 o Related information: 367 6. Security Considerations 369 6.1. Privacy Considerations 371 The Transport-Info header provides information about a senders view 372 of its network transport metrics, such as bandwidth and latency, to 373 its receiver. This information may potentially be abused for such 374 purposes as fingerprinting a user through their particular network 375 metrics or a time series thereof. In some situations it might also 376 be possible to infer location of users. This may also apply in the 377 case where multiple users, or user identities, share a connection 378 through the use of connection reuse mechanisms or otherwise. 380 However, these issues are not new and such information is already 381 being shared by some servers and clients to arbitrary levels of 382 accuracy. Furthermore, there are a number of other ways an attacker 383 can obtain such information. In the client side, in a browser, there 384 exist a number JavaScript based techniques to measure the bandwidth 385 and latency through existing network APIs such as the Network 386 Information, the Resource Timing, and WebRTC. On the server side, or 387 a non-browser client, there is no limit to the techniques that may be 388 applied to obtain information about network flows. 390 6.2. Information control 392 Whilst such information may be available through other mechanisms we 393 recommend that implementers minimise any potential privacy issues 394 through the application of the following approaches: - The principle 395 of data minimisation should be applied to any use of the header such 396 that only information required for the purposes of the application be 397 shared. - Any metrics deemed sensitive should apply an appropriate 398 level of quantisation and noise to the values to a level that 399 provides privacy whilst allowing for actual utility of the values. - 400 Consideration of limits to the temporal update frequency of the 401 metric values. - Any metrics that may be considered private should 402 not be sent in the header, or should be appropriately protected. - 403 Metrics should be sent over an encrypted connection. 405 If the header is delivered over a transport protocol whose content 406 can be modified without detection then parties should be aware that 407 the header could be maliciously modified to alter the metrics values 408 which could result in the client making incorrect adaptations. 410 7. References 412 7.1. Normative References 414 [I-D.ietf-httpbis-client-hints] 415 Grigorik, I. and Y. Weiss, "HTTP Client Hints", draft- 416 ietf-httpbis-client-hints-10 (work in progress), February 417 2020. 419 [I-D.ietf-httpbis-header-structure] 420 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 421 draft-ietf-httpbis-header-structure-15 (work in progress), 422 January 2020. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 430 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 431 . 433 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 434 Procedures for Message Header Fields", BCP 90, RFC 3864, 435 DOI 10.17487/RFC3864, September 2004, 436 . 438 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 439 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 440 . 442 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 443 "Computing TCP's Retransmission Timer", RFC 6298, 444 DOI 10.17487/RFC6298, June 2011, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 7.2. Informative References 453 [alpn-ids] 454 "Application-Layer Protocol Negotiation (ALPN) Protocol 455 ID", IANA , n.d., . 458 [cors] van Kesteren, A., "Cross-Origin Resource Sharing", W3C , 459 January 2014, 460 . 462 [exploring-mtu] 463 Custura, A., Fairhurst, G., and I. Learmonth, "Exploring 464 usable Path MTU in the Internet", Network Traffic 465 Measurement and Analysis Conference , April 2018, 466 . 468 [I-D.ietf-quic-transport] 469 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 470 and Secure Transport", draft-ietf-quic-transport-27 (work 471 in progress), February 2020. 473 [network-info-api] 474 Grigorik, I., "Network Information API", W3C , September 475 2019, . 477 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 478 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 479 May 2007, . 481 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 482 Specifications: ABNF", STD 68, RFC 5234, 483 DOI 10.17487/RFC5234, January 2008, 484 . 486 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 487 Protocol (HTTP/1.1): Message Syntax and Routing", 488 RFC 7230, DOI 10.17487/RFC7230, June 2014, 489 . 491 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 492 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 493 DOI 10.17487/RFC7540, May 2015, 494 . 496 7.3. URIs 498 [1] https://github.com/bbc/draft-ohanlon-transport-info-header 500 Appendix A. Acknowledgements 502 The authors would like to thank Craig Taylor, Lucas Pardue, Patrick 503 McManus, and the IETF HTTP Working Group for feedback on the 504 development of this document. 506 Appendix B. Changes 508 B.1. Since -00 510 o Issue 1 (HTTP Tunnels): Added text regarding the use of HTTP 511 CONNECT. 512 o Issue 3 (Is sub-second resolution appropriate?): Changed from UNIC 513 Epoch to RFC3339 time format. 514 o Issue 4 (Could this be used for both request and response?): 515 Updated text to describe both server and client use, and their 516 implications. 517 o Issue 5 (Privacy Implications): Added new Privacy Considerations 518 section and updated security section 519 o Issue 9 (CORS considerations): Added text to address CORS usage. 520 o Issue 10 (Provide additional use-cases): Updated motivation and 521 added use-cases section. 523 Authors' Addresses 525 Piers O'Hanlon 526 British Broadcasting Corporation 528 Email: piers.ohanlon@bbc.co.uk 530 James Gruessing 531 British Broadcasting Corporation 533 Email: james.gruessing@bbc.co.uk