Re: HTTP proposal for UDP proxying: HELIUM

Hi Ben, replies inline.
cheers


On 10/07/2018, 17:21, "Ben Schwartz" <bemasc@google.com<mailto:bemasc@google.com>> wrote:

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

I’m not sure I agree with the statement that the trust to nearby IP routers or NAT gateways is necessarily weak.  In fact, I think I tend to trust it maybe too much with my packets...  And the converse is also true, in the sense that I’m typically one of the few clients sitting at the back of its NAT / forwarding tables, and I’m using WPA2 with a reasonably secure password to authenticate to it.

The major risks I see for a proxy are spam, resource costs, and exploitable bugs.

Yes, I agree, especially if the proxy needs to satisfy the “tightly bounded memory usage.” requirement.  I’m not sure if you want to spell the DoS relay risk explicitly or you count that into the “spam” bucket?

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.

I agree.


·  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.

Oh, I see!  So maybe it’s worth suggesting the use of unsigned int types in HIP-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?

It would, thanks.


·  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?

Yes, this is always trickier than expected.  I think CoAP got that quite right though.  (You might want to have a look at the critical/elective options thing in RFC 7252, which is very efficiently encoded as a binary signal (even/odd) in the codepoint itself.)


·  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.

Sorry, I hadn’t understood that even in UDP mode the whole IP datagram is sent in the outbound message (I incorrectly thought it was just the UDP datagram).  Then you are right, the options will be visible to the proxy in any case.



·  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<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