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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 15, 2021 at 11:52 AM Tommy Pauly <[e-mail]> wrote:

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

I understand your point, but I don't think it's really responsive to my
concern. Exposing the data between the client and the proxy has a material
impact on the security of the data on that hop.


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

Thanks for this data. I think I missed this presentation. Assuming I'm
reading this correctly, it seems to me like most of the difference here is
probably due to the fact that you're not having to pull the data into
quiche. That's not meaningless, but it's also precisely the kind of
implementation issue that it seems like one could address in a production
environment. Certainly, the crypto itself doesn't seem like the primary
concern a modern AES-GCM core can easily saturate a 1Gig link.


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

I'm not sure what environments you have in mind here, but the primary
multi-hop environment I know of is anonymity networks like Tor. However, in
that case (1) you absolutely need to tunnel, not forward and (2) you
generally want a rather different packet framing (i.e., one that is
constant-size per hop).


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

Well, seeing as it comes at the cost of significantly more protocol
complexity, this seems like an arguable point.


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

OK. I think I'd need to hear something much more convincing than the
reasons above to be in favor of forwarding.

-Ekr

Thanks,
> Tommy
>
>
> -Ekr
>
> [0] It's quite old, but see:
> 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
>
>
>