Re: HTTP proposal for UDP proxying: HELIUM

Hi Ben,

First, thank you for the nicely written and very clear document.

A few comments:


  *   I think this document would enjoy greatly from a discussion on the assumed trust model.  It seems to me it's sort of implied that trust must be mutual for this to work.  But maybe the assumption could be relaxed in some scenario?  The problem is this is not explicitly spelled out, which leaves the reader in a slightly suspended state :-)


  *   Sec 2.3: with regards to metadata of type integer (id, dns, errors, timestamp), not sure why you are not constraining the type to unsigned integer straight away (which CBOR supports) rather than imposing a separate "SHOULD treat negative as errors"?


  *   I think I understand the reasoning behind not sending unsolicited meta message, but there might be a more balanced approach that allows proxy to inform the client about anything dodgy going on without requiring the client to request feedback on each and every packet just in case?  Maybe an explicit "error/warning" message type?


  *   Permission-less extensibility is great, but I’m a bit uncomfortable that sender semantics is silently ignored at the receiver (fourth from last para in Sec. 2.3). The text seems to also imply that in principle there is no guarantee that any metadata key is going to be honoured? I think it'd be nice to have a way to express the fact that a key MUST be understood at the receiver (e.g., give them even, or odd, key indexes) and allow an explicit error to be sent back if needed.  Note that a similar situation arises in the last para of 2.4.


  *   There is no mention about the treatment of UDP options - I'm thinking in particular regarding PLPMTUD [1].  I guess if you want options to work in UDP tunnel mode, they should be conveyed in a new metadata key?


  *   Maybe I'm not understanding correctly, but it seems to me that in 2.5.1 first para you could simply say that the client always clears the src address of the tunnelled packet and the proxy populates it?


  *   Sec 2.1: "Context: the identity […]",  s/identity/instance/ maybe?

Cheers!

[1] https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-03




On 25/06/2018, 21:47, "Ben Schwartz" <bemasc@google.com<mailto:bemasc@google.com>> wrote:

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