Re: [Masque] Comments on draft-pauly-masque-quic-proxy-01.txt

[Tommy Pauly <[e-mail]>]

Hi ekr,

> On Apr 15, 2021, at 10:27 AM, Eric Rescorla <[e-mail]> wrote:
> 
> Hi folks,
> 
> I've reviewed this document. At a high level, I'm unconvinced of the
> requirements that lead to this design. I agree that QUIC in QUIC
> is going to be common, but ISTM that 
> 
> First, the Forwarded mode. I have two concerns here:
> 
> 1. The general thrust of QUIC is to encrypt everything and having the
>    non-handshake data in the clear goes against that. It is also much
>    more difficult to analyze.

In this case, the feature is to allow not double-encrypting data. However, there would never be any packets exposed on a path that wouldn’t be fully encrypted. It’s essentially made for multi-hop proxy cases where re-encryption is not a requirement for security or privacy.

For example, if you use two proxies, you can forward from the first to the second, and then tunnel to the target.

>    
> 2. This document offers performance as the reason for forwarding mode,
>    but I think we should be quite suspicious of such claims without
>    strong evidence. The cost of symmetric encryption and decryption in
>    modern systems is extraordinarily low [0] especially with hardware
>    support, so removing the encryption seems unlikely to materially
>    change the performance profile of most proxies.

The scalability of letting a proxy in a multi-hop proxy setup essentially just be a packet forwarder is very measurable.

Our slides that we drew up for IETF 110 go into the details here:
https://datatracker.ietf.org/meeting/110/materials/slides-110-masque-quic-aware-proxying-00 <https://datatracker.ietf.org/meeting/110/materials/slides-110-masque-quic-aware-proxying-00>

Forwarding also does have a notable impact on effective MTU once you start going through multiple hops, so allowing forwarding in these environments allows for more hops scaling well.

> 
> 
> Second, I'm not really convinced of the need to reuse local host/port
> values. We have plenty of experience with TCP proxies that use a
> separate port for each connection (this is, after all, what a CDN is
> on the back end), and AFAIK that works out mostly OK. You don't
> really explain why this is necessary, but I can imagine two
> reasons:
> 
> 1. Port scarcity -- this seems like mostly an IPv4 issue, as you can
>    use IPv6 to have an arbitrary number of addresses.

Right, this is more of an issue for IPv4 than IPv6. However for particularly large numbers of connections being proxied between the same two nodes, it does make things simpler.

> 
> 2. Implementation issues around having multiple sockets open -- this
>    seems like something that is fixable at the OS level (and again,
>    we'll want to for QUIC CDNs), so we don't need to add protocol
>    machinery.

Agreed that this can be managed in various ways on a system.

> 
> Given that much of the complexity of this proposal comes from these
> two requirements, ISTM that they require fairly close examination.
> 
> If we were to relax both requirements, it seems to me that we could
> have a much simpler protocol which was basically QUIC-specific header
> compression. I can imagine a number of different ways to implement
> this, including pre-registration (the sender tells the receiver about
> CIDs in advance) or notification (the receiver tells the sender "I now
> know CID X and you can compress it with label Y"). Note that we could
> probably just fold such a compression scheme into whatever (if
> anything) we did for IP header compression.
> 
> If we only relax the forwarding requirement, then we would still
> need some mechanism to mux multiple clients on the same host/port
> quartet. I can imagine a number of angles here:
> 
> 1. The design you have in which the client has to pre-register
>    each receiving CID.
> 2. A design in which the proxy provides part of the CID or
>    tells the client how to construct them. This would have
>    the advantage that the proxy never told the client "no",
>    which simplifies the client logic [1].
> 3. Require the clients to use high entropy CIDs (made easier
>    with header compression) and just assume that conflicts
>    are errors.

Agreed that collisions should be rare, and I’m fine with designs that just make such collisions errors.

I think it comes down to being able to support forwarding, which (for the reasons I list above) I believe is an important capability. Not to always be used, but to be possible.

Thanks,
Tommy
> 
> -Ekr
> 
> [0] It's quite old, but see:
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html <https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html>
>                 
> [1] And testing, as CID collisions will be very rare.
> -- 
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque