Subject: [Masque] Initial comments on draft-schinazi-masque-connect-udp-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2020 17:41:15 -0700

Document: draft-schinazi-masque-connect-udp-00.txt

Generally, this looks like a good start and I think is probably
ready for WG adoption. I do have some technical comments.

OVERALL
I'm concerned about the treatment of multiple proxies here. Generally,
having multiple proxies that are invisible to the client seems
confusing, especially when their properties then get upstreamed to the
client. I think a better way to handle this would be to require that
the ingress proxy to handle any necessary translation (e.g., datagram
to stream) and not offer services it cannot somehow translate. I'm
open to being wrong about this, but I'd like to see some rationale
for this design decision.

DETAILED
S 3.
   A client sending a CONNECT-UDP 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.  For example,

        CONNECT-UDP server.example.com:443 HTTP/1.1
        Host: server.example.com:443

Or IP address, right?

   A tunnel is closed when a tunnel intermediary detects that either
   side has closed its connection: 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.

I'm not sure I understand what this text means (for instance, if
I MUST attempt to send unreliable data, what does "undelivered"
mean) but in any case I think it's inadvisable. Implementations
which want delivery should get end-to-end acknowledgements and
close the connection, not trust the proxy to do it for them.

S 4.
   When the HTTP connection between client and proxy supports HTTP/3
   datagrams [H3DGRAM], UDP packets can be encoded using QUIC DATAGRAM
   frames.  This support is ascertained by checking receipt of the
   H3_DATAGRAM SETTINGS Parameter.  Note that when there are multiple
   proxies involved, this support needs to be ascertained on all the
   HTTP connections that will carry proxied UDP packets.

I would actually just require QUIC MASQUE implementations to support
DATAGRAM.

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 18:24:44 -0700

Thanks for the comments, EKR! Responses inline.

David

> for this design decision.

I would say that handling of multiple proxies is still a work-in-progress.
I agree with you that what the draft currently has on this topic isn't fully
fledged. I have a couple slides about it for tomorrow, hopefully they can
clarify things.

>         Host: server.example.com:443

Yes, this text was somewhat copy-pasted from the definition of the
CONNECT method. I think that in this context host name can also
refer to IP literals, though I'm happy to add that if not - I do
want to support IP literals here.

> close the connection, not trust the proxy to do it for them.

Similarly, I think I copy-pasted this without making all the needed edits.
Conceptually, the idea is that whenever the CONNECT-UDP stream is
closed, then the proxy closes all associated resources such as its
ephemeral UDP socket.

S 4.
> I would actually just require QUIC MASQUE implementations to support

That would work for me, though it'll depend on how we want to support the
use-case where there is an HTTP intermediary that forwards the
CONNECT-UDP request. Hopefully my presentation tomorrow clarifies things.