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

Hi Ben,

> On Oct 13, 2021, at 6:13 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 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.

I don’t think there’s any violation of that requirement here. The fact that a proxy hides a client’s original IP address, and any changes that might have (due to passive NAT rebinding or active migration) isn’t any different than with all of CONNECT-UDP proxying.
> 
> 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.
> 

Yes, the stateless reset case is an interesting corner case to explore.

> 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 don’t think you’d want these to be different. From a network observer’s point of view, they wouldn’t be able to tell apart traffic bound to the proxy and traffic forwarded on—they’ll just see a sea of different QUIC SH packets with different connection IDs. It’s also a clear benefit to share address validation state for the return path, and handle NAT rebindings, etc.

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

Both the port number usage and the connection forwarding are things we doing today at large scale—this extension is the basis for how we do multi-hop proxies with iCloud Private Relay, and both aspects are hugely valuable optimizations in practice. The setup here is where you have many thousands to millions of concurrent connections that just need lightweight IP blinding to go to a next hop, with an authenticated proxy.

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

As given in the reasons above, I think this kind of change would be a regression for both privacy and scalability.

Best,
Tommy

> 
> On Tue, Oct 12, 2021 at 2:42 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> 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: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> 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 <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>>, Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>
>> 
>> 
>> 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 <https://www.ietf.org/archive/id/draft-pauly-masque-quic-proxy-02.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-pauly-masque-quic-proxy/ <https://datatracker.ietf.org/doc/draft-pauly-masque-quic-proxy/>
>> Html:           https://www.ietf.org/archive/id/draft-pauly-masque-quic-proxy-02.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 <https://datatracker.ietf.org/doc/html/draft-pauly-masque-quic-proxy>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-masque-quic-proxy-02 <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
> Masque@ietf.org <mailto:Masque@ietf.org>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>