Subject: Re: [Masque] Proposed draft charter

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 02:17:08 -0800

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 15:05:22 +0000

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 <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Monday, 3. February 2020 at 11:18
To: Mirja Kuehlewind <mirja.kuehlewind=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Masque] Proposed draft charter

Hi folks,

over the tunnel. IOW, it was an application-level VPN.. This is

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.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 07:13:32 -0800

On Mon, Feb 3, 2020 at 7:05 AM Mirja Kuehlewind <
[email-masked]> wrote:

> Hi Ekr,
>
>
>
> the reason why we extended the use cases is because we think the
> requirement are not that different,
>

I see that, but I believe you are incorrect.

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
>

Are you aware of any widely deployed client which would be interested in
this service?

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

Well, as I said above, I am skeptical that people want this service, but if
they do, it seems thoroughly unnecessary to proxy the data; simply
establish a separate channel to the device in question and have it provide
labelled out of band feedback.

-Ekr

>
> Mirja
>
>
>
>
>
>
>
>
>
> *From: *Masque <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Date: *Monday, 3. February 2020 at 11:18
> *To: *Mirja Kuehlewind <mirja.kuehlewind=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Masque] Proposed draft charter
>
>
>
> Hi folks,
>
> 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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 04 Feb 2020 16:30:22 +0100

Hi all, 

There’s been some good discussion on this thread, which has led to some potential improvements in the draft charter. 

Here’s some proposed text which tightens things up quite a bit and tries to clarify many of the parts that caused concern. Thoughts and feedback welcome!

Thanks,
Eric

==================

Many network topologies lead to situations where transport protocol proxying is
beneficial. For example, proxying enables endpoints to communicate when
end-to-end connectivity is not possible and can apply additional encryption
where desirable (such as a VPN).

QUIC is a good candidate protocol for tunneling these types of traffic, as QUIC
provides secure connection establishment, multiplexed streams, and connection
migration. Further, HTTP/3 provides an existing request/response syntax that can
be used to set up and configure services.

Using QUIC as a tunneling technology allows for proxying of both reliable stream
(TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
provide reliable in-order delivery across the client-proxy link. QUIC datagrams
provide for unreliable data transmission, which allows for transporting UDP and
other unreliable flows via a proxy without introducing potentially redundant or
unnecessary recovery mechanisms. In addition, QUIC can carry both types of
streams over the same connection while taking advantage of a unified congestion
controller.

This working group will work on MASQUE (Multiplexed Application Substrate over
QUIC Encryption), a framework that allows concurrently running multiple proxied
flows inside a QUIC connection. The MASQUE framework will specify a signaling
protocol that is used between the endpoint(s) and the MASQUE server to negotiate
proxy services that establish tunneled connectivity. The initial functionality
will be limited to client-initiated proxy tunnels. The WG may subsequently
recharter to consider other applications.

Proxy services that extend the signaling of the base MASQUE protocol can be
adopted by the group by creating a new milestone with AD review.

If MASQUE requires any extensions to existing protocols, the group will
coordinate closely with the respective group responsible for maintaining that
protocol, such as the HTTPBIS, QUIC, or TLS working groups.

==================

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 07:36:23 -0800

Generally LGTM. Some comments below.

On Tue, Feb 4, 2020 at 7:30 AM Eric Kinnear <ekinnear=
[email-masked]> wrote:

> Hi all,
>
> There’s been some good discussion on this thread, which has led to some
> potential improvements in the draft charter.
>
> Here’s some proposed text which tightens things up quite a bit and tries
> to clarify many of the parts that caused concern. Thoughts and feedback
> welcome!
>
> Thanks,
> Eric
>
>
>
> ==================
>
> be used to set up and configure services
>

Note: not just secure connection establishment, but also secure transport.

.

> streams over the same connection while taking advantage of a unified

Maybe "both types of flows" because QUIC streams are a specific thing.

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 4 Feb 2020 17:22:13 +0100

Thank you Eric (Kinnear) for writing this. I like the new charter,
especially the fact that the scope is much narrower now.

David

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 4 Feb 2020 16:23:53 +0000

Hi Eric,

thanks for narrowing this down. The proposed text below looks like a good starting point for a working group!

Mirja

From: Masque <[email-masked]> on behalf of Eric Kinnear <ekinnear=[email-masked]>
Date: Tuesday, 4. February 2020 at 16:30
To: "[email-masked]" <[email-masked]>
Subject: Re: [Masque] Proposed draft charter

Hi all,

Thanks,
Eric

==================

==================

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 06 Feb 2020 13:05:21 +0100

Awesome, thanks all for the feedback! 

Updating with the changes proposed by Ekr and Lucas, thanks for the great suggestions.

===============

QUIC is a good candidate protocol for tunneling these types of traffic, as QUIC
provides secure connectivity, multiplexed streams, and connection migration.
Further, HTTP/3 supports an established request/response semantic that can be
used to set up and configure services.

Using QUIC as a tunneling technology allows for proxying of both reliable stream
(TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
provide reliable in-order delivery across the client-proxy link. QUIC datagrams
provide for unreliable data transmission, which allows for transporting UDP and
other unreliable flows via a proxy without introducing potentially redundant or
unnecessary recovery mechanisms. In addition, QUIC can carry both types of flows
over the same connection while taking advantage of a unified congestion
controller.

 

===============

Thanks,
Eric

> On Feb 4, 2020, at 5:23 PM, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 
> Hi Eric,
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Feb 2020 18:31:02 -0600

I'm finally reading this charter, as opposed to looking at the words ...
mostly, this looks fine to me.

A couple of things inline.

> Updating with the changes proposed by Ekr and Lucas, thanks for the great

The definition of QUIC as practiced in 2020 is "HTTP/3 over QUIC", although
we certainly see proposals for other application protocols over something
QUIC-like. Would something like

"HTTP/3, carried over QUIC, is a good candidate protocol for tunneling
these types of traffic, as QUIC
provides secure connectivity, multiplexed streams, and connection migration.
Further, HTTP/3 supports an established request/response semantic that can
be
used to set up and configure services."

make that clearer?

> (TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams

I'm a little confused here, about whether (HTTP/3-)QUIC is also in scope as
a proxied protocol. Does everyone else know whether it is, and I'm just
catching up?

Best,

Spencer

> flows
> On Feb 4, 2020, at 5:23 PM, Mirja Kuehlewind <
> mirja.kuehlewind=[email-masked]> wrote:
>
> Hi Eric,
>
> *From: *Masque <[email-masked]> on behalf of Eric Kinnear <
> ekinnear=[email-masked]>
> *Date: *Tuesday, 4. February 2020 at 16:30
> *To: *"[email-masked]" <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Feb 2020 16:44:35 -0800

On Mon, Feb 10, 2020 at 4:31 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> The definition of QUIC as practiced in 2020 is "HTTP/3 over QUIC",
> although we certainly see proposals for other application protocols over
> something QUIC-like. Would something like
>
>> (TCP) and unreliable datagram (UDP) flows.. For stream flows, QUIC streams
>>
>
> I'm a little confused here, about whether (HTTP/3-)QUIC is also in scope
> as a proxied protocol. Does everyone else know whether it is, and I'm just
> catching up?
>

Well, it's just UDP, so yes.

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Feb 2020 21:18:19 -0600

> Well, it's just UDP, so yes.

:-)

Thanks!

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Feb 2020 20:26:05 -0800

On 2/10/2020 7:18 PM, Spencer Dawkins at IETF wrote:
>
>
>         I'm a little confused here, about whether (HTTP/3-)QUIC is
>         also in scope as a proxied protocol. Does everyone else know
>         whether it is, and I'm just catching up?
>
>

Actually, that's still not entirely clear. There are two ways of
connecting UDP: connected sockets, or full sockets. One is adequate for
proxying a Quic client: a Quic datagram stream is associated with a five
tuple on the proxy. The other is what you want for a Quic server: a Quic
datagram stream is associated with a 3-tuple on the proxy. It is not
clear to me whether we are speaking of one or the other.

I assume that we are speaking about the five-tuple variant, which is
equivalent to a TCP connection. But this is not obvious from the charter.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 04:25:01 -0800

On Mon, Feb 10, 2020 at 8:26 PM Christian Huitema <[email-masked]>
wrote:

> datagram stream is associated with a 3-tuple on the proxy. It is not clear
> to me whether we are speaking of one or the other.
>
I think we should specify the client->server piece first and see how that
goes. The other one is harder and has more policy issues, as we found with
TURN

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Feb 2020 14:46:15 -0600

Christian,

(top-posting) Thanks - you explained my question better than I asked it.

Best,

Spencer

On Tue, Feb 11, 2020 at 6:25 AM Eric Rescorla <[email-masked]> wrote:

>>>> I'm a little confused here, about whether (HTTP/3-)QUIC is also in
>>>> scope as a proxied protocol. Does everyone else know whether it is, and I'm
>>>> just catching up?
>>>>
>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Feb 2020 14:50:05 -0600

Just following up - I had two questions, and people might have missed the
first one .

On Mon, Feb 10, 2020 at 6:31 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> (Deleted down to )

> used to set up and configure services."

(deleted)

Best,

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 12:51:45 -0800

On Tue, Feb 11, 2020 at 12:50 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> A couple of things inline..
>>

No, I dont think this is correct. We are most likely going to use Datagram
for tunnelling UDP, and that is not part of H3.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Feb 2020 19:09:49 -0600

Hi, Eric,

> for tunnelling UDP, and that is not part of H3.

That's kind of what I expected, but it sure isn't clear from the
description of what QUIC is providing, which is

"QUIC provides secure connectivity, multiplexed streams, and connection
migration."

Perhaps it's worth mentioning datagram as well, given that secure
connectivity,  multiplexed streams, and connection migration have been in
the QUIC charter since 2016, and datagram is only being added to the
proposed charter now.

Best,

Spencer