idnits 2.17.1 draft-pardue-httpbis-http-network-tunnelling-00.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 (July 02, 2018) is 2117 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 BBC Research & Development 4 Intended status: Informational July 02, 2018 5 Expires: January 3, 2019 7 HTTP-initiated Network Tunnelling (HiNT) 8 draft-pardue-httpbis-http-network-tunnelling-00 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 January 3, 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 . . . . . . . . . . . . . . . . . . . 5 53 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Design Consideration Aspects . . . . . . . . . . . . . . . . 6 55 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2. HTTP Forward Proxying . . . . . . . . . . . . . . . . . . 6 57 3.3. Message Destination Agility . . . . . . . . . . . . . . . 6 58 3.4. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 7 59 3.5. Blind forwarding vs. in-the-loop Processing . . . . . . . 7 60 3.6. Head-of-line Blocking . . . . . . . . . . . . . . . . . . 7 61 4. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. CONNECT Method Augmentation . . . . . . . . . . . . . . . 8 63 4.2. UDPASSOCIATE with HINT Frames for HTTP/2 and HTTP/QUIC . 8 64 4.3. HELIUM over WebSockets for all HTTP Versions . . . . . . 8 65 4.4. HELIUM over WebSockets for HTTP/1.1, Native Framing for 66 HTTP/2 or HTTP/QUIC . . . . . . . . . . . . . . . . . . . 8 67 5. Technical Specification for HiNT Requests . . . . . . . . . . 9 68 5.1. The UDPASSOCIATE Method for HTTP/1.1x . . . . . . . . . . 9 69 5.2. The UDPASSOCIATE Method for HTTP/2 and HTTP/QUIC . . . . 10 70 5.3. The IPASSOCIATE Method . . . . . . . . . . . . . . . . . 11 71 6. Technical Specification for HiNT Message Transfer . . . . . . 11 72 6.1. HiNT Message Framing . . . . . . . . . . . . . . . . . . 11 73 6.1.1. The HINT HTTP/2 Frame . . . . . . . . . . . . . . . . 12 74 6.1.2. The HINT HTTP/QUIC Frame . . . . . . . . . . . . . . 13 75 6.2. Light HIP HTTP/2 Framing . . . . . . . . . . . . . . . . 13 76 6.3. Full HIP HTTP/2 Framing . . . . . . . . . . . . . . . . . 14 77 6.3.1. The OHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 15 78 6.3.2. The IHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 16 79 6.3.3. The MHIP HTTP/2 Frame . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 8.1. UDPASSOCIATE Method Registration . . . . . . . . . . . . 20 83 8.2. IPASSOCIATE Method Registration . . . . . . . . . . . . . 20 84 8.3. The HINT HTTP/2 Frame Type . . . . . . . . . . . . . . . 20 85 8.4. The HINT HTTP/QUIC Frame Type . . . . . . . . . . . . . . 20 86 8.5. The HIP HTTP/2 Frame Type . . . . . . . . . . . . . . . . 21 87 8.6. The OHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 21 88 8.7. The IHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 21 89 8.8. The MHIP HTTP/2 Frame Type . . . . . . . . . . . . . . . 21 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 9.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 94 Appendix B. HiNT Request Options . . . . . . . . . . . . . . . . 24 95 Appendix C. HiNT Message Transfer Options . . . . . . . . . . . 25 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 98 1. Introduction 100 A wide range of network tunnelling solutions already exist (e.g. 101 SOCKS [RFC1928], TURN [RFC5766] etc.), with various applicability. 102 So why consider creating another one? Several tunnelling 103 specifications reserve well known TCP or UDP ports that are easy to 104 block. Even if port usage is more agile, plain text communications 105 allow potential attackers to easily analyse traffic and cause 106 interference. 108 This document we consider options for HTTP-initiated Network 109 Tunnelling (HiNT) as a solution. The use case is a client behind a 110 forward proxy but other uses may be supported. Using HTTP as a 111 substrate for other protocols follows a trend seen elsewhere (DNS 112 Queries over HTTPS [DOH]). Shifting to an HTTP port, makes port 113 blocking less effective. However, the real advantage comes from 114 securing HTTP (TLS [RFC5246], QUIC [QUIC-TRANSPORT]) to provide 115 confidentiality, integrity and authenticity, which makes analysis and 116 interference harder. This also enables secure communication to a 117 remote proxy on the Internet (in contrast to SOCKS etc.). 119 A HiNT session is initiated by some HTTP mechanism. This could be a 120 HTTP request or some binary frame format (HTTP/2 and HTTP/QUIC only). 122 Client Forward Proxy Server 123 + + + 124 | +------------------------------------+ | | 125 | | TCP Connection | | | 126 | | | | | 127 | | CONNECT example.org | | | 128 +=========================================>| | 129 | | 200 OK | | +-----------------+ | 130 |<=========================================+ | TCP Connection | | 131 | | | | | | | 132 | | +------------------------------------------------------+ | | 133 | | | TLS Session | | | | | | 134 | | | | | | | | | 135 | | | GET /foo | | | | | | 136 +=================================================================>| 137 | | | 200 OK | | | | | | 138 |<=================================================================+ 139 | | | | | | | | | 140 | | +------------------------------------------------------+ | | 141 | | | | | | | 142 | +------------------------------------+ | +-----------------+ | 143 + + + 145 Figure 1: HTTP/1.1 CONNECT-based TLS tunnel 147 The CONNECT request method (see Section 4.3.6 of [RFC7231]) is 148 commonly used to establish a tunnelled TLS session with an origin 149 identified by a request-target. In HTTP/1.1, the entire client-to- 150 proxy HTTP connection is converted into a tunnel (Figure 1). In 151 HTTP/2 (see Section 8.3 of [RFC7540]) and HTTP/QUIC (see 152 Section 3.1.2 of [QUIC-HTTP]), a single stream gets dedicated to a 153 tunnel (Figure 2). 155 Client Forward Proxy Server 156 + + + 157 | +------------------------------------+ | | 158 | | TCP Connection or UDP Association | | | 159 | | +------------------------------+ | | | 160 | | | TLS or QUIC Security Context | | | | 161 | | | +------------------------+ | | | | 162 | | | | HTTP/2 or HTTP/QUIC | | | | | 163 | | | | Stream | | | | | 164 | | | | | | | | | 165 | | | | CONNECT example.org | | | | | 166 +=========================================>| | 167 | | | | 200 OK | | | | +-----------------+ | 168 |<=========================================+ | TCP Connection | | 169 | | | | | | | | | | | 170 | | | | +------------------------------------------------+ | | 171 | | | | | TLS Session | | | | | | | | 172 | | | | | +------------------------------------------+ | | | 173 | | | | | | HTTP/2 Stream | | | | | | | | | 174 | | | | | | | | | | | | | | | 175 | | | | | | GET /foo | | | | | | | | | 176 +=================================================================>| 177 | | | | | | 200 OK | | | | | | | | | 178 |<=================================================================+ 179 | | | | | | | | | | | | | | | 180 | | | | | +------------------------------------------+ | | | 181 | | | | | | | | | | | | | 182 | | | | +------------------------------------------------+ | | 183 | | | | | | | | | | | 184 | | | +------------------------+ | | | | | | 185 | | | | | | | | | 186 | | +------------------------------+ | | | | | 187 | | | | | | | 188 | +------------------------------------+ | +-----------------+ | 189 + + + 191 Figure 2: HTTP/2 and HTTP/QUIC CONNECT-based TLS tunnel 193 A proxy that supports CONNECT blindly forwards packets, in both 194 directions, using TCP for both client-to-proxy and proxy-to-origin 195 hops. The use of TCP for the latter hop is a limiting factor: other 196 application or transport protocols are unsupported. This document 197 specifically concerns itself with finding a solution that permits a 198 UDP-based HTTP/QUIC client behind an HTTP proxy to establish an HTTP/ 199 QUIC session with the origin. Without such a capability, there 200 continues to be a dependency on origins to support TCP-based HTTP 201 (for a small subset of the client population). 203 The document is arranged in the following order: 205 o Design aspects are considered in Section 3. 207 o Tunnel initiation options are surveyed in Appendix B. 209 o Messaging (post-handshake data transfer) options are surveyed in 210 Appendix C. 212 o Four candidate solutions are presented in Section 4, based on the 213 above options. 215 Candidate solutions have the purpose of stimulating discussion in the 216 community in order to drive toward a single solution. 218 2. Notational Conventions 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in BCP 223 14 [RFC2119] [RFC8174] when, and only when, they appear in all 224 capitals, as shown here. 226 2.1. Definitions 228 Definitions of terms that are used in this document: 230 o HiNT request: a message that requests the establishment of a 231 network tunnel to a HiNT destination. 233 o HiNT response: a message that confirms the establishment of a 234 network tunnel. 236 o HiNT message: a message that allows data transfer between client, 237 proxy and/or destination during a HiNT session. 239 o HiNT client: an HTTP endpoint that sends a HiNT request to a HiNT 240 proxy. Also referred to as a client. 242 o HiNT proxy: an HTTP endpoint that services HiNT requests. It 243 returns a HiNT response that indicates the outcome of network 244 tunnel creation. Also referred to as a proxy. 246 o HiNT destination: the service that the HiNT client is trying to 247 reach via a HiNT proxy. Also referred to as a destination. 249 o HiNT session: a specific instance of a network tunnel. 251 o Network Tunnel: describes any forms of association between client 252 and destination (end-to-end). A tunnel ceases to exist when both 253 ends of the association are closed (implicitly or explicitly). 255 3. Design Consideration Aspects 257 3.1. HTTP Version 259 The design should consider if all HTTP Versions need be supported. 260 Differences in version syntax (in particular binary framing and 261 streams) may provide certain design advantages. 263 3.2. HTTP Forward Proxying 265 The design considers the "forward proxying" intermediary (see 266 Section 2.3 of [RFC7230]) model, which is widely deployed. 268 HTTP clients may use a range of methods to discover the presence of 269 an HTTP proxy (WPAD, DHCP, manual configuration). Client 270 application-layer communications remain unaware of such 271 configuration. (In other words, handshake and data transfer 272 interactions with the HTTP proxy are invisible to the application 273 layer.) 275 Intermediaries may themselves have an HTTP proxy configured. A 276 client attempting to initiate a tunnel to a remote host may end up 277 traversing a proxy chain. This is a useful design characteristic and 278 should be considered when selecting a preferred option. 280 3.3. Message Destination Agility 282 The CONNECT method currently expresses a request-target. This is a 283 "fixed destination mode" where all messages travel on the same fixed 284 TCP path to the same destination (ignoring lower level network 285 elements). 287 The design should consider if more agile approach i.e. a "per-message 288 destination mode" would support new network interaction models. This 289 may add per-message overhead but optimisation may be possible. 291 3.4. Path MTU Discovery 293 The design should consider that endpoints may want/be required to 294 avoid IP fragmentation. Support for reasonable attempts at path MTU 295 discovery (PMTUD) should be included. Traditional PMTUD methods 296 (such as those described in [RFC1191] and [RFC8201] are intended for 297 TCP and rely on ICMP and ICMPv6 messages. [RFC2293] catalogs some of 298 the problems with PMTUD. Packetization Layer PMTUD (PLPMTUD) 299 [RFC4821] is an extension that describes an algorithm that can 300 operate at the transport layer. Datagram PLPMTUD [DPLPMTUD] is a 301 proposed further extension that describes approaches for various UDP- 302 based transports. 304 3.5. Blind forwarding vs. in-the-loop Processing 306 [RFC7230] describes a tunnel as "a blind relay between two 307 connections without changing messages". This approach may be overly 308 restrictive for new interaction modes. 310 In the case of CONNECT for TCP-based tunnelling, the HiNT message 311 sent by a client (TCP/IP packet payload) is decapsulated at the proxy 312 and recapsulated in a new TCP/IP packet created and sent by the 313 proxy. The proxy performs no processing of the HiNT message. 315 [HELIUM] proposes an alternative model, where the proxy does (and is 316 expected to) modify HiNT messages. 318 3.6. Head-of-line Blocking 320 The current design of CONNECT-based tunnelling reserves either a 321 whole TCP connection (HTTP/1.1) or an ordered byte stream (HTTP/2 and 322 HTTP/QUIC) for the client-to-proxy hop. These are subject to head- 323 of-line (HoL) blocking. For example, where there is an end-to-end 324 tunnelled HTTP/2 connection, all of its streams are subject to the 325 blocking on the single reserved stream. It is unknown to the author 326 is this is perceived to be a high impact problem. 328 This document defines HTTP/2 and HTTP/QUIC frames (Section 6) that 329 are sent on HTTP/2 or QUIC streams respecitvely. 331 For UDP or IP-based tunnels, HoL blocking may be problematic. It is 332 unlikely that the application expects blocking to occur, leading to 333 potential issues. (QUIC is specifically designed to avoid HoL 334 blocking and is designed to operate on unreliable UDP, a reliable 335 bearer may adversely affect performance.) 337 Future versions of QUIC may offer partial reliability. If it were 338 used for the client-to-proxy hop, it could help mitigate HoL blocking 339 The design should consider the tension between the benefits of 340 tunnelling, impact of HoL, and HTTP version Section 3.1. 342 4. Candidate Solutions 344 Strawman candidate solutions are presented in order of increasing 345 perceived complexity. It is hoped that wider input will help shape 346 the solution. 348 4.1. CONNECT Method Augmentation 350 Enhance or augment the current definitions of the CONNECT method in 351 HTTP/1.x, HTTP/2 and HTTP/QUIC. Data exchanges between a client and 352 a single destination will be conveyed over existing byte streams with 353 no additional framing. Client and proxy are required to assign 354 meaning to groups of bytes delivered on the stream, which may be 355 impractical. 357 4.2. UDPASSOCIATE with HINT Frames for HTTP/2 and HTTP/QUIC 359 Define a new method, UDPASSOCIATE (Section 5.1), that reserves a 360 stream for the carriage of newly defined HINT frames (Section 6.1). 361 Data exchanges between a client and a single destination will be 362 conveyed using these frames. This requires HTTP/2 or HTTP/QUIC 363 proxies, and precludes HTTP/1.x (because there is no means for 364 framing HiNT messages). 366 4.3. HELIUM over WebSockets for all HTTP Versions 368 Tunnelling of UDP or IP using HELIUM ([HELIUM]) over WebSockets. 369 Data exchanges between a client and destination(s) will be conveyed 370 using CBOR-encoded HIP messages. WebSockets connections between 371 client and proxy are established by existing means. This option 372 would work for all HTTP versions that support WebSockets. 374 4.4. HELIUM over WebSockets for HTTP/1.1, Native Framing for HTTP/2 or 375 HTTP/QUIC 377 Tunnelling of UDP or IP using HELIUM ([HELIUM]). Data exchanges 378 between a client and destination(s) will be conveyed using HIP 379 messages appropriate for the HTTP version. 381 For HTTP/1.x, WebSockets with CBOR-encoded HIP messages would be 382 used. 384 For HTTP/2 and HTTP/QUIC, HIP messages would be framed and exchanged 385 on a stream reserved by the new method, IPASSOCIATE (Section 5.3). 387 There are two framing options presented: light framing (Section 6.2) 388 that uses the CBOR-encoded format, which would allow direct reuse of 389 code to that used for the above WebSocket substrate; full framing 390 (Section 6.3) that uses the native features of the application layer 391 substrate, which may have advantages. 393 5. Technical Specification for HiNT Requests 395 This section outlines the technical specifications required to 396 support the candidate solutions. Discussion of respective merits and 397 drawbacks is captured in Appendix B. 399 5.1. The UDPASSOCIATE Method for HTTP/1.1x 401 In HTTP/1.x, the UDPASSOCIATE method requests that the recipient 402 establish a UDP-based tunnel to the destination origin server 403 identified by the request-target and, if successful, thereafter 404 restrict its behavior to blind forwarding of UDP datagram payloads, 405 in both directions, until the tunnel is closed. 407 UDPASSOCIATE is intended only for use in requests to a proxy. An 408 origin server that receives a UDPASSOCIATE request for itself MAY 409 respond with a 2xx (Successful) status code to indicate that a 410 connection is established. TODO: explicitly ban this? 412 A client sending a UDPASSOCIATE request MUST send the authority form 413 of request-target (Section 5.3 of [RFC7230]); i.e., the request- 414 target consists of only the host name and port number of the tunnel 415 destination, separated by a colon. The port number is for UDP only. 417 UDPASSOCIATE hq.example.com:50781 HTTP/1.1 418 Host: hq.example.com:50781 420 The recipient proxy can establish a tunnel either by directly 421 connecting to the request-target or, if configured to use another 422 proxy, by forwarding the UDPASSOCIATE request to the next inbound 423 proxy. Any 2xx (Successful) response indicates that the sender (and 424 all inbound proxies) will switch to tunnel mode immediately after the 425 blank line that concludes the successful response's header section; 426 data received after that blank line is from the server identified by 427 the request-target. Any response other than a successful response 428 indicates that the tunnel has not yet been formed and that the 429 connection remains governed by HTTP. 431 TODO: how do connectionless UDP associations affirm that connection 432 to the remote host succeeded? Perhaps a 2xx should be formed when 433 the proxy believes it has sufficient capability to send or receive 434 packets. 436 A tunnel is closed when an intermediary detects that either side has 437 closed its connection (explicitly or implicitly). The intermediary 438 MUST attempt to send any outstanding data that came from the closed 439 side to the other side, close both connections, and then discard any 440 remaining data left undelivered. 442 A server MUST NOT send any Transfer-Encoding or Content-Length header 443 fields in a 2xx (Successful) response to UDPASSOCIATE. A client MUST 444 ignore any Content-Length or Transfer-Encoding header fields received 445 in a successful response to UDPASSOCIATE. 447 A payload within a UDPASSOCIATE request message has no defined 448 semantics. 450 5.2. The UDPASSOCIATE Method for HTTP/2 and HTTP/QUIC 452 In HTTP/2 and HTTP/QUIC, the UDPASSOCIATE method requests the 453 establishment of a tunnel to a single remote host over a single 454 stream. This mechanism has a few differences from the header field 455 mapping described in [RFC7540], Section 8.1.2.3: 457 o The ":method" pseudo-header field is set to "UDPASSOCIATE" 459 o The ":scheme" and ":path" pseudo-header fields MUST be omitted 461 o The ":authority" pseudo-header field contains the host and port to 462 connect to (equivalent to the authority-form of the request-target 463 of CONNECT requests (see [RFC7230], Section 5.3)). 465 A UDPASSOCIATE method that does not conform to these restrictions is 466 malformed ([RFC7540], Section 8.1.2.6). 468 A proxy that supports UDPASSOCIATE can establish a tunnel to the 469 server identified in the ":authority" pseudo-header field. Once this 470 is completed (see earlier TODO), the proxy sends a HEADERS frame 471 containing a 2xx series status code to the client. 473 A successful UDPASSOCIATE request reserves the request stream for 474 tunnelling. After the initial HEADERS frame sent by each peer, all 475 subsequent frames exchanged on this stream correspond to data sent on 476 the UDP association. Section 6.1, Section 6.2 and Section 6.3 477 explore options for application-level framing and the mapping to UDP. 478 Some frame types MUST NOT be sent on the reserved stream (e.g. 479 RST_STREAM and more TBD). An endpoint that receives any of these 480 MUST respond with a connection error. 482 The UDP association can be closed (explicitly or implicitly) by 483 either peer. It is RECOMMENDED that peers close the association 484 explicitly using tunnelled application-level means (if possible). 485 Once this has happened, the client SHOULD close the reserved stream 486 on the client-to-proxy hop. Closing the reserved stream before an 487 explicit close is likely to trigger an application-level implicit 488 close (i.e. idle timeout). 490 5.3. The IPASSOCIATE Method 492 The IPASSOCIATE method can be used by a client to request that the 493 recipient establish an IP-based tunnel to the destination origin 494 server identified by the request-target and, if successful, 495 thereafter restrict its behaviour to blind forwarding of IP payloads, 496 in both direction, until the tunnel is closed. 498 The IPASSOCIATE method would look and behave much like the 499 UDPASSOCIATE method. 501 TODO: expand this definition if this method is preferred or required. 502 Additional parameters may be required to accommodate the extra 503 capabilities of IP-based tunnels. 505 6. Technical Specification for HiNT Message Transfer 507 This section outlines the technical specifications required to 508 support the candidate solutions. Discussion of respective merits and 509 drawbacks is captured in Appendix C. 511 6.1. HiNT Message Framing 513 The HINT frame carries HiNT messages between client and proxy. Is 514 intended to be used with versions of HTTP that support binary 515 framing. Definitions are provided for HTTP/2 and HTTP/QUIC, 516 differing only in their use of padding. (The QUIC transport 517 ([QUIC-TRANSPORT]) provides padding itself.) Frames are non-critical 518 extensions to their respective protocols. Endpoints that do not 519 support these frames will ignore them. 521 The payload of each HINT frame corresponds to a UDP datagram (or IP 522 Packet?) sent or received by a HiNT proxy. A separate HiNT request 523 is REQUIRED in order to initiate the tunnel with which these frames 524 relate. 526 HINT frames are subject to flow control. The size of HINT frames 527 should take into consideration the path MTU. Methods for path MTU 528 discovery are discussed in Section 3.4. 530 Frames MUST be associated with a non-control stream. If a frame is 531 received on a control stream, the recipient MUST respond with a 532 connection error. For HTTP/2 this is PROTOCOL_ERROR, for HTTP/QUIC 533 this is TBD. 535 6.1.1. The HINT HTTP/2 Frame 537 The HINT HTTP/2 frame (type=0xTBD) defines the following flags (based 538 on HTTP/2 flags): 540 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 541 last that the endpoint will send for the identified stream. 542 Setting this flag causes the stream to enter one of the "half- 543 closed" states or the "closed" state ([RFC7540], Section 5.1). 545 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 546 and any padding that it describes are present. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |Pad Length? (8)| Payload (*) ... 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Padding (*) ... 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 3: HINT HTTP/2 frame payload 558 The HINT HTTP/2 frame payload has the following fields: 560 Pad Length: An OPTIONAL 8-bit field containing the length of the 561 frame padding in units of octets. This field is only present if 562 the PADDED flag is set. 564 Payload: Arbitrary octets that correspond to messages sent to/from a 565 HiNT proxy. 567 Padding: Padding octets that contain no application semantic value. 568 Padding octets MUST be set to zero when sending. A receiver is 569 not obligated to verify padding but MAY treat non-zero padding as 570 a connection error ([RFC7540], Section 5.4.1) of type 571 PROTOCOL_ERROR. 573 HINT HTTP/2 frames are subject to flow control ([RFC7540], 574 Section 5.2) and can only be sent when a stream is in the "open" or 575 "half-closed (remote)" state. If an HINT HTTP/2 frame is received 576 whose stream is not in "open" or "half-closed (local)" state, the 577 recipient MUST respond with a stream error ([RFC7540] Section 5.4.2) 578 of type STREAM_CLOSED. 580 The HINT HTTP/2 frame is processed hop-by-hop. An intermediary MUST 581 NOT forward HINT HTTP/2 frames, though it can use the information 582 contained in HINT HTTP/2 frames in forming new HINT HTTP/2 frames to 583 send to its own proxy. 585 6.1.2. The HINT HTTP/QUIC Frame 587 The HINT HTTP/QUIC frame (type=0xTBD) defines no flags. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Payload (*) ... 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 4: HINT HTTP/QUIC frame payload 597 The HINT HTTP/QUIC frame carries arbitrary octets that correspond to 598 messages sent to/from a HiNT proxy. The payload MUST be non-zero- 599 length. If a HINT HTTP/QUIC frame is received with with a payload 600 length of zero, the recipient MUST respond with a stream error 601 ([QUIC-HTTP], Section 6) of type TBD. 603 The HINT HTTP/QUIC frame is processed hop-by-hop. An intermediary 604 MUST NOT forward HINT HTTP/QUIC frames, though it can use the 605 information contained in HINT HTTP/QUIC frames in forming new HINT 606 HTTP/QUIC frames to send to its own proxy. 608 6.2. Light HIP HTTP/2 Framing 610 The HELIUM inner protocol (HIP) [HELIUM] defines an abstract message 611 structure that may be carried on a variety of substrates. 613 The HIP HTTP/2 frame (type=0xTBD) carries CBOR-encoded HIP message. 614 The message type is indicated in a frame field. 616 The frame is a non-critical extension. Endpoints that do not support 617 it will ignore it. 619 The size of frame should take into consideration the path MTU. 620 Methods for path MTU discovery are discussed in Section 3.4. 622 Frames MUST be associated with a non-control stream. If a frame is 623 received on a control stream, the recipient MUST respond with a 624 connection error. For HTTP/2 this is PROTOCOL_ERROR. 626 The HIP HTTP/2 frame defines the following flags: 628 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 629 last that the endpoint will send for the identified stream. 630 Setting this flag causes the stream to enter one of the "half- 631 closed" states or the "closed" state ([RFC7540], Section 5.1). 633 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 634 and any padding that it describes are present. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Pad Length? (8)| Type (8) | HIP-CBOR Message (*) ... 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Padding (*) ... 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 5: HIP HTTP/2 frame payload 646 The HIP HTTP/2 frame payload has the following fields: 648 Pad Length: An OPTIONAL 8-bit field containing the length of the 649 frame padding in units of octets. This field is only present if 650 the PADDED flag is set. 652 Type: An 8-bit field that identifies the HIP message type as defined 653 in [HELIUM]. 655 HIP-CBOR Message: A HIP message expressed in CBOR encoding including 656 type, metadata (including padding), and packet or packet-prefix. 658 Padding: Padding octets that contain no application semantic value. 659 Padding octets MUST be set to zero when sending. A receiver is 660 not obligated to verify padding but MAY treat non-zero padding as 661 a connection error ([RFC7540], Section 5.4.1) of type 662 PROTOCOL_ERROR. 664 6.3. Full HIP HTTP/2 Framing 666 The OHIP, IHIP and MHIP frames (collectively xHIP) encode all HIP 667 message data directly in the HTTP/2 frame structure. 669 These frames are non-critical extensions, endpoints that do not 670 support them will ignore them. 672 The size of these frames should take into consideration the path MTU. 673 Methods for path MTU discovery are discussed in Section 3.4.2. 675 Frames MUST be associated with a non-control stream. If a frame is 676 received on a control stream, the recipient MUST respond with a 677 connection error. For HTTP/2 this is PROTOCOL_ERROR. 679 Each xHIP frame type contains zero or more instances of the Metadata- 680 entry field. Fields are processed by the HIP application layer. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Metadata-entry (*) ... 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 A Metadata-entry field is a tuple consisting of a Key and a length- 689 delimited Value: 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Key (16) | Value Length (32) ... 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 ... | Value? ... 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Specifically: 701 Key: An unsigned, 16-bit integer representing the HIP metadata key. 703 Value Length: An unsigned, 16-bit integer indicating the length, in 704 octets of the Value field. 706 Value: An OPTIONAL sequence of octets containing an application- 707 specific value. 709 6.3.1. The OHIP HTTP/2 Frame 711 The OHIP HTTP/2 frame (type=0xTBD) carries an "outbound" HIP message. 713 The OHIP HTTP/2 frame defines the following flags: 715 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 716 last that the endpoint will send for the identified stream. 717 Setting this flag causes the stream to enter one of the "half- 718 closed" states or the "closed" state ([RFC7540], Section 5.1). 720 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 721 field and metadata that is describes are present 723 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 724 and any padding that it describes are present. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 |Pad Length? (8)| Metadata Entries? (16) | ... 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Metadata (*) ... 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Payload (*) ... 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Padding (*) ... 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 6: OHIP HTTP/2 frame payload 740 The OHIP HTTP/2 frame payload has the following fields: 742 Pad Length: An OPTIONAL 8-bit field containing the length of the 743 frame padding in units of octets. This field is only present if 744 the PADDED flag is set. 746 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 747 of Metadata-entries held in the Metadata field. This field is 748 only present if the METADATA flag is set. 750 Metadata: Zero or more instances of the Metadata-entry field. 752 Payload: At most one packet (or prefix of a packet), in essence, a 753 standard IP packet starting with an IP header. 755 Padding: Padding octets that contain no application semantic value. 756 Padding octets MUST be set to zero when sending. A receiver is 757 not obligated to verify padding but MAY treat non-zero padding as 758 a connection error ([RFC7540], Section 5.4.1) of type 759 PROTOCOL_ERROR. 761 6.3.2. The IHIP HTTP/2 Frame 763 The IHIP HTTP/2 frame (type=0xTBD) carries an "inbound" HIP message. 765 The IHIP HTTP/2 frame defines the following flags: 767 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 768 last that the endpoint will send for the identified stream. 769 Setting this flag causes the stream to enter one of the "half- 770 closed" states or the "closed" state ([RFC7540], Section 5.1). 772 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 773 field and metadata that is describes are present 775 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 776 and any padding that it describes are present. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 |Pad Length? (8)| Metadata Entries? (16) | ... 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 ... Metadata (*) ... 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Payload (*) ... 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Padding (*) ... 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 7: IHIP HTTP/2 frame payload 792 The IHIP HTTP/2 frame payload has the following fields: 794 Pad Length: An OPTIONAL 8-bit field containing the length of the 795 frame padding in units of octets. This field is only present if 796 the PADDED flag is set. 798 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 799 of Metadata-entries held in the Metadata field. This field is 800 only present if the METADATA flag is set. 802 Metadata: Zero or more instances of the Metadata-entry field. 804 Payload: A packet, in essence, a standard IP packet starting with an 805 IP header, as received by the proxy. 807 Padding: Padding octets that contain no application semantic value. 808 Padding octets MUST be set to zero when sending. A receiver is 809 not obligated to verify padding but MAY treat non-zero padding as 810 a connection error ([RFC7540], Section 5.4.1) of type 811 PROTOCOL_ERROR. 813 6.3.3. The MHIP HTTP/2 Frame 815 The MHIP HTTP/2 frame (type=0xTBD) carries a "meta" HIP message. 817 The MHIP HTTP/2 frame defines the following flags: 819 END_STREAM (0x1): When set, bit 0 indicates that this frame is the 820 last that the endpoint will send for the identified stream. 821 Setting this flag causes the stream to enter one of the "half- 822 closed" states or the "closed" state ([RFC7540], Section 5.1). 824 METADATA (0x2): When set, bit 1 indicates that the Metadata Entries 825 field and metadata that is describes are present 827 ERROR (0x4): When set, bit 2 indicates that this frame includes an 828 Error-len field. 830 PADDED (0x8): When set, bit 3 indicates that the Pad Length field 831 and any padding that it describes are present. 833 PAYLOAD (0xc): When set, bit 4 indicates that the Payload field is 834 present 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 |Pad Length? (8)| Metadata Entries? (16) |Err Length? (8)| 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Metadata (*) ... 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Errors (*) 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Payload? (*) ... 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Padding (*) ... 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Figure 8: MHIP HTTP/2 frame payload 852 The MHIP HTTP/2 frame payload has the following fields: 854 Pad Length: An OPTIONAL 8-bit field containing the length of the 855 frame padding in units of octets. This field is only present if 856 the PADDED flag is set. 858 Metadata Entries: An OPTIONAL 16-bit field that indicates the number 859 of Metadata-entries held in the Metadata field. This field is 860 only present if the METADATA flag is set. 862 Err Length: An OPTIONAL 8-bit field containing the length of the 863 Errors field. This field is only present if the ERROR flag is 864 set. 866 Metadata: Zero or more instances of the Metadata-entry field. 868 Errors: An OPTIONAL octet array of length Err Length. Each octet of 869 the array represents a HIP error as described in [HELIUM]. 871 Payload: An OPTIONAL payload containing a prefix of the outbound 872 packet as sent, including any parts that were modified. This 873 field is only present if the PAYLOAD flag is set. 875 Padding: Padding octets that contain no application semantic value. 876 Padding octets MUST be set to zero when sending. A receiver is 877 not obligated to verify padding but MAY treat non-zero padding as 878 a connection error ([RFC7540], Section 5.4.1) of type 879 PROTOCOL_ERROR. 881 7. Security Considerations 883 This document is partly motivated by the desire to prevent exposure 884 to observers, to make detection and interference more difficult. The 885 effectiveness of this is dependent on the chosen solution. Where 886 HTTP is used only to bootstrap a HiNT session, messages will be 887 carried without additional HTTP traffic to mask them. A more secure 888 option would be to both bootstrap and carry HiNT messages inside an 889 HTTP session. This of course relies on secure HTTP to provide 890 confidentiality. 892 It is noted that different HiNT traffic may have different 893 characteristics (e.g. volumes and timing) when compared to the HTTP 894 context that it is operating in. Session level encryption is weak 895 with respect to traffic analysis. HTTP/2 provides further advice 896 about the use of compression ([RFC7540] Section 10.6) and padding 897 ([RFC7540] Section 10.7) to mitigate the ability for an observer to 898 discriminate different forms of traffic. Additional application- 899 layer padding may help. 901 TODO: Proxy authentication might be used to establish the authority 902 to create a tunnel. 904 There are significant risks in establishing a tunnel to arbitrary 905 servers. Proxies that support HiNT requests SHOULD restrict a HiNT 906 session to a limited set of known ports or a configurable white list 907 of safe request targets. 909 This section will address more security considerations once a single 910 solution is chosen. 912 8. IANA Considerations 914 8.1. UDPASSOCIATE Method Registration 916 This section registers the "UDPASSOCIATE" method in "HTTP Method 917 Registry" ([RFC7230], Section 8.1). 919 Method Name: UDPASSOCIATE 921 Safe: No 923 Idempotent: No 925 Cacheable: No 927 Specification document(s): Section 5.1 of this document 929 8.2. IPASSOCIATE Method Registration 931 This section registers the "IPASSOCIATE" method in "HTTP Method 932 Registry" ([RFC7230], Section 8.1). 934 Method Name: IPASSOCIATE 936 Safe: No 938 Idempotent: No 940 Cacheable: No 942 Specification document(s): Section 5.3 of this document 944 8.3. The HINT HTTP/2 Frame Type 946 This section registers the "HINT" frame type in the "HTTP/2 Frame 947 Type" registry ([RFC7540], Section 11.2). 949 Frame Type: HINT 951 Code: 0XTBD 953 Specification: Section 6.1.1 of this document 955 8.4. The HINT HTTP/QUIC Frame Type 957 This section registers the "HINT" frame type in the "HTTP/QUIC Frame 958 Type" registry ([QUIC-HTTP], Section 9.3). 960 Frame Type: HINT 962 Code: 0XTBD 964 Specification: Section 6.1.2 of this document 966 8.5. The HIP HTTP/2 Frame Type 968 This section registers the "HIP" frame type in the "HTTP/2 Frame 969 Type" registry ([RFC7540], Section 11.2). 971 Frame Type: HIP 973 Code: 0XTBD 975 Specification: Section 6.2 of this document 977 8.6. The OHIP HTTP/2 Frame Type 979 This section registers the "OHIP" frame type in the "HTTP/2 Frame 980 Type" registry ([RFC7540], Section 11.2). 982 Frame Type: OHIP 984 Code: 0XTBD 986 Specification: Section 6.3.1 of this document 988 8.7. The IHIP HTTP/2 Frame Type 990 This section registers the "IHIP" frame type in the "HTTP/2 Frame 991 Type" registry ([RFC7540], Section 11.2). 993 Frame Type: IHIP 995 Code: 0XTBD 997 Specification: Section 6.3.2 of this document 999 8.8. The MHIP HTTP/2 Frame Type 1001 This section registers the "MHIP" frame type in the "HTTP/2 Frame 1002 Type" registry ([RFC7540], Section 11.2). 1004 Frame Type: MHIP 1006 Code: 0XTBD 1007 Specification: Section 6.3.3 of this document 1009 9. References 1011 9.1. Normative References 1013 [HELIUM] Schwartz, B., "Hybrid Encapsulation Layer for IP and UDP 1014 Messages (HELIUM)", draft-schwartz-httpbis-helium-00 (work 1015 in progress). 1017 [QUIC-HTTP] 1018 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1019 QUIC", draft-ietf-quic-http-13 (work in progress). 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, 1023 DOI 10.17487/RFC2119, March 1997, 1024 . 1026 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1027 Protocol (HTTP/1.1): Message Syntax and Routing", 1028 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1029 . 1031 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1032 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1033 DOI 10.17487/RFC7231, June 2014, 1034 . 1036 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1037 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1038 DOI 10.17487/RFC7540, May 2015, 1039 . 1041 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1042 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1043 May 2017, . 1045 9.2. Informative References 1047 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 1048 draft-ietf-doh-dns-over-https-10 (work in progress). 1050 [DPLPMTUD] 1051 Ruengeler, I., "Packetization Layer Path MTU Discovery for 1052 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-01 1053 (work in progress). 1055 [H2-WEBSOCKETS] 1056 McManus, P., Ed., "Bootstrapping WebSockets with HTTP/2", 1057 draft-ietf-httpbis-h2-websockets-02 (work in progress). 1059 [QUIC-TRANSPORT] 1060 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1061 Multiplexed and Secure Transport", draft-ietf-quic- 1062 transport-13 (work in progress). 1064 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1065 DOI 10.17487/RFC1191, November 1990, 1066 . 1068 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1069 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1070 DOI 10.17487/RFC1928, March 1996, 1071 . 1073 [RFC2293] Kille, S., "Representing Tables and Subtrees in the X.500 1074 Directory", RFC 2293, DOI 10.17487/RFC2293, March 1998, 1075 . 1077 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1078 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1079 . 1081 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1082 (TLS) Protocol Version 1.2", RFC 5246, 1083 DOI 10.17487/RFC5246, August 2008, 1084 . 1086 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1087 Relays around NAT (TURN): Relay Extensions to Session 1088 Traversal Utilities for NAT (STUN)", RFC 5766, 1089 DOI 10.17487/RFC5766, April 2010, 1090 . 1092 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1093 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1094 DOI 10.17487/RFC8201, July 2017, 1095 . 1097 Appendix A. Acknowledgments 1099 Many aspects of this document were inspired by the existing outputs 1100 of the HTTP Working Group and the wider IETF community. Some aspects 1101 were inspired by Mark Nottingham's previous work on HTTP/2 VPN. 1103 The author would like to thank Richard Bradbury, Katharine Daly, 1104 Piers O'Hanlon, and Ben Schwartz for design input and review of this 1105 document. 1107 Appendix B. HiNT Request Options 1109 The following list presents options for a HiNT request in no 1110 particular order: 1112 1. Enhance the CONNECT method (i.e. request/response headers) that 1113 permits negotiation of the proxy-to-destination transport 1114 protocol. 1116 * Pros: 1118 + Already widely supported for HTTP proxying use case. 1120 + Bootstrapping WebSockets for HTTP/2 [H2-WEBSOCKETS] has 1121 made some headway here. 1123 * Cons: 1125 + Deployability may be unrealistic. New types of tunnelling 1126 behaviour may not meet expectations of extant endpoints. 1128 + CONNECT method extension may not be popular. Need to 1129 consider if this is suited for all HTTP or specific 1130 version. 1132 2. Define a new method (e.g. UDPASSOCIATE Section 5.1) that is 1133 restricted to use UDP for the proxy-to-destination transport 1134 protocol. 1136 * Pros: 1138 + Clear demarcation between the conventional TCP case. 1140 + Well suited for HTTP/QUIC use case. 1142 * Cons: 1144 + Limited applicability (because it is UDP-only?). 1146 3. Define a new method (e.g. IPASSOCIATE) that permits negotiation 1147 of the proxy-to-destination transport protocol. 1149 * Pros: 1151 + Clear demarcation between the conventional TCP case. 1153 + Well suited for HTTP/QUIC use case. 1155 * Cons: 1157 + Too complicated for most needs (?). 1159 4. Define a substrate that is already supported by HTTP proxying 1160 i.e. WebSocket. 1162 * Pros: 1164 + Capable of functioning irrespective of HTTP version. 1166 * Cons: 1168 + Multiple layers requires implementation complexity and adds 1169 data transfer overhead. 1171 5. Define HTTP/2 and HTTP/QUIC means of HiNT request, e.g. a new 1172 frame or setting that is used to reserve a stream (or streams) 1173 for special processing of HiNT messages. 1175 * Pros: 1177 + Avoids coining a new method. 1179 * Cons: 1181 + Excludes HTTP/1.1. 1183 Appendix C. HiNT Message Transfer Options 1185 The following list presents options for framing of messages within a 1186 HiNT session in no particular order: 1188 1. Where CONNECT is used by an HTTP/1.1 client, each TCP/IP packet 1189 on the client-to-proxy hop maps directly to a packet (TCP/IP or 1190 UDP/IP) on the proxy-to-destination hop. 1192 * Pros: 1194 + "Simple" option that requires no new TCP framing 1195 definition. 1197 * Cons: 1199 + Breaks the layering model 1201 + In practice, the endpoints are not likely to be able to do 1202 this. 1204 2. Where CONNECT is used by an HTTP/2 or HTTP/QUIC client, each DATA 1205 frame on the client-to-proxy hop maps directly to a packet (TCP/ 1206 IP or UDP/IP) on the proxy-to-destination hop. 1208 * Pros: 1210 + Simple option that requires no additional framing. 1212 + Client and proxy already handle DATA frames. 1214 * Cons: 1216 + DATA frames are delivered on streams, which are treated as 1217 an ordered byte stream. It may not be possible to treat 1218 them individually. 1220 3. Define framing format that uses a WebSocket substrate. For 1221 example, the HELIUM Inner Protocol [HELIUM]. 1223 * Pros: 1225 + Would be supported in HTTP/1.1, HTTP/2 and HTTP/QUIC 1226 (subject to further work). 1228 * Cons: 1230 + Framing overhead which could be optimised away in HTTP/2 1231 and HTTP/QUIC. 1233 + Requires WebSocket support in endpoints. 1235 + Breaks the layering model(?). 1237 4. Define a new simple HTTP/2 and HTTP/QUIC extension frame for 1238 carriage of HiNT messages. (This would likely be subject to 1239 stream-level flow control). The frame payload would be 1240 encapsulated by the proxy. This approach is reliant on a fixed 1241 destination tunnel Section 3.3. 1243 * Pros: 1245 + Clear separation between stream-based and message-based 1246 tunnels. 1248 + Similar to how endpoints already handle CONNECT today. 1250 * Cons: 1252 + New frame may change the semantic of HTTP/2 and HTTP/QUIC. 1253 Therefore, it may need to be negotiated by a new SETTINGS 1254 parameter. 1256 + Excludes HTTP/1.1 1258 + Dependence on fixed destination tunnel may not support all 1259 desired interaction modes. 1261 5. Define a new HTTP/2 and HTTP/QUIC extension frame(s) for carriage 1262 of HiNT messages. (This would likely be subject to stream-level 1263 flow control). This could express HELIUM Inner Protocol [HELIUM] 1264 messages directly and, by virtue, would support per-message 1265 destination. 1267 * Pros: 1269 + Clear separation between stream-based and message-based 1270 tunnels. 1272 + Reduced overhead compared for HTTP/2 and HTTP/QUIC compared 1273 to carriage over WebSocket substrate. 1275 * Cons: 1277 + New frame may change the semantic of HTTP/2 and HTTP/QUIC. 1278 Therefore, it may need to be negotiated by a new SETTINGS 1279 parameter. 1281 + Some divergence from HTTP/1.1. 1283 + Differs from blind forwarding which is implemented in 1284 CONNECT proxies today. 1286 Author's Address 1288 Lucas Pardue 1289 BBC Research & Development 1291 Email: lucas.pardue@bbc.co.uk