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

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Apr 2021 10:27:46 -0700

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.

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.

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.

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.

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.

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

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 15 Apr 2021 11:52:15 -0700

Hi ekr,

> On Apr 15, 2021, at 10:27 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi folks,
> 

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.

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

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

>    we'll want to for QUIC CDNs), so we don't need to add protocol

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

>    with header compression) and just assume that conflicts

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
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html <https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html>
>                 
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Apr 2021 12:02:29 -0700

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

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

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.

> The scalability of letting a proxy in a multi-hop proxy setup essentially
> just be a packet forwarder is very measurable.
>
> 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).

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

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