Subject: [Masque] Call for MASQUE use cases

From: "Christopher Wood" <[email-masked]>
Date: Thu, 20 Feb 2020 19:13:03 -0800

The core MASQUE protocol [1] describes a simple negotiation mechanism 
for various
applications. However, it omits use cases for these applications. MASQUE 
obfuscation
in support of a "hidden VPN" service is one use case [2]. Tunneling QUIC 
is another [3].

Given that MASQUE and the upcoming BoF will be successful insofar as it 
addresses important
use cases, I think it'd be useful to discuss these application use cases 
in more detail
before Vancouver. To that end, let's use this time before the meeting to 
discuss them!

I'd like to ask interested parties to please surface use cases they know 
of (and care about).

Thanks!
Chris

[1] https://tools.ietf.org/html/draft-schinazi-masque-02
[2] https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-00
[3] https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-02

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Feb 2020 15:13:34 -0800

I am interested in this as an alternative transport for securely proxying
HTTP traffic (cf. https://fpn.firefox.com/)

-Ekr

On Thu, Feb 20, 2020 at 7:13 PM Christopher Wood <[email-masked]>
wrote:

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

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 23 Feb 2020 23:05:38 -0500

I think virtually all the use cases for SOCKS and HTTP CONNECT are also
in-scope for MASQUE.  Additionally, there are some cases that they don't
handle, or that MASQUE could handle better:

 - TCP proxying over congested/lossy client-proxy links.  SOCKS and
HTTP/1.1 don't multiplex, so the congestion controllers for each TCP
connection fight over this link.  HTTP/2 multiplexes but has head-of-line
blocking on loss.  CONNECT over HTTP/3 would get us unified
congestion control without blocking.

- Proxied WebRTC (or RTC generally).  Currently, using a proxy generally
forces WebRTC to use TCP, which generally also forces it to route through a
TURN server (another proxy!).  This adds up to significantly impaired
latency and quality.  By supporting UDP, MASQUE could do better.

- Virtual machine running in a webpage.  MASQUE could enable standardized
networking for virtual machines in WebAssembly.

- Network debugging when using a proxy.  HTTP CONNECT doesn't provide any
indication of why a connection failed, e.g. to distinguish RST, FIN,
timeout, or an ICMP error.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Feb 2020 10:57:07 -0600

Hi, Ben,

I have a couple of questions about some use cases you described (inline),
but thank you for sending out your list.

> congestion control without blocking.

IIRC, CONNECT currently doesn't know how to do HTTP/3 over QUIC, right? So
is what you're thinking about

   - Connect can do HTTP/3 - proxy - HTTP/3 or HTTP/2 - proxy - HTTP/2, OR
   - Connect can do HTTP - proxy - HTTP, where the HTTP versions don't have
   to match?

> timeout, or an ICMP error.

We've come some distance since I was introducing myself at IESG meetings as
"AD for the spin bit", but we haven't come a really long way - the spin bit
is in and optional, which is fine, and we are noticing
https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-quic-lossbits/ as
a related draft, but we haven't had it on a QUIC working group agenda in
the past year (IIRC), even though it gets talked about in places like MOPS.
And that's just one more (almost certainly optional) bit of information, if
it does move forward.

I'm intrigued by your proposed use case on network debugging, especially if
proxying HTTP/3 using CONNECT becomes a common mode of operation - have you
started to hash out details for this use case, what might be visible
without revealing too much, etc.? If not, would you like to work on
something with me (and, one hopes, smarter and more realistic QUIC people)?

Best,

Spencer

---

From: Ted Hardie <[email-masked]>
Date: Mon, 24 Feb 2020 09:20:01 -0800

In-line.

Ted

On Mon, Feb 24, 2020 at 8:57 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>    - Connect can do HTTP - proxy - HTTP, where the HTTP versions don't
>    have to match?
>
> We've come some distance since I was introducing myself at IESG meetings
> as "AD for the spin bit", but we haven't come a really long way - the spin
> bit is in and optional, which is fine, and we are noticing
> https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-quic-lossbits/
> as a related draft, but we haven't had it on a QUIC working group agenda in
> the past year (IIRC),
>
It was the last item discussed at the last interim, see the minutes here:
https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md

regards,

Ted Hardie

> even though it gets talked about in places like MOPS. And that's just one
> more (almost certainly optional) bit of information, if it does move
> forward.
>
> I'm intrigued by your proposed use case on network debugging, especially
> if proxying HTTP/3 using CONNECT becomes a common mode of operation - have
> you started to hash out details for this use case, what might be visible
>>> I am interested in this as an alternative transport for securely
>>> proxying HTTP traffic (cf. https://fpn.firefox.com/)
>>>
>>> -Ekr
>>>
>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Feb 2020 11:31:49 -0600

Hi, Ted,

On Mon, Feb 24, 2020 at 11:20 AM Ted Hardie <[email-masked]> wrote:

>> IIRC, CONNECT currently doesn't know how to do HTTP/3 over QUIC, right?
>> So is what you're thinking about
>>
>>> - Virtual machine running in a webpage.  MASQUE could enable
>>> standardized networking for virtual machines in WebAssembly.
>>>
>>> - Network debugging when using a proxy.  HTTP CONNECT doesn't provide
>>> any indication of why a connection failed, e.g. to distinguish RST, FIN,

Thank you for this pointer! The minutes were posted to the datatracker, but
I wasn't checking interim meeting minutes. My bad.

>> more (almost certainly optional) bit of information, if it does move
Of course, it's still only one more bit of information :-)

So, I'm still intrigued by Ben's suggestion.

Best,

Spencer

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Feb 2020 12:52:39 -0500

On Mon, Feb 24, 2020 at 11:57 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> I am trying to describe this: client <--[H3]---> proxy <--[SSH]-->
destination

Where "SSH" is an arbitrary example of a TCP-based protocol.  Any TCP
connection can run over CONNECT.

In other words, I am talking about unmodified CONNECT over HTTP/3.

> something with me (and, one hopes, smarter and more realistic QUIC people)?

I wasn't really thinking about QUIC; I was thinking primarily about TCP.
If we're in the business of modernizing CONNECT, one thing that I would
like would be an HTTP Trailer indicating _why_ the connection was closed,
e.g. who closed it, FIN vs. RST vs. timeout.  Similarly, if CONNECT fails,
it would be nice to have a header indicating why it failed, and perhaps
some clarity about which status codes to use.  My main use case here is
"showing users the right error message" when something goes wrong.

I would have to think some more about QUIC.  In my view, it depends on
whether we end up defining (1) a QUIC-specialized proxy, (2) a general UDP
transport proxy, and/or (3) an IP tunnel.  If (1) or (2), it could be
interesting to consider how to convey some lower-layer information to
enable ICMP error reporting, PMTUD, etc.  (An IP tunnel gets us all that
stuff automatically.)

One thing I have proposed is using continuous measurement of client-proxy
RTT to unify the two layers of congestion control, but this is a purely
hypothetical performance optimization, not for network debugging.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Feb 2020 12:11:19 -0600

Hi, Ben,

Thank you for the clues below.

Perhaps we should talk in Vancouver :-)

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 24 Feb 2020 18:12:08 +0000

> "showing users the right error message" when something goes wrong.

If we're talking only HTTP/2 and HTTP/3, I don't think trailers is the
right fit here but nor do I see that being a problem because the terminal
state of the TCP connection is reflected in the terminal state of the HTTP
stream. FIN -> END_STREAM, TCP error -> RST_STREAM with CONNECT_ERROR code.
Other failure conditions could be communicated by adding new error codes.

In failure case that occurs when CONNECT fails to even get off the ground,
a standard 4xx/5xx error seems apropriate and I'm reminded of
https://tools.ietf.org/html/rfc7807 which describes machine-readable
details for "problems".

---

From: Dallas McCall <[email-masked]>
Date: Tue, 25 Feb 2020 10:54:45 -0500

I've been developing a quic-based vpn (partially upstreamed to the quiche
project
<https://quiche.googlesource.com/quiche/+/refs/heads/master/quic/qbone/>)
and would be interested in working this into a standard.

Dallas