Re: [Masque] Call for MASQUE use cases

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Ben,

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

On Sun, Feb 23, 2020 at 10:06 PM Ben Schwartz <bemasc=
[e-mail]> wrote:

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

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?

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

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


> On Sat, Feb 22, 2020 at 6:14 PM Eric Rescorla <[e-mail]> wrote:
>
>> 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 <[e-mail]>
>> wrote:
>>
>>> 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
>>>
>>> --
>>> Masque mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>