Fwd: HTTP proposal for UDP proxying: HELIUM

On Sun, Jul 8, 2018 at 7:20 PM Fossati, Thomas (Nokia - GB/Cambridge) <
thomas.fossati@nokia.com> wrote:

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

And thank you for your nicely written and very clear comments!


>
>
> 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 :-)
>
> OK, I agree.  I'll plan to add a section on that.

I'm not sure exactly how to describe the trust relationship.  In a sense,
the amount of trust required is very weak, similar to the trust between a
client and a nearby IP router or NAT gateway.  The major risks I see for a
proxy are spam, resource costs, and exploitable bugs.  The major risks I
see for a client are metadata privacy, content privacy (if the content is
not encrypted, which it really should be), and denial of service.


>
>    - 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"?
>
> Section 2.3 is about the abstract "HIP" protocol, which might be encoded
in ways other than CBOR.  For example, Lucas has proposed an  encoding of
HIP in HTTP/2 frames that does not use CBOR.


>
>    - 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?
>
> That's an interesting idea.  We could say:

If an "outbound" message encounters an error that prevented it from being
sent, and does not have an "id", the proxy SHOULD (MAY?) respond with a
"meta" message that also lacks an "id".

Would that work for you?


>
>    - 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.
>
> It seems to me that this is about trying to predict the kinds of options
that we might want in future versions of this protocol, which is always
challenging.  It's not clear to me that we'll need this, but I can see the
appeal.  Maybe we could have the "meta" message include a list of
unrecognized options?


>
>    - 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?
>
> I wasn't aware of the UDP Options draft (
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-04), but that's
actually not a problem.  I think it's sort of a case in point of how the
HELIUM design works.  HELIUM says nothing about UDP Options, and a given
proxy might forward the options successfully, strip them, modify them, or
drop the packet as malformed.  However, the message format is capable of
representing them, and as a client you're always welcome to try to use
them.  The "meta" reply will unambiguously indicate whether it worked, or
how it failed.


>
>    - 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?
>
> Those two behaviors (client and proxy) are valid and allowed, but they're
not required.  Alternatively, the client can choose to use different source
address values for different outbound packets, and the proxy can choose to
map different source addresses to different "network source addresses".
This allows the use of multiple source addresses in a single HELIUM
session.  For example, I could imagine this being useful to a browser that
wants to use a different IPv6 address for each tab or profile.


>
>    - Sec 2.1: "Context: the identity […]",  s/identity/instance/ maybe?
>
> OK.


> Cheers!
>
>
>
> [1] https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-03
>
>
>
>
>
>
>
> On 25/06/2018, 21:47, "Ben Schwartz" <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
>