Re: [Masque] Proposed draft charter

[Mirja Kuehlewind <[e-mail]>]

Hi Ekr,

the reason why we extended the use cases is because we think the requirement are not that different, however, the whole point is to move away from transparent proxies that interfere with the end-to-end connection to a setup where the client actively decides to use a proxy to a request a service. So the QUIC tunnel is actually just used for forwarding traffic (and not modifying the traffic) but then the tunnel connection can also be used to exchange information between the endpoint and the proxy

You wrote:
„In the tunnel-type case, the point of the proxy is to a great extent to protect client-server connection from interference by the local network (as well as to conceal the client/server IP addresses). However, in the PEP style case, the purpose appears to be to reestablish the control that these network-level devices had prior to the advent of QUIC's end-to-end encryption.“
What you call “PEP-style” is explicitly not supported by any solution we are looking for in MASQUE. However, PEP stands for “Performance Enhancing Proxy”. So what we have in mind is still aiming at enhancing performance but in a way where the proxy provides information to the endpoints and the control sits at the endpoint to do anything with this information. So all thatb is needed is forwarding and a signal channel.

Mirja




From: Masque <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Monday, 3. February 2020 at 11:18
To: Mirja Kuehlewind <mirja.kuehlewind=[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Masque] Proposed draft charter

Hi folks,

I have reviewed this charter and I fear that it is going in the wrong
direction. When MASQUE was first proposed, it was conceptually simple:
effectively an HTTP CONNECT tunnel but (1) Implemented over QUIC/H3
rather than H1/H2 (2) Allowing for non-TCP protocols to be carried
over the tunnel. IOW, it was an application-level VPN.. This is
something that clearly has a number of valuable uses cases. To name
two real-world applications where this would be valuable:

1.. Tor has repeatedly discussed converting from their TCP-based
   protocol to something DTLS or QUIC-like.

2. Firefox Private Network (https://fpn.firefox.com/<https://protect2.fireeye.com/v1/url?k=f414024d-a89dd870-f41442d6-0cc47ad93c0c-0fde56b3d9745760&q=1&e=4e88e632-cdec-4643-be39-12b7bdc3e6aa&u=https%3A%2F%2Ffpn.firefox.com%2F>) has an
   H2-based secure proxy mode, and running it over QUIC would
   have some obvious advantages.

However, when I read this charter, that simple application is sort of
buried under a bunch of other stuff that seems more appropriate for
some other use cases, such as performance-enhancing proxies. proxy
caches, etc. While I appreciate that something like tunnel (as in
FPN/Tor) and PEPs are both technically proxies, they're fundamentally
dissimilar even though they occupy the same position in the data
stream (though not the same position in the network, given that PEPs
are typically on-path between endpoints whereas tunnel-type systems
typically are not).

It's not necessarily bad to charter work that handles multiple use
cases, but in this case, I think that it would be a severe distraction
because the requirements are totally different. In the tunnel-type
case, the point of the proxy is to a great extent to protect
client-server connection from interference by the local network
(as well as to conceal the client/server IP addresses). However, in
the PEP style case, the purpose appears to be to reestablish the
control that these network-level devices had prior to the advent
of QUIC's end-to-end encryption. This is readily apparent from the
text in this proposed charter that says:

  As use-cases for deploying MASQUE have different security or
  performance requirements, the working group may define multiple
  MASQUE services for proxying to suit these disparate use-cases.

This actually seems like an understatement.

IMO, we should simply strike all these use cases and focus on a
simple tunnel protocol, which seems comparatively straightforward.
Such a protocol should be designed to be extensible.

In parallel, those who are interested in designing protocols to
re-establish access by network intermediaries can work on those
separately, and, if there is sufficient implementor interest we
can then discuss whether those use cases should be served by
Masque extensions or by some other protocol.

-Ekr