Re: [Masque] Updated version of QUIC-aware proxying using HTTP capsules

[Ben Schwartz <[e-mail]>]

I think there's an idea here that is worth pursuing, but I'm not sure about
this specific approach.

To start with a concrete issue, RFC 9000 says "an endpoint MUST NOT reuse a
connection ID when sending to more than one destination address".  To
preserve user privacy, the client connection ID must change when the
client's IP changes.  However, this draft is based on the idea that the
proxy uses essentially a single target-facing port, with the result that
the target doesn't know when the client's address has changed.

There's also a problem in the handling of Stateless Reset responses, which
generate a random Connection ID.  The proxy will have to drop any Reset
responses, because it does not know which client to forward them to.

The requirement that the QUIC packets to forward land on the same
client-facing port as the HTTP/3 connection also strikes me as unnatural
and possibly inconvenient.  The forwarding service really has nothing to do
with the HTTP/3 transport.  There's no reason to even require HTTP/3; the
forwarding service could just as well be controlled using a session that is
running in HTTP/2.

I believe these problems are consequences of trying to conserve port
numbers on the proxy.  This strikes me as a premature optimization.

I think we should benchmark this design against something closer to a
classic NAT:
- Registration ACKs indicate an explicit client-facing IP and port, which
is distinct from the HTTP endpoint
- Each client-facing port is associated with one tunnel
- Each (target-facing port, target) pair is used for at most one tunnel
- Connections should move to a different target-facing port (and possibly
IP) whenever the client's address (as viewed from the proxy) changes

This would remove the need for juggling of Connection IDs, and allow
application to any UDP payload, not just QUIC.  It would allow use with any
HTTP version, and be unaffected by arbitrary HTTP intermediaries.  It can
even be extended to forward TCP.

The port number would impose some scaling limits, but only on the
assumption that IP addresses are scarce.  In IPv6 this is definitely not
true, and scaling seems likely to be manageable even in IPv4, as evidenced
by the successful operation of large-scale TURN servers for WebRTC.

On Tue, Oct 12, 2021 at 2:42 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

> Hi all,
>
> David and I recently revised the QUIC-aware proxying draft (which adds the
> ability to share sockets and perform forwarding on top of CONNECT-UDP).
>
> This new revision aligns with the latest CONNECT-UDP and HTTP datagram
> drafts by adopting capsules and using CONNECT-UDP’s extended CONNECT method.
>
> We ended up not needing to use any context IDs (as defined in HTTP
> datagrams), but instead are just using some new capsule messages to add
> control signaling between the client and the proxy. Hopefully, this informs
> some of our broader discussion about how the extensibility provided by HTTP
> datagrams can be used, and which parts are most useful.
>
> Best,
> Tommy
>
> Begin forwarded message:
>
> *From: *[e-mail]
> *Subject: **New Version Notification for
> draft-pauly-masque-quic-proxy-02.txt*
> *Date: *October 11, 2021 at 11:04:58 AM PDT
> *To: *David Schinazi <[e-mail]>, Tommy Pauly <
> [e-mail]>
>
>
> A new version of I-D, draft-pauly-masque-quic-proxy-02.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
>
> Name: draft-pauly-masque-quic-proxy
> Revision: 02
> Title: QUIC-Aware Proxying Using HTTP
> Document date: 2021-10-11
> Group: Individual Submission
> Pages: 19
> URL:
> https://www.ietf.org/archive/id/draft-pauly-masque-quic-proxy-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pauly-masque-quic-proxy/
> Html:
> https://www.ietf.org/archive/id/draft-pauly-masque-quic-proxy-02.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pauly-masque-quic-proxy
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-pauly-masque-quic-proxy-02
>
> Abstract:
>   This document defines an extension to UDP Proxying over HTTP that
>   adds specific optimizations for proxied QUIC connections.  This
>   extension allows a proxy to reuse UDP 4-tuples for multiple
>   connections.  It also defines a mode of proxying in which QUIC short
>   header packets can be forwarded using an HTTP/3 proxy rather than
>   being re-encapsulated and re-encrypted.
>
>
>
>
> The IETF Secretariat
>
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>