idnits 2.17.1 draft-pardue-httpbis-http-network-tunnelling-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 : ---------------------------------------------------------------------------- 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 (October 18, 2018) is 2017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-13 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-10 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-01 == Outdated reference: A later version (-07) exists of draft-ietf-httpbis-h2-websockets-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-13 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis L. Pardue 3 Internet-Draft October 18, 2018 4 Intended status: Informational 5 Expires: April 21, 2019 7 HTTP-initiated Network Tunnelling (HiNT) 8 draft-pardue-httpbis-http-network-tunnelling-01 10 Abstract 12 The HTTP CONNECT method allows an HTTP client to initiate, via a 13 proxy, a TCP-based tunnel to a single destination origin. This memo 14 explores options for expanding HTTP-initiated Network Tunnelling 15 (HiNT) to cater for diverse UDP and IP associations. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 21, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6 53 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. Design Consideration Aspects . . . . . . . . . . . . . . . . 7 55 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 7 56 3.2. HTTP Forward Proxying . . . . . . . . . . . . . . . . . . 7 57 3.3. Message Destination Agility . . . . . . . . . . . . . . . 7 58 3.4. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 7 59 3.5. Blind forwarding vs. in-the-loop Processing . . . . . . . 8 60 3.6. Head-of-line Blocking . . . . . . . . . . . . . . . . . . 8 61 4. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. CONNECT Method Augmentation . . . . . . . . . . . . . . . 9 63 4.2. UDPASSOCIATE with HINT Frames for HTTP/2 and HTTP/QUIC . 9 64 4.3. HELIUM over WebSockets for all HTTP Versions . . . . . . 9 65 4.4. HELIUM over WebSockets for HTTP/1.1, Native Framing for 66 HTTP/2 or HTTP/QUIC . . . . . . . . . . . . . . . . . . . 9 67 5. Technical Specification for HiNT Requests . . . . . . . . . . 10 68 5.1. The UDPASSOCIATE Method for HTTP/1.1x . . . . . . . . . . 10 69 5.2. The UDPASSOCIATE Method for HTTP/2 and HTTP/QUIC . . . . 11 70 5.3. The IPASSOCIATE Method . . . . . . . . . . . . . . . . . 12 71 6. Technical Specification for HiNT Message Transfer . . . . . . 12 72 6.1. HiNT Message Framing . . . . . . . . . . . . . . . . . . 12 73 6.1.1. The HINT HTTP/2 Frame . . . . . . . . . . . . . . . . 13 74 6.1.2. The HINT HTTP/QUIC Frame . . . . . . . . . . . . . . 14 75 6.2. Light HIP HTTP/2 Framing . . . . . . . . . . . . . . . . 14 76 6.3. Full HIP HTTP/2 Framing . . . . . . . . . . . . . . . . . 15 77 6.3.1. The OHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 16 78 6.3.2. The IHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 17 79 6.3.3. The MHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 8.1. UDPASSOCIATE Method Registration . . . . . . . . . . . . 20 83 8.2. IPASSOCIATE Method Registration . . . . . . . . . . . . . 21 84 8.3. The HINT HTTP/2 Frame Type . . . . . . . . . . . . . . . 21 85 8.4. The HINT HTTP/QUIC Frame Type . . . . . . . . . . . . . . 21 86 8.5. The HIP HTTP/2 Frame Type . . . . . . . . . . . . . . . . 22 87 8.6. The OHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 22 88 8.7. The IHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 22 89 8.8. The MHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 22 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 92 9.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 94 Appendix B. HiNT Request Options . . . . . . . . . . . . . . . . 25 95 Appendix C. HiNT Message Transfer Options . . . . . . . . . . . 26 96 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 28 97 D.1. Since draft-pardue-httpbis-http-network-tunnelling-00 . . 29 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 A wide range of network tunnelling solutions already exist (e.g. 103 SOCKS [RFC1928], TURN [RFC5766] etc.), with various applicability. 104 So why consider creating another one? Several tunnelling 105 specifications reserve well known TCP or UDP ports that are easy to 106 block. Even if port usage is more agile, plain text communications 107 allow potential attackers to easily analyse traffic and cause 108 interference. 110 This document we consider options for HTTP-initiated Network 111 Tunnelling (HiNT) as a solution. The use case is a client behind a 112 forward proxy but other uses may be supported. Using HTTP as a 113 substrate for other protocols follows a trend seen elsewhere (DNS 114 Queries over HTTPS [DOH]). Shifting to an HTTP port, makes port 115 blocking less effective. However, the real advantage comes from 116 securing HTTP (TLS [RFC5246], QUIC [QUIC-TRANSPORT]) to provide 117 confidentiality, integrity and authenticity, which makes analysis and 118 interference harder. This also enables secure communication to a 119 remote proxy on the Internet (in contrast to SOCKS etc.). 121 A HiNT session is initiated by some HTTP mechanism. This could be a 122 HTTP request or some binary frame format (HTTP/2 and HTTP/QUIC only). 124 Client Forward Proxy Server 125 + + + 126 | +------------------------------------+ | | 127 | | TCP Connection | | | 128 | | | | | 129 | | CONNECT example.org | | | 130 +=========================================>| | 131 | | 200 OK | | +-----------------+ | 132 |<=========================================+ | TCP Connection | | 133 | | | | | | | 134 | | +------------------------------------------------------+ | | 135 | | | TLS Session | | | | | | 136 | | | | | | | | | 137 | | | GET /foo | | | | | | 138 +=================================================================>| 139 | | | 200 OK | | | | | | 140 |<=================================================================+ 141 | | | | | | | | | 142 | | +------------------------------------------------------+ | | 143 | | | | | | | 144 | +------------------------------------+ | +-----------------+ | 145 + + + 147 Figure 1: HTTP/1.1 CONNECT-based TLS tunnel 149 The CONNECT request method (see Section 4.3.6 of [RFC7231]) is 150 commonly used to establish a tunnelled TLS session with an origin 151 identified by a request-target. In HTTP/1.1, the entire client-to- 152 proxy HTTP connection is converted into a tunnel (Figure 1). In 153 HTTP/2 (see Section 8.3 of [RFC7540]) and HTTP/QUIC (see 154 Section 3.1.2 of [QUIC-HTTP]), a single stream gets dedicated to a 155 tunnel (Figure 2). 157 Client Forward Proxy Server 158 + + + 159 | +------------------------------------+ | | 160 | | TCP Connection or UDP Association | | | 161 | | +------------------------------+ | | | 162 | | | TLS or QUIC Security Context | | | | 163 | | | +------------------------+ | | | | 164 | | | | HTTP/2 or HTTP/QUIC | | | | | 165 | | | | Stream | | | | | 166 | | | | | | | | | 167 | | | | CONNECT example.org | | | | | 168 +=========================================>| | 169 | | | | 200 OK | | | | +-----------------+ | 170 |<=========================================+ | TCP Connection | | 171 | | | | | | | | | | | 172 | | | | +------------------------------------------------+ | | 173 | | | | | TLS Session | | | | | | | | 174 | | | | | +------------------------------------------+ | | | 175 | | | | | | HTTP/2 Stream | | | | | | | | | 176 | | | | | | | | | | | | | | | 177 | | | | | | GET /foo | | | | | | | | | 178 +=================================================================>| 179 | | | | | | 200 OK | | | | | | | | | 180 |<=================================================================+ 181 | | | | | | | | | | | | | | | 182 | | | | | +------------------------------------------+ | | | 183 | | | | | | | | | | | | | 184 | | | | +------------------------------------------------+ | | 185 | | | | | | | | | | | 186 | | | +------------------------+ | | | | | | 187 | | | | | | | | | 188 | | +------------------------------+ | | | | | 189 | | | | | | | 190 | +------------------------------------+ | +-----------------+ | 191 + + + 193 Figure 2: HTTP/2 and HTTP/QUIC CONNECT-based TLS tunnel 195 A proxy that supports CONNECT blindly forwards packets, in both 196 directions, using TCP for both client-to-proxy and proxy-to-origin 197 hops. The use of TCP for the latter hop is a limiting factor: other 198 application or transport protocols are unsupported. This document 199 specifically concerns itself with finding a solution that permits a 200 UDP-based HTTP/QUIC client behind an HTTP proxy to establish an HTTP/ 201 QUIC session with the origin. Without such a capability, there 202 continues to be a dependency on origins to support TCP-based HTTP 203 (for a small subset of the client population). 205 The document is arranged in the following order: 207 o Design aspects are considered in Section 3. 209 o Tunnel initiation options are surveyed in Appendix B. 211 o Messaging (post-handshake data transfer) options are surveyed in 212 Appendix C. 214 o Four candidate solutions are presented in Section 4, based on the 215 above options. 217 Candidate solutions have the purpose of stimulating discussion in the 218 community in order to drive toward a single solution. 220 2. Notational Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in BCP 225 14 [RFC2119] [RFC8174] when, and only when, they appear in all 226 capitals, as shown here. 228 2.1. Definitions 230 Definitions of terms that are used in this document: 232 o HiNT request: a message that requests the establishment of a 233 network tunnel to a HiNT destination. 235 o HiNT response: a message that confirms the establishment of a 236 network tunnel. 238 o HiNT message: a message that allows data transfer between client, 239 proxy and/or destination during a HiNT session. 241 o HiNT client: an HTTP endpoint that sends a HiNT request to a HiNT 242 proxy. Also referred to as a client. 244 o HiNT proxy: an HTTP endpoint that services HiNT requests. It 245 returns a HiNT response that indicates the outcome of network 246 tunnel creation. Also referred to as a proxy. 248 o HiNT destination: the service that the HiNT client is trying to 249 reach via a HiNT proxy. Also referred to as a destination. 251 o HiNT session: a specific instance of a network tunnel. 253 o Network Tunnel: describes any forms of association between client 254 and destination (end-to-end). A tunnel ceases to exist when both 255 ends of the association are closed (implicitly or explicitly). 257 3. Design Consideration Aspects 259 3.1. HTTP Version 261 The design should consider if all HTTP Versions need be supported. 262 Differences in version syntax (in particular binary framing and 263 streams) may provide certain design advantages. 265 3.2. HTTP Forward Proxying 267 The design considers the "forward proxying" intermediary (see 268 Section 2.3 of [RFC7230]) model, which is widely deployed. 270 HTTP clients may use a range of methods to discover the presence of 271 an HTTP proxy (WPAD, DHCP, manual configuration). Client 272 application-layer communications remain unaware of such 273 configuration. (In other words, handshake and data transfer 274 interactions with the HTTP proxy are invisible to the application 275 layer.) 277 Intermediaries may themselves have an HTTP proxy configured. A 278 client attempting to initiate a tunnel to a remote host may end up 279 traversing a proxy chain. This is a useful design characteristic and 280 should be considered when selecting a preferred option. 282 3.3. Message Destination Agility 284 The CONNECT method currently expresses a request-target. This is a 285 "fixed destination mode" where all messages travel on the same fixed 286 TCP path to the same destination (ignoring lower level network 287 elements). 289 The design should consider if more agile approach i.e. a "per-message 290 destination mode" would support new network interaction models. This 291 may add per-message overhead but optimisation may be possible. 293 3.4. Path MTU Discovery 295 The design should consider that endpoints may want/be required to 296 avoid IP fragmentation. Support for reasonable attempts at path MTU 297 discovery (PMTUD) should be included. Traditional PMTUD methods 298 (such as those described in [RFC1191] and [RFC8201] are intended for 299 TCP and rely on ICMP and ICMPv6 messages. [RFC2293] catalogs some of 300 the problems with PMTUD. Packetization Layer PMTUD (PLPMTUD) 302 [RFC4821] is an extension that describes an algorithm that can 303 operate at the transport layer. Datagram PLPMTUD [DPLPMTUD] is a 304 proposed further extension that describes approaches for various UDP- 305 based transports. 307 3.5. Blind forwarding vs. in-the-loop Processing 309 [RFC7230] describes a tunnel as "a blind relay between two 310 connections without changing messages". This approach may be overly 311 restrictive for new interaction modes. 313 In the case of CONNECT for TCP-based tunnelling, the HiNT message 314 sent by a client (TCP/IP packet payload) is decapsulated at the proxy 315 and recapsulated in a new TCP/IP packet created and sent by the 316 proxy. The proxy performs no processing of the HiNT message. 318 [HELIUM] proposes an alternative model, where the proxy does (and is 319 expected to) modify HiNT messages. 321 3.6. Head-of-line Blocking 323 The current design of CONNECT-based tunnelling reserves either a 324 whole TCP connection (HTTP/1.1) or an ordered byte stream (HTTP/2 and 325 HTTP/QUIC) for the client-to-proxy hop. These are subject to head- 326 of-line (HoL) blocking. For example, where there is an end-to-end 327 tunnelled HTTP/2 connection, all of its streams are subject to the 328 blocking on the single reserved stream. It is unknown to the author 329 is this is perceived to be a high impact problem. 331 This document defines HTTP/2 and HTTP/QUIC frames (Section 6) that 332 are sent on HTTP/2 or QUIC streams respecitvely. 334 For UDP or IP-based tunnels, HoL blocking may be problematic. It is 335 unlikely that the application expects blocking to occur, leading to 336 potential issues. (QUIC is specifically designed to avoid HoL 337 blocking and is designed to operate on unreliable UDP, a reliable 338 bearer may adversely affect performance.) 340 Future versions of QUIC may offer partial reliability. If it were 341 used for the client-to-proxy hop, it could help mitigate HoL blocking 343 The design should consider the tension between the benefits of 344 tunnelling, impact of HoL, and HTTP version Section 3.1. 346 4. Candidate Solutions 348 Strawman candidate solutions are presented in order of increasing 349 perceived complexity. It is hoped that wider input will help shape 350 the solution. 352 4.1. CONNECT Method Augmentation 354 Enhance or augment the current definitions of the CONNECT method in 355 HTTP/1.x, HTTP/2 and HTTP/QUIC. Data exchanges between a client and 356 a single destination will be conveyed over existing byte streams with 357 no additional framing. Client and proxy are required to assign 358 meaning to groups of bytes delivered on the stream, which may be 359 impractical. 361 4.2. UDPASSOCIATE with HINT Frames for HTTP/2 and HTTP/QUIC 363 Define a new method, UDPASSOCIATE (Section 5.1), that reserves a 364 stream for the carriage of newly defined HINT frames (Section 6.1). 365 Data exchanges between a client and a single destination will be 366 conveyed using these frames. This requires HTTP/2 or HTTP/QUIC 367 proxies, and precludes HTTP/1.x (because there is no means for 368 framing HiNT messages). 370 4.3. HELIUM over WebSockets for all HTTP Versions 372 Tunnelling of UDP or IP using HELIUM ([HELIUM]) over WebSockets. 373 Data exchanges between a client and destination(s) will be conveyed 374 using CBOR-encoded HIP messages. WebSockets connections between 375 client and proxy are established by existing means. This option 376 would work for all HTTP versions that support WebSockets. 378 4.4. HELIUM over WebSockets for HTTP/1.1, Native Framing for HTTP/2 or 379 HTTP/QUIC 381 Tunnelling of UDP or IP using HELIUM ([HELIUM]). Data exchanges 382 between a client and destination(s) will be conveyed using HIP 383 messages appropriate for the HTTP version. 385 For HTTP/1.x, WebSockets with CBOR-encoded HIP messages would be 386 used. 388 For HTTP/2 and HTTP/QUIC, HIP messages would be framed and exchanged 389 on a stream reserved by the new method, IPASSOCIATE (Section 5.3). 391 There are two framing options presented: light framing (Section 6.2) 392 that uses the CBOR-encoded format, which would allow direct reuse of 393 code to that used for the above WebSocket substrate; full framing 394 (Section 6.3) that uses the native features of the application layer 395 substrate, which may have advantages. 397 5. Technical Specification for HiNT Requests 399 This section outlines the technical specifications required to 400 support the candidate solutions. Discussion of respective merits and 401 drawbacks is captured in Appendix B. 403 5.1. The UDPASSOCIATE Method for HTTP/1.1x 405 In HTTP/1.x, the UDPASSOCIATE method requests that the recipient 406 establish a UDP-based tunnel to the destination origin server 407 identified by the request-target and, if successful, thereafter 408 restrict its behavior to blind forwarding of UDP datagram payloads, 409 in both directions, until the tunnel is closed. 411 UDPASSOCIATE is intended only for use in requests to a proxy. An 412 origin server that receives a UDPASSOCIATE request for itself MAY 413 respond with a 2xx (Successful) status code to indicate that a 414 connection is established. TODO: explicitly ban this? 416 A client sending a UDPASSOCIATE request MUST send the authority form 417 of request-target (Section 5.3 of [RFC7230]); i.e., the request- 418 target consists of only the host name and port number of the tunnel 419 destination, separated by a colon. The port number is for UDP only. 421 UDPASSOCIATE hq.example.com:50781 HTTP/1.1 422 Host: hq.example.com:50781 424 The recipient proxy can establish a tunnel either by directly 425 connecting to the request-target or, if configured to use another 426 proxy, by forwarding the UDPASSOCIATE request to the next inbound 427 proxy. Any 2xx (Successful) response indicates that the sender (and 428 all inbound proxies) will switch to tunnel mode immediately after the 429 blank line that concludes the successful response's header section; 430 data received after that blank line is from the server identified by 431 the request-target. Any response other than a successful response 432 indicates that the tunnel has not yet been formed and that the 433 connection remains governed by HTTP. 435 TODO: how do connectionless UDP associations affirm that connection 436 to the remote host succeeded? Perhaps a 2xx should be formed when 437 the proxy believes it has sufficient capability to send or receive 438 packets. 440 A tunnel is closed when an intermediary detects that either side has 441 closed its connection (explicitly or implicitly). The intermediary 442 MUST attempt to send any outstanding data that came from the closed 443 side to the other side, close both connections, and then discard any 444 remaining data left undelivered. 446 A server MUST NOT send any Transfer-Encoding or Content-Length header 447 fields in a 2xx (Successful) response to UDPASSOCIATE. A client MUST 448 ignore any Content-Length or Transfer-Encoding header fields received 449 in a successful response to UDPASSOCIATE. 451 A payload within a UDPASSOCIATE request message has no defined 452 semantics. 454 5.2. The UDPASSOCIATE Method for HTTP/2 and HTTP/QUIC 456 In HTTP/2 and HTTP/QUIC, the UDPASSOCIATE method requests the 457 establishment of a tunnel to a single remote host over a single 458 stream. This mechanism has a few differences from the header field 459 mapping described in [RFC7540], Section 8.1.2.3: 461 o The ":method" pseudo-header field is set to "UDPASSOCIATE" 463 o The ":scheme" and ":path" pseudo-header fields MUST be omitted 465 o The ":authority" pseudo-header field contains the host and port to 466 connect to (equivalent to the authority-form of the request-target 467 of CONNECT requests (see [RFC7230], Section 5.3)). 469 A UDPASSOCIATE method that does not conform to these restrictions is 470 malformed ([RFC7540], Section 8.1.2.6). 472 A proxy that supports UDPASSOCIATE can establish a tunnel to the 473 server identified in the ":authority" pseudo-header field. Once this 474 is completed (see earlier TODO), the proxy sends a HEADERS frame 475 containing a 2xx series status code to the client. 477 A successful UDPASSOCIATE request reserves the request stream for 478 tunnelling. After the initial HEADERS frame sent by each peer, all 479 subsequent frames exchanged on this stream correspond to data sent on 480 the UDP association. Section 6.1, Section 6.2 and Section 6.3 481 explore options for application-level framing and the mapping to UDP. 482 Some frame types MUST NOT be sent on the reserved stream (e.g. 483 RST_STREAM and more TBD). An endpoint that receives any of these 484 MUST respond with a connection error. 486 The UDP association can be closed (explicitly or implicitly) by 487 either peer. It is RECOMMENDED that peers close the association 488 explicitly using tunnelled application-level means (if possible). 489 Once this has happened, the client SHOULD close the reserved stream 490 on the client-to-proxy hop. Closing the reserved stream before an 491 explicit close is likely to trigger an application-level implicit 492 close (i.e. idle timeout). 494 5.3. The IPASSOCIATE Method 496 The IPASSOCIATE method can be used by a client to request that the 497 recipient establish an IP-based tunnel to the destination origin 498 server identified by the request-target and, if successful, 499 thereafter restrict its behaviour to blind forwarding of IP payloads, 500 in both direction, until the tunnel is closed. 502 The IPASSOCIATE method would look and behave much like the 503 UDPASSOCIATE method. 505 TODO: expand this definition if this method is preferred or required. 506 Additional parameters may be required to accommodate the extra 507 capabilities of IP-based tunnels. 509 6. Technical Specification for HiNT Message Transfer 511 This section outlines the technical specifications required to 512 support the candidate solutions. Discussion of respective merits and 513 drawbacks is captured in Appendix C. 515 6.1. HiNT Message Framing 517 The HINT frame carries HiNT messages between client and proxy. Is 518 intended to be used with versions of HTTP that support binary 519 framing. Definitions are provided for HTTP/2 and HTTP/QUIC, 520 differing only in their use of padding. (The QUIC transport 521 ([QUIC-TRANSPORT]) provides padding itself.) Frames are non-critical 522 extensions to their respective protocols. Endpoints that do not 523 support these frames will ignore them. 525 The payload of each HINT frame corresponds to a UDP datagram (or IP 526 Packet?) sent or received by a HiNT proxy. A separate HiNT request 527 is REQUIRED in order to initiate the tunnel with which these frames 528 relate. 530 HINT frames are subject to flow control. The size of HINT frames 531 should take into consideration the path MTU. Methods for path MTU 532 discovery are discussed in Section 3.4. 534 Frames MUST be associated with a non-control stream. If a frame is 535 received on a control stream, the recipient MUST respond with a 536 connection error. For HTTP/2 this is PROTOCOL_ERROR, for HTTP/QUIC 537 this is TBD. 539 6.1.1. The HINT HTTP/2 Frame 541 The HINT HTTP/2 frame (type=0xTBD) defines the following flags (based 542 on HTTP/2 flags): 544 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 545 last that the endpoint will send for the identified stream. 546 Setting this flag causes the stream to enter one of the "half- 547 closed" states or the "closed" state ([RFC7540], Section 5.1). 549 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 550 and any padding that it describes are present. 552 0 1 2 3 553 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 |Pad Length? (8)| Payload (*) ... 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Padding (*) ... 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 3: HINT HTTP/2 frame payload 562 The HINT HTTP/2 frame payload has the following fields: 564 Pad Length: An OPTIONAL 8-bit field containing the length of the 565 frame padding in units of octets. This field is only present if 566 the PADDED flag is set. 568 Payload: Arbitrary octets that correspond to messages sent to/from a 569 HiNT proxy. 571 Padding: Padding octets that contain no application semantic value. 572 Padding octets MUST be set to zero when sending. A receiver is 573 not obligated to verify padding but MAY treat non-zero padding as 574 a connection error ([RFC7540], Section 5.4.1) of type 575 PROTOCOL_ERROR. 577 HINT HTTP/2 frames are subject to flow control ([RFC7540], 578 Section 5.2) and can only be sent when a stream is in the "open" or 579 "half-closed (remote)" state. If an HINT HTTP/2 frame is received 580 whose stream is not in "open" or "half-closed (local)" state, the 581 recipient MUST respond with a stream error ([RFC7540] Section 5.4.2) 582 of type STREAM_CLOSED. 584 The HINT HTTP/2 frame is processed hop-by-hop. An intermediary MUST 585 NOT forward HINT HTTP/2 frames, though it can use the information 586 contained in HINT HTTP/2 frames in forming new HINT HTTP/2 frames to 587 send to its own proxy. 589 6.1.2. The HINT HTTP/QUIC Frame 591 The HINT HTTP/QUIC frame (type=0xTBD) defines no flags. 593 0 1 2 3 594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Payload (*) ... 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 4: HINT HTTP/QUIC frame payload 601 The HINT HTTP/QUIC frame carries arbitrary octets that correspond to 602 messages sent to/from a HiNT proxy. The payload MUST be non-zero- 603 length. If a HINT HTTP/QUIC frame is received with with a payload 604 length of zero, the recipient MUST respond with a stream error 605 ([QUIC-HTTP], Section 6) of type TBD. 607 The HINT HTTP/QUIC frame is processed hop-by-hop. An intermediary 608 MUST NOT forward HINT HTTP/QUIC frames, though it can use the 609 information contained in HINT HTTP/QUIC frames in forming new HINT 610 HTTP/QUIC frames to send to its own proxy. 612 6.2. Light HIP HTTP/2 Framing 614 The HELIUM inner protocol (HIP) [HELIUM] defines an abstract message 615 structure that may be carried on a variety of substrates. 617 The HIP HTTP/2 frame (type=0xTBD) carries CBOR-encoded HIP message. 618 The message type is indicated in a frame field. 620 The frame is a non-critical extension. Endpoints that do not support 621 it will ignore it. 623 The size of frame should take into consideration the path MTU. 624 Methods for path MTU discovery are discussed in Section 3.4. 626 Frames MUST be associated with a non-control stream. If a frame is 627 received on a control stream, the recipient MUST respond with a 628 connection error. For HTTP/2 this is PROTOCOL_ERROR. 630 The HIP HTTP/2 frame defines the following flags: 632 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 633 last that the endpoint will send for the identified stream. 635 Setting this flag causes the stream to enter one of the "half- 636 closed" states or the "closed" state ([RFC7540], Section 5.1). 638 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 639 and any padding that it describes are present. 641 0 1 2 3 642 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 |Pad Length? (8)| Type (8) | HIP-CBOR Message (*) ... 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Padding (*) ... 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Figure 5: HIP HTTP/2 frame payload 651 The HIP HTTP/2 frame payload has the following fields: 653 Pad Length: An OPTIONAL 8-bit field containing the length of the 654 frame padding in units of octets. This field is only present if 655 the PADDED flag is set. 657 Type: An 8-bit field that identifies the HIP message type as defined 658 in [HELIUM]. 660 HIP-CBOR Message: A HIP message expressed in CBOR encoding including 661 type, metadata (including padding), and packet or packet-prefix. 663 Padding: Padding octets that contain no application semantic value. 664 Padding octets MUST be set to zero when sending. A receiver is 665 not obligated to verify padding but MAY treat non-zero padding as 666 a connection error ([RFC7540], Section 5.4.1) of type 667 PROTOCOL_ERROR. 669 6.3. Full HIP HTTP/2 Framing 671 The OHIP, IHIP and MHIP frames (collectively xHIP) encode all HIP 672 message data directly in the HTTP/2 frame structure. 674 These frames are non-critical extensions, endpoints that do not 675 support them will ignore them. 677 The size of these frames should take into consideration the path MTU. 678 Methods for path MTU discovery are discussed in Section 3.4.2. 680 Frames MUST be associated with a non-control stream. If a frame is 681 received on a control stream, the recipient MUST respond with a 682 connection error. For HTTP/2 this is PROTOCOL_ERROR. 684 Each xHIP frame type contains zero or more instances of the Metadata- 685 entry field. Fields are processed by the HIP application layer. 687 0 1 2 3 688 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Metadata-entry (*) ... 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 A Metadata-entry field is a tuple consisting of a Key and a length- 694 delimited Value: 696 0 1 2 3 697 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Key (16) | Value Length (32) ... 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 ... | Value? ... 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Specifically: 706 Key: An unsigned, 16-bit integer representing the HIP metadata key. 708 Value Length: An unsigned, 16-bit integer indicating the length, in 709 octets of the Value field. 711 Value: An OPTIONAL sequence of octets containing an application- 712 specific value. 714 6.3.1. The OHIP HTTP/2 Frame 716 The OHIP HTTP/2 frame (type=0xTBD) carries an "outbound" HIP message. 718 The OHIP HTTP/2 frame defines the following flags: 720 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 721 last that the endpoint will send for the identified stream. 722 Setting this flag causes the stream to enter one of the "half- 723 closed" states or the "closed" state ([RFC7540], Section 5.1). 725 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 726 field and metadata that is describes are present 728 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 729 and any padding that it describes are present. 731 0 1 2 3 732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 |Pad Length? (8)| Metadata Entries? (16) | ... 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Metadata (*) ... 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Payload (*) ... 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Padding (*) ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Figure 6: OHIP HTTP/2 frame payload 745 The OHIP HTTP/2 frame payload has the following fields: 747 Pad Length: An OPTIONAL 8-bit field containing the length of the 748 frame padding in units of octets. This field is only present if 749 the PADDED flag is set. 751 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 752 of Metadata-entries held in the Metadata field. This field is 753 only present if the METADATA flag is set. 755 Metadata: Zero or more instances of the Metadata-entry field. 757 Payload: At most one packet (or prefix of a packet), in essence, a 758 standard IP packet starting with an IP header. 760 Padding: Padding octets that contain no application semantic value. 761 Padding octets MUST be set to zero when sending. A receiver is 762 not obligated to verify padding but MAY treat non-zero padding as 763 a connection error ([RFC7540], Section 5.4.1) of type 764 PROTOCOL_ERROR. 766 6.3.2. The IHIP HTTP/2 Frame 768 The IHIP HTTP/2 frame (type=0xTBD) carries an "inbound" HIP message. 770 The IHIP HTTP/2 frame defines the following flags: 772 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 773 last that the endpoint will send for the identified stream. 774 Setting this flag causes the stream to enter one of the "half- 775 closed" states or the "closed" state ([RFC7540], Section 5.1). 777 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 778 field and metadata that is describes are present 780 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 781 and any padding that it describes are present. 783 0 1 2 3 784 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 |Pad Length? (8)| Metadata Entries? (16) | ... 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 ... Metadata (*) ... 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Payload (*) ... 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Padding (*) ... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Figure 7: IHIP HTTP/2 frame payload 797 The IHIP HTTP/2 frame payload has the following fields: 799 Pad Length: An OPTIONAL 8-bit field containing the length of the 800 frame padding in units of octets. This field is only present if 801 the PADDED flag is set. 803 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 804 of Metadata-entries held in the Metadata field. This field is 805 only present if the METADATA flag is set. 807 Metadata: Zero or more instances of the Metadata-entry field. 809 Payload: A packet, in essence, a standard IP packet starting with an 810 IP header, as received by the proxy. 812 Padding: Padding octets that contain no application semantic value. 813 Padding octets MUST be set to zero when sending. A receiver is 814 not obligated to verify padding but MAY treat non-zero padding as 815 a connection error ([RFC7540], Section 5.4.1) of type 816 PROTOCOL_ERROR. 818 6.3.3. The MHIP HTTP/2 Frame 820 The MHIP HTTP/2 frame (type=0xTBD) carries a "meta" HIP message. 822 The MHIP HTTP/2 frame defines the following flags: 824 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 825 last that the endpoint will send for the identified stream. 826 Setting this flag causes the stream to enter one of the "half- 827 closed" states or the "closed" state ([RFC7540], Section 5.1). 829 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 830 field and metadata that is describes are present 832 ERROR (0x4): When set, bit 2 indicates that this frame includes an 833 Error-len field. 835 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 836 and any padding that it describes are present. 838 PAYLOAD (0xc): When set, bit 4 indicates that the Payload field is 839 present 841 0 1 2 3 842 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 |Pad Length? (8)| Metadata Entries? (16) |Err Length? (8)| 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Metadata (*) ... 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Errors (*) 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Payload? (*) ... 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Padding (*) ... 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure 8: MHIP HTTP/2 frame payload 857 The MHIP HTTP/2 frame payload has the following fields: 859 Pad Length: An OPTIONAL 8-bit field containing the length of the 860 frame padding in units of octets. This field is only present if 861 the PADDED flag is set. 863 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 864 of Metadata-entries held in the Metadata field. This field is 865 only present if the METADATA flag is set. 867 Err Length: An OPTIONAL 8-bit field containing the length of the 868 Errors field. This field is only present if the ERROR flag is 869 set. 871 Metadata: Zero or more instances of the Metadata-entry field. 873 Errors: An OPTIONAL octet array of length Err Length. Each octet of 874 the array represents a HIP error as described in [HELIUM]. 876 Payload: An OPTIONAL payload containing a prefix of the outbound 877 packet as sent, including any parts that were modified. This 878 field is only present if the PAYLOAD flag is set. 880 Padding: Padding octets that contain no application semantic value. 881 Padding octets MUST be set to zero when sending. A receiver is 882 not obligated to verify padding but MAY treat non-zero padding as 883 a connection error ([RFC7540], Section 5.4.1) of type 884 PROTOCOL_ERROR. 886 7. Security Considerations 888 This document is partly motivated by the desire to prevent exposure 889 to observers, to make detection and interference more difficult. The 890 effectiveness of this is dependent on the chosen solution. Where 891 HTTP is used only to bootstrap a HiNT session, messages will be 892 carried without additional HTTP traffic to mask them. A more secure 893 option would be to both bootstrap and carry HiNT messages inside an 894 HTTP session. This of course relies on secure HTTP to provide 895 confidentiality. 897 It is noted that different HiNT traffic may have different 898 characteristics (e.g. volumes and timing) when compared to the HTTP 899 context that it is operating in. Session level encryption is weak 900 with respect to traffic analysis. HTTP/2 provides further advice 901 about the use of compression ([RFC7540] Section 10.6) and padding 902 ([RFC7540] Section 10.7) to mitigate the ability for an observer to 903 discriminate different forms of traffic. Additional application- 904 layer padding may help. 906 TODO: Proxy authentication might be used to establish the authority 907 to create a tunnel. 909 There are significant risks in establishing a tunnel to arbitrary 910 servers. Proxies that support HiNT requests SHOULD restrict a HiNT 911 session to a limited set of known ports or a configurable white list 912 of safe request targets. 914 This section will address more security considerations once a single 915 solution is chosen. 917 8. IANA Considerations 919 8.1. UDPASSOCIATE Method Registration 921 This section registers the "UDPASSOCIATE" method in "HTTP Method 922 Registry" ([RFC7230], Section 8.1). 924 Method Name: UDPASSOCIATE 926 Safe: No 928 Idempotent: No 930 Cacheable: No 932 Specification document(s): Section 5.1 of this document 934 8.2. IPASSOCIATE Method Registration 936 This section registers the "IPASSOCIATE" method in "HTTP Method 937 Registry" ([RFC7230], Section 8.1). 939 Method Name: IPASSOCIATE 941 Safe: No 943 Idempotent: No 945 Cacheable: No 947 Specification document(s): Section 5.3 of this document 949 8.3. The HINT HTTP/2 Frame Type 951 This section registers the "HINT" frame type in the "HTTP/2 Frame 952 Type" registry ([RFC7540], Section 11.2). 954 Frame Type: HINT 956 Code: 0XTBD 958 Specification: Section 6.1.1 of this document 960 8.4. The HINT HTTP/QUIC Frame Type 962 This section registers the "HINT" frame type in the "HTTP/QUIC Frame 963 Type" registry ([QUIC-HTTP], Section 9.3). 965 Frame Type: HINT 967 Code: 0XTBD 969 Specification: Section 6.1.2 of this document 971 8.5. The HIP HTTP/2 Frame Type 973 This section registers the "HIP" frame type in the "HTTP/2 Frame 974 Type" registry ([RFC7540], Section 11.2). 976 Frame Type: HIP 978 Code: 0XTBD 980 Specification: Section 6.2 of this document 982 8.6. The OHIP HTTP/2 Frame Type 984 This section registers the "OHIP" frame type in the "HTTP/2 Frame 985 Type" registry ([RFC7540], Section 11.2). 987 Frame Type: OHIP 989 Code: 0XTBD 991 Specification: Section 6.3.1 of this document 993 8.7. The IHIP HTTP/2 Frame Type 995 This section registers the "IHIP" frame type in the "HTTP/2 Frame 996 Type" registry ([RFC7540], Section 11.2). 998 Frame Type: IHIP 1000 Code: 0XTBD 1002 Specification: Section 6.3.2 of this document 1004 8.8. The MHIP HTTP/2 Frame Type 1006 This section registers the "MHIP" frame type in the "HTTP/2 Frame 1007 Type" registry ([RFC7540], Section 11.2). 1009 Frame Type: MHIP 1011 Code: 0XTBD 1013 Specification: Section 6.3.3 of this document 1015 9. References 1017 9.1. Normative References 1019 [HELIUM] Schwartz, B., "Hybrid Encapsulation Layer for IP and UDP 1020 Messages (HELIUM)", draft-schwartz-httpbis-helium-00 (work 1021 in progress). 1023 [QUIC-HTTP] 1024 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1025 QUIC", draft-ietf-quic-http-13 (work in progress). 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, 1029 DOI 10.17487/RFC2119, March 1997, 1030 . 1032 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1033 Protocol (HTTP/1.1): Message Syntax and Routing", 1034 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1035 . 1037 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1038 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1039 DOI 10.17487/RFC7231, June 2014, 1040 . 1042 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1043 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1044 DOI 10.17487/RFC7540, May 2015, 1045 . 1047 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1048 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1049 May 2017, . 1051 9.2. Informative References 1053 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 1054 draft-ietf-doh-dns-over-https-10 (work in progress). 1056 [DPLPMTUD] 1057 Ruengeler, I., "Packetization Layer Path MTU Discovery for 1058 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-01 1059 (work in progress). 1061 [H2-WEBSOCKETS] 1062 McManus, P., Ed., "Bootstrapping WebSockets with HTTP/2", 1063 draft-ietf-httpbis-h2-websockets-02 (work in progress). 1065 [QUIC-TRANSPORT] 1066 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1067 Multiplexed and Secure Transport", draft-ietf-quic- 1068 transport-13 (work in progress). 1070 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1071 DOI 10.17487/RFC1191, November 1990, 1072 . 1074 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1075 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1076 DOI 10.17487/RFC1928, March 1996, 1077 . 1079 [RFC2293] Kille, S., "Representing Tables and Subtrees in the X.500 1080 Directory", RFC 2293, DOI 10.17487/RFC2293, March 1998, 1081 . 1083 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1084 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1085 . 1087 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1088 (TLS) Protocol Version 1.2", RFC 5246, 1089 DOI 10.17487/RFC5246, August 2008, 1090 . 1092 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1093 Relays around NAT (TURN): Relay Extensions to Session 1094 Traversal Utilities for NAT (STUN)", RFC 5766, 1095 DOI 10.17487/RFC5766, April 2010, 1096 . 1098 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1099 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1100 DOI 10.17487/RFC8201, July 2017, 1101 . 1103 Appendix A. Acknowledgments 1105 The first draft of this document was written with support from BBC 1106 Research & Development while Lucas was employed there. 1108 Many aspects of this document were inspired by the existing outputs 1109 of the HTTP Working Group and the wider IETF community. Some aspects 1110 were inspired by Mark Nottingham's previous work on HTTP/2 VPN. 1112 The author would like to thank Richard Bradbury, Katharine Daly, 1113 Piers O'Hanlon, and Ben Schwartz for design input and review of this 1114 document. 1116 Appendix B. HiNT Request Options 1118 The following list presents options for a HiNT request in no 1119 particular order: 1121 1. Enhance the CONNECT method (i.e. request/response headers) that 1122 permits negotiation of the proxy-to-destination transport 1123 protocol. 1125 * Pros: 1127 + Already widely supported for HTTP proxying use case. 1129 + Bootstrapping WebSockets for HTTP/2 [H2-WEBSOCKETS] has 1130 made some headway here. 1132 * Cons: 1134 + Deployability may be unrealistic. New types of tunnelling 1135 behaviour may not meet expectations of extant endpoints. 1137 + CONNECT method extension may not be popular. Need to 1138 consider if this is suited for all HTTP or specific 1139 version. 1141 2. Define a new method (e.g. UDPASSOCIATE Section 5.1) that is 1142 restricted to use UDP for the proxy-to-destination transport 1143 protocol. 1145 * Pros: 1147 + Clear demarcation between the conventional TCP case. 1149 + Well suited for HTTP/QUIC use case. 1151 * Cons: 1153 + Limited applicability (because it is UDP-only?). 1155 3. Define a new method (e.g. IPASSOCIATE) that permits negotiation 1156 of the proxy-to-destination transport protocol. 1158 * Pros: 1160 + Clear demarcation between the conventional TCP case. 1162 + Well suited for HTTP/QUIC use case. 1164 * Cons: 1166 + Too complicated for most needs (?). 1168 4. Define a substrate that is already supported by HTTP proxying 1169 i.e. WebSocket. 1171 * Pros: 1173 + Capable of functioning irrespective of HTTP version. 1175 * Cons: 1177 + Multiple layers requires implementation complexity and adds 1178 data transfer overhead. 1180 5. Define HTTP/2 and HTTP/QUIC means of HiNT request, e.g. a new 1181 frame or setting that is used to reserve a stream (or streams) 1182 for special processing of HiNT messages. 1184 * Pros: 1186 + Avoids coining a new method. 1188 * Cons: 1190 + Excludes HTTP/1.1. 1192 Appendix C. HiNT Message Transfer Options 1194 The following list presents options for framing of messages within a 1195 HiNT session in no particular order: 1197 1. Where CONNECT is used by an HTTP/1.1 client, each TCP/IP packet 1198 on the client-to-proxy hop maps directly to a packet (TCP/IP or 1199 UDP/IP) on the proxy-to-destination hop. 1201 * Pros: 1203 + "Simple" option that requires no new TCP framing 1204 definition. 1206 * Cons: 1208 + Breaks the layering model 1210 + In practice, the endpoints are not likely to be able to do 1211 this. 1213 2. Where CONNECT is used by an HTTP/2 or HTTP/QUIC client, each DATA 1214 frame on the client-to-proxy hop maps directly to a packet (TCP/ 1215 IP or UDP/IP) on the proxy-to-destination hop. 1217 * Pros: 1219 + Simple option that requires no additional framing. 1221 + Client and proxy already handle DATA frames. 1223 * Cons: 1225 + DATA frames are delivered on streams, which are treated as 1226 an ordered byte stream. It may not be possible to treat 1227 them individually. 1229 3. Define framing format that uses a WebSocket substrate. For 1230 example, the HELIUM Inner Protocol [HELIUM]. 1232 * Pros: 1234 + Would be supported in HTTP/1.1, HTTP/2 and HTTP/QUIC 1235 (subject to further work). 1237 * Cons: 1239 + Framing overhead which could be optimised away in HTTP/2 1240 and HTTP/QUIC. 1242 + Requires WebSocket support in endpoints. 1244 + Breaks the layering model(?). 1246 4. Define a new simple HTTP/2 and HTTP/QUIC extension frame for 1247 carriage of HiNT messages. (This would likely be subject to 1248 stream-level flow control). The frame payload would be 1249 encapsulated by the proxy. This approach is reliant on a fixed 1250 destination tunnel Section 3.3. 1252 * Pros: 1254 + Clear separation between stream-based and message-based 1255 tunnels. 1257 + Similar to how endpoints already handle CONNECT today. 1259 * Cons: 1261 + New frame may change the semantic of HTTP/2 and HTTP/QUIC. 1262 Therefore, it may need to be negotiated by a new SETTINGS 1263 parameter. 1265 + Excludes HTTP/1.1 1267 + Dependence on fixed destination tunnel may not support all 1268 desired interaction modes. 1270 5. Define a new HTTP/2 and HTTP/QUIC extension frame(s) for carriage 1271 of HiNT messages. (This would likely be subject to stream-level 1272 flow control). This could express HELIUM Inner Protocol [HELIUM] 1273 messages directly and, by virtue, would support per-message 1274 destination. 1276 * Pros: 1278 + Clear separation between stream-based and message-based 1279 tunnels. 1281 + Reduced overhead compared for HTTP/2 and HTTP/QUIC compared 1282 to carriage over WebSocket substrate. 1284 * Cons: 1286 + New frame may change the semantic of HTTP/2 and HTTP/QUIC. 1287 Therefore, it may need to be negotiated by a new SETTINGS 1288 parameter. 1290 + Some divergence from HTTP/1.1. 1292 + Differs from blind forwarding which is implemented in 1293 CONNECT proxies today. 1295 Appendix D. Changelog 1297 *RFC Editor's Note:* Please remove this section prior to 1298 publication of a final version of this document. 1300 D.1. Since draft-pardue-httpbis-http-network-tunnelling-00 1302 o Author's address. 1304 Author's Address 1306 Lucas Pardue 1308 Email: lucaspardue.24.7@gmail.com