RE: HTTP proposal for UDP proxying: HELIUM

To follow Ben’s previous email, I have published another draft in the UDP proxying family.

This one takes a broader look at today’s TCP tunnelling that uses the HTTP CONNECT method. It generalises the tunnelling concepts and surveys options that may be suited toward UDP or IP tunnels. Design considerations are captured, and some technical solutions are specced out for illustrative purposes. Four candidate solutions are proposed to help direct discussion, although the matrix of options supports many permutations.

Title:
   HTTP-initiated Network Tunnelling

Abstract:

   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.



https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00


Questions and reviews are welcomed. Ben and I will are scheduled to present our drafts at the HTTPbis session on Tuesday 17 July.

Kind regards
Lucas


From: Ben Schwartz [mailto:bemasc@google.com]
Sent: 25 June 2018 21:44
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: HTTP proposal for UDP proxying: HELIUM

Hello HTTPBIS,

In a thread a few months ago [1], there was call for interest in extending HTTP proxying (e.g. HTTP CONNECT) to support UDP traffic, motivated by the growth of QUIC and WebRTC.  Since then, the people who expressed interest have brainstormed some possible use cases and solutions.  I am emailing to present the first of what I hope will be several drafts that we will present on the topic and discuss at IETF 102.  This draft presents one possible solution enabling HTTP proxying of UDP.

https://www.ietf.org/id/draft-schwartz-httpbis-helium-00.txt


Title:
   Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)
Abstract:
   HELIUM is a protocol that can be used to implement a UDP proxy, a
   VPN, or a hybrid of these.  It is intended to run over a reliable,
   secure substrate transport.  It can serve a variety of use cases, but
   its initial purpose is to enable HTTP proxies to forward non-TCP
   flows.

Questions and reviews much appreciated.

--Ben Schwartz

[1] https://www.ietf.org/mail-archive/web/httpbisa/current/msg30667.html