| httpbis | L. Pardue |
| Internet-Draft | BBC Research & Development |
| Intended status: Informational | July 02, 2018 |
| Expires: January 3, 2019 |
HTTP-initiated Network Tunnelling (HiNT)
draft-pardue-httpbis-http-network-tunnelling-00
The HTTP CONNECT method allows an HTTP client to initiate, via a proxy, a TCP-based tunnel to a single destination origin. This memo explores options for expanding HTTP-initiated Network Tunnelling (HiNT) to cater for diverse UDP and IP associations.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A wide range of network tunnelling solutions already exist (e.g. SOCKS [RFC1928], TURN [RFC5766] etc.), with various applicability. So why consider creating another one? Several tunnelling specifications reserve well known TCP or UDP ports that are easy to block. Even if port usage is more agile, plain text communications allow potential attackers to easily analyse traffic and cause interference.
This document we consider options for HTTP-initiated Network Tunnelling (HiNT) as a solution. The use case is a client behind a forward proxy but other uses may be supported. Using HTTP as a substrate for other protocols follows a trend seen elsewhere (DNS Queries over HTTPS [DOH]). Shifting to an HTTP port, makes port blocking less effective. However, the real advantage comes from securing HTTP (TLS [RFC5246], QUIC [QUIC-TRANSPORT]) to provide confidentiality, integrity and authenticity, which makes analysis and interference harder. This also enables secure communication to a remote proxy on the Internet (in contrast to SOCKS etc.).
A HiNT session is initiated by some HTTP mechanism. This could be a HTTP request or some binary frame format (HTTP/2 and HTTP/QUIC only).
Client Forward Proxy Server + + + | +------------------------------------+ | | | | TCP Connection | | | | | | | | | | CONNECT example.org | | | +=========================================>| | | | 200 OK | | +-----------------+ | |<=========================================+ | TCP Connection | | | | | | | | | | | +------------------------------------------------------+ | | | | | TLS Session | | | | | | | | | | | | | | | | | | GET /foo | | | | | | +=================================================================>| | | | 200 OK | | | | | | |<=================================================================+ | | | | | | | | | | | +------------------------------------------------------+ | | | | | | | | | | +------------------------------------+ | +-----------------+ | + + +
Figure 1: HTTP/1.1 CONNECT-based TLS tunnel
The CONNECT request method (see Section 4.3.6 of [RFC7231]) is commonly used to establish a tunnelled TLS session with an origin identified by a request-target. In HTTP/1.1, the entire client-to-proxy HTTP connection is converted into a tunnel (Figure 1). In HTTP/2 (see Section 8.3 of [RFC7540]) and HTTP/QUIC (see Section 3.1.2 of [QUIC-HTTP]), a single stream gets dedicated to a tunnel (Figure 2).
Client Forward Proxy Server + + + | +------------------------------------+ | | | | TCP Connection or UDP Association | | | | | +------------------------------+ | | | | | | TLS or QUIC Security Context | | | | | | | +------------------------+ | | | | | | | | HTTP/2 or HTTP/QUIC | | | | | | | | | Stream | | | | | | | | | | | | | | | | | | CONNECT example.org | | | | | +=========================================>| | | | | | 200 OK | | | | +-----------------+ | |<=========================================+ | TCP Connection | | | | | | | | | | | | | | | | | +------------------------------------------------+ | | | | | | | TLS Session | | | | | | | | | | | | | +------------------------------------------+ | | | | | | | | | HTTP/2 Stream | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GET /foo | | | | | | | | | +=================================================================>| | | | | | | 200 OK | | | | | | | | | |<=================================================================+ | | | | | | | | | | | | | | | | | | | | +------------------------------------------+ | | | | | | | | | | | | | | | | | | | | +------------------------------------------------+ | | | | | | | | | | | | | | | | +------------------------+ | | | | | | | | | | | | | | | | | +------------------------------+ | | | | | | | | | | | | | +------------------------------------+ | +-----------------+ | + + +
Figure 2: HTTP/2 and HTTP/QUIC CONNECT-based TLS tunnel
A proxy that supports CONNECT blindly forwards packets, in both directions, using TCP for both client-to-proxy and proxy-to-origin hops. The use of TCP for the latter hop is a limiting factor: other application or transport protocols are unsupported. This document specifically concerns itself with finding a solution that permits a UDP-based HTTP/QUIC client behind an HTTP proxy to establish an HTTP/QUIC session with the origin. Without such a capability, there continues to be a dependency on origins to support TCP-based HTTP (for a small subset of the client population).
The document is arranged in the following order:
Candidate solutions have the purpose of stimulating discussion in the community in order to drive toward a single solution.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Definitions of terms that are used in this document:
The design should consider if all HTTP Versions need be supported. Differences in version syntax (in particular binary framing and streams) may provide certain design advantages.
The design considers the “forward proxying” intermediary (see Section 2.3 of [RFC7230]) model, which is widely deployed.
HTTP clients may use a range of methods to discover the presence of an HTTP proxy (WPAD, DHCP, manual configuration). Client application-layer communications remain unaware of such configuration. (In other words, handshake and data transfer interactions with the HTTP proxy are invisible to the application layer.)
Intermediaries may themselves have an HTTP proxy configured. A client attempting to initiate a tunnel to a remote host may end up traversing a proxy chain. This is a useful design characteristic and should be considered when selecting a preferred option.
The CONNECT method currently expresses a request-target. This is a “fixed destination mode” where all messages travel on the same fixed TCP path to the same destination (ignoring lower level network elements).
The design should consider if more agile approach i.e. a “per-message destination mode” would support new network interaction models. This may add per-message overhead but optimisation may be possible.
The design should consider that endpoints may want/be required to avoid IP fragmentation. Support for reasonable attempts at path MTU discovery (PMTUD) should be included. Traditional PMTUD methods (such as those described in [RFC1191] and [RFC8201] are intended for TCP and rely on ICMP and ICMPv6 messages. [RFC2293] catalogs some of the problems with PMTUD. Packetization Layer PMTUD (PLPMTUD) [RFC4821] is an extension that describes an algorithm that can operate at the transport layer. Datagram PLPMTUD [DPLPMTUD] is a proposed further extension that describes approaches for various UDP-based transports.
[RFC7230] describes a tunnel as “a blind relay between two connections without changing messages”. This approach may be overly restrictive for new interaction modes.
In the case of CONNECT for TCP-based tunnelling, the HiNT message sent by a client (TCP/IP packet payload) is decapsulated at the proxy and recapsulated in a new TCP/IP packet created and sent by the proxy. The proxy performs no processing of the HiNT message.
[HELIUM] proposes an alternative model, where the proxy does (and is expected to) modify HiNT messages.
The current design of CONNECT-based tunnelling reserves either a whole TCP connection (HTTP/1.1) or an ordered byte stream (HTTP/2 and HTTP/QUIC) for the client-to-proxy hop. These are subject to head-of-line (HoL) blocking. For example, where there is an end-to-end tunnelled HTTP/2 connection, all of its streams are subject to the blocking on the single reserved stream. It is unknown to the author is this is perceived to be a high impact problem.
This document defines HTTP/2 and HTTP/QUIC frames (Section 6) that are sent on HTTP/2 or QUIC streams respecitvely.
For UDP or IP-based tunnels, HoL blocking may be problematic. It is unlikely that the application expects blocking to occur, leading to potential issues. (QUIC is specifically designed to avoid HoL blocking and is designed to operate on unreliable UDP, a reliable bearer may adversely affect performance.)
Future versions of QUIC may offer partial reliability. If it were used for the client-to-proxy hop, it could help mitigate HoL blocking
The design should consider the tension between the benefits of tunnelling, impact of HoL, and HTTP version Section 3.1.
Strawman candidate solutions are presented in order of increasing perceived complexity. It is hoped that wider input will help shape the solution.
Enhance or augment the current definitions of the CONNECT method in HTTP/1.x, HTTP/2 and HTTP/QUIC. Data exchanges between a client and a single destination will be conveyed over existing byte streams with no additional framing. Client and proxy are required to assign meaning to groups of bytes delivered on the stream, which may be impractical.
Define a new method, UDPASSOCIATE (Section 5.1), that reserves a stream for the carriage of newly defined HINT frames (Section 6.1). Data exchanges between a client and a single destination will be conveyed using these frames. This requires HTTP/2 or HTTP/QUIC proxies, and precludes HTTP/1.x (because there is no means for framing HiNT messages).
Tunnelling of UDP or IP using HELIUM ([HELIUM]) over WebSockets. Data exchanges between a client and destination(s) will be conveyed using CBOR-encoded HIP messages. WebSockets connections between client and proxy are established by existing means. This option would work for all HTTP versions that support WebSockets.
Tunnelling of UDP or IP using HELIUM ([HELIUM]). Data exchanges between a client and destination(s) will be conveyed using HIP messages appropriate for the HTTP version.
For HTTP/1.x, WebSockets with CBOR-encoded HIP messages would be used.
For HTTP/2 and HTTP/QUIC, HIP messages would be framed and exchanged on a stream reserved by the new method, IPASSOCIATE (Section 5.3).
There are two framing options presented: light framing (Section 6.2) that uses the CBOR-encoded format, which would allow direct reuse of code to that used for the above WebSocket substrate; full framing (Section 6.3) that uses the native features of the application layer substrate, which may have advantages.
This section outlines the technical specifications required to support the candidate solutions. Discussion of respective merits and drawbacks is captured in Appendix B.
In HTTP/1.x, the UDPASSOCIATE method requests that the recipient establish a UDP-based tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of UDP datagram payloads, in both directions, until the tunnel is closed.
UDPASSOCIATE is intended only for use in requests to a proxy. An origin server that receives a UDPASSOCIATE request for itself MAY respond with a 2xx (Successful) status code to indicate that a connection is established. TODO: explicitly ban this?
A client sending a UDPASSOCIATE request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. The port number is for UDP only.
UDPASSOCIATE hq.example.com:50781 HTTP/1.1 Host: hq.example.com:50781
The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another proxy, by forwarding the UDPASSOCIATE request to the next inbound proxy. Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that concludes the successful response’s header section; data received after that blank line is from the server identified by the request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains governed by HTTP.
TODO: how do connectionless UDP associations affirm that connection to the remote host succeeded? Perhaps a 2xx should be formed when the proxy believes it has sufficient capability to send or receive packets.
A tunnel is closed when an intermediary detects that either side has closed its connection (explicitly or implicitly). The intermediary MUST attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard any remaining data left undelivered.
A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to UDPASSOCIATE. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to UDPASSOCIATE.
A payload within a UDPASSOCIATE request message has no defined semantics.
In HTTP/2 and HTTP/QUIC, the UDPASSOCIATE method requests the establishment of a tunnel to a single remote host over a single stream. This mechanism has a few differences from the header field mapping described in [RFC7540], Section 8.1.2.3:
A UDPASSOCIATE method that does not conform to these restrictions is malformed ([RFC7540], Section 8.1.2.6).
A proxy that supports UDPASSOCIATE can establish a tunnel to the server identified in the “:authority” pseudo-header field. Once this is completed (see earlier TODO), the proxy sends a HEADERS frame containing a 2xx series status code to the client.
A successful UDPASSOCIATE request reserves the request stream for tunnelling. After the initial HEADERS frame sent by each peer, all subsequent frames exchanged on this stream correspond to data sent on the UDP association. Section 6.1, Section 6.2 and Section 6.3 explore options for application-level framing and the mapping to UDP. Some frame types MUST NOT be sent on the reserved stream (e.g. RST_STREAM and more TBD). An endpoint that receives any of these MUST respond with a connection error.
The UDP association can be closed (explicitly or implicitly) by either peer. It is RECOMMENDED that peers close the association explicitly using tunnelled application-level means (if possible). Once this has happened, the client SHOULD close the reserved stream on the client-to-proxy hop. Closing the reserved stream before an explicit close is likely to trigger an application-level implicit close (i.e. idle timeout).
The IPASSOCIATE method can be used by a client to request that the recipient establish an IP-based tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behaviour to blind forwarding of IP payloads, in both direction, until the tunnel is closed.
The IPASSOCIATE method would look and behave much like the UDPASSOCIATE method.
TODO: expand this definition if this method is preferred or required. Additional parameters may be required to accommodate the extra capabilities of IP-based tunnels.
This section outlines the technical specifications required to support the candidate solutions. Discussion of respective merits and drawbacks is captured in Appendix C.
The HINT frame carries HiNT messages between client and proxy. Is intended to be used with versions of HTTP that support binary framing. Definitions are provided for HTTP/2 and HTTP/QUIC, differing only in their use of padding. (The QUIC transport ([QUIC-TRANSPORT]) provides padding itself.) Frames are non-critical extensions to their respective protocols. Endpoints that do not support these frames will ignore them.
The payload of each HINT frame corresponds to a UDP datagram (or IP Packet?) sent or received by a HiNT proxy. A separate HiNT request is REQUIRED in order to initiate the tunnel with which these frames relate.
HINT frames are subject to flow control. The size of HINT frames should take into consideration the path MTU. Methods for path MTU discovery are discussed in Section 3.4.
Frames MUST be associated with a non-control stream. If a frame is received on a control stream, the recipient MUST respond with a connection error. For HTTP/2 this is PROTOCOL_ERROR, for HTTP/QUIC this is TBD.
The HINT HTTP/2 frame (type=0xTBD) defines the following flags (based on HTTP/2 flags):
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Pad Length? (8)| Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: HINT HTTP/2 frame payload
The HINT HTTP/2 frame payload has the following fields:
HINT HTTP/2 frames are subject to flow control ([RFC7540], Section 5.2) and can only be sent when a stream is in the “open” or “half-closed (remote)” state. If an HINT HTTP/2 frame is received whose stream is not in “open” or “half-closed (local)” state, the recipient MUST respond with a stream error ([RFC7540] Section 5.4.2) of type STREAM_CLOSED.
The HINT HTTP/2 frame is processed hop-by-hop. An intermediary MUST NOT forward HINT HTTP/2 frames, though it can use the information contained in HINT HTTP/2 frames in forming new HINT HTTP/2 frames to send to its own proxy.
The HINT HTTP/QUIC frame (type=0xTBD) defines no flags.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HINT HTTP/QUIC frame payload
The HINT HTTP/QUIC frame carries arbitrary octets that correspond to messages sent to/from a HiNT proxy. The payload MUST be non-zero-length. If a HINT HTTP/QUIC frame is received with with a payload length of zero, the recipient MUST respond with a stream error ([QUIC-HTTP], Section 6) of type TBD.
The HINT HTTP/QUIC frame is processed hop-by-hop. An intermediary MUST NOT forward HINT HTTP/QUIC frames, though it can use the information contained in HINT HTTP/QUIC frames in forming new HINT HTTP/QUIC frames to send to its own proxy.
The HELIUM inner protocol (HIP) [HELIUM] defines an abstract message structure that may be carried on a variety of substrates.
The HIP HTTP/2 frame (type=0xTBD) carries CBOR-encoded HIP message. The message type is indicated in a frame field.
The frame is a non-critical extension. Endpoints that do not support it will ignore it.
The size of frame should take into consideration the path MTU. Methods for path MTU discovery are discussed in Section 3.4.
Frames MUST be associated with a non-control stream. If a frame is received on a control stream, the recipient MUST respond with a connection error. For HTTP/2 this is PROTOCOL_ERROR.
The HIP HTTP/2 frame defines the following flags:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Pad Length? (8)| Type (8) | HIP-CBOR Message (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: HIP HTTP/2 frame payload
The HIP HTTP/2 frame payload has the following fields:
The OHIP, IHIP and MHIP frames (collectively xHIP) encode all HIP message data directly in the HTTP/2 frame structure.
These frames are non-critical extensions, endpoints that do not support them will ignore them.
The size of these frames should take into consideration the path MTU. Methods for path MTU discovery are discussed in Section 3.4.2.
Frames MUST be associated with a non-control stream. If a frame is received on a control stream, the recipient MUST respond with a connection error. For HTTP/2 this is PROTOCOL_ERROR.
Each xHIP frame type contains zero or more instances of the Metadata-entry field. Fields are processed by the HIP application layer.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata-entry (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Metadata-entry field is a tuple consisting of a Key and a length-delimited Value:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (16) | Value Length (32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Value? ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Specifically:
The OHIP HTTP/2 frame (type=0xTBD) carries an “outbound” HIP message.
The OHIP HTTP/2 frame defines the following flags:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Pad Length? (8)| Metadata Entries? (16) | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OHIP HTTP/2 frame payload
The OHIP HTTP/2 frame payload has the following fields:
The IHIP HTTP/2 frame (type=0xTBD) carries an “inbound” HIP message.
The IHIP HTTP/2 frame defines the following flags:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Pad Length? (8)| Metadata Entries? (16) | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Metadata (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IHIP HTTP/2 frame payload
The IHIP HTTP/2 frame payload has the following fields:
The MHIP HTTP/2 frame (type=0xTBD) carries a “meta” HIP message.
The MHIP HTTP/2 frame defines the following flags:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Pad Length? (8)| Metadata Entries? (16) |Err Length? (8)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Errors (*) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload? (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MHIP HTTP/2 frame payload
The MHIP HTTP/2 frame payload has the following fields:
This document is partly motivated by the desire to prevent exposure to observers, to make detection and interference more difficult. The effectiveness of this is dependent on the chosen solution. Where HTTP is used only to bootstrap a HiNT session, messages will be carried without additional HTTP traffic to mask them. A more secure option would be to both bootstrap and carry HiNT messages inside an HTTP session. This of course relies on secure HTTP to provide confidentiality.
It is noted that different HiNT traffic may have different characteristics (e.g. volumes and timing) when compared to the HTTP context that it is operating in. Session level encryption is weak with respect to traffic analysis. HTTP/2 provides further advice about the use of compression ([RFC7540] Section 10.6) and padding ([RFC7540] Section 10.7) to mitigate the ability for an observer to discriminate different forms of traffic. Additional application-layer padding may help.
TODO: Proxy authentication might be used to establish the authority to create a tunnel.
There are significant risks in establishing a tunnel to arbitrary servers. Proxies that support HiNT requests SHOULD restrict a HiNT session to a limited set of known ports or a configurable white list of safe request targets.
This section will address more security considerations once a single solution is chosen.
This section registers the “UDPASSOCIATE” method in “HTTP Method Registry” ([RFC7230], Section 8.1).
Method Name: UDPASSOCIATE
Safe: No
Idempotent: No
Cacheable: No
Specification document(s): Section 5.1 of this document
This section registers the “IPASSOCIATE” method in “HTTP Method Registry” ([RFC7230], Section 8.1).
Method Name: IPASSOCIATE
Safe: No
Idempotent: No
Cacheable: No
Specification document(s): Section 5.3 of this document
This section registers the “HINT” frame type in the “HTTP/2 Frame Type” registry ([RFC7540], Section 11.2).
Frame Type: HINT
Code: 0XTBD
Specification: Section 6.1.1 of this document
This section registers the “HINT” frame type in the “HTTP/QUIC Frame Type” registry ([QUIC-HTTP], Section 9.3).
Frame Type: HINT
Code: 0XTBD
Specification: Section 6.1.2 of this document
This section registers the “HIP” frame type in the “HTTP/2 Frame Type” registry ([RFC7540], Section 11.2).
Frame Type: HIP
Code: 0XTBD
Specification: Section 6.2 of this document
This section registers the “OHIP” frame type in the “HTTP/2 Frame Type” registry ([RFC7540], Section 11.2).
Frame Type: OHIP
Code: 0XTBD
Specification: Section 6.3.1 of this document
This section registers the “IHIP” frame type in the “HTTP/2 Frame Type” registry ([RFC7540], Section 11.2).
Frame Type: IHIP
Code: 0XTBD
Specification: Section 6.3.2 of this document
This section registers the “MHIP” frame type in the “HTTP/2 Frame Type” registry ([RFC7540], Section 11.2).
Frame Type: MHIP
Code: 0XTBD
Specification: Section 6.3.3 of this document
| [HELIUM] | Schwartz, B., "Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)", Internet-Draft draft-schwartz-httpbis-helium-00 |
| [QUIC-HTTP] | Bishop, M., "Hypertext Transfer Protocol (HTTP) over QUIC", Internet-Draft draft-ietf-quic-http-13 |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7230] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014. |
| [RFC7231] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014. |
| [RFC7540] | Belshe, M., Peon, R. and M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
Many aspects of this document were inspired by the existing outputs of the HTTP Working Group and the wider IETF community. Some aspects were inspired by Mark Nottingham’s previous work on HTTP/2 VPN.
The author would like to thank Richard Bradbury, Katharine Daly, Piers O’Hanlon, and Ben Schwartz for design input and review of this document.
The following list presents options for a HiNT request in no particular order:
The following list presents options for framing of messages within a HiNT session in no particular order: