Subject: Re: [Masque] Call for MASQUE use cases

From: "Border, John" <[email-masked]>
Date: Tue, 3 Mar 2020 22:43:08 +0000

Here is another potential use case...

    There is a trend towards using satellite links in a multipath combination with a terrestrial technology (e.g. LTE).  The two paths provide redundancy for each other.  But, the big selling point is using QoS classification to send traffic which requires low latency (i.e. truly interactive traffic) via the terrestrial path and traffic which requires high throughput (so called bulk traffic) through the satellite path.  As I understand the Multipath QUIC proposal, the solution requires the end host to select the path to use (and is also oriented towards sending the same connection via multiple paths).  In the use cases we see, the end hosts are not cognizant of the multiple paths.  The edge router classifies traffic (perhaps with DSCP help from the end host) and selects the path.  The router also knows about path failures and degradations.   With QUIC, traffic classification is blocked.  Perhaps we can get end hosts to opt in and expose traffic classification via DSCPs.  But, that has the potential of being carried farther than necessary.  A proxy could be trusted with just enough information to do the classification while removing the evidence before forwarding the traffic.

    Does this fit?

John

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Christopher Wood
Sent: Thursday, February 20, 2020 10:13 PM
To: [email-masked]
Subject: [Masque] Call for MASQUE use cases

**EXTERNAL EMAIL** 

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://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFMXV8K-fA$
[2] https://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-00__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFNUKdnP3g$
[3] https://urldefense.com/v3/__https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFPmGZef8g$ 

--
Masque mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/masque__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFPynOxALg$

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 4 Mar 2020 15:57:59 -0500

On Tue, Mar 3, 2020 at 5:43 PM Border, John <[email-masked]> wrote:

>     There is a trend towards using satellite links in a multipath
> combination with a terrestrial technology (e.g. LTE).  The two paths
> provide redundancy for each other.  But, the big selling point is using QoS
> classification to send traffic which requires low latency (i.e. truly
> interactive traffic) via the terrestrial path and traffic which requires
> high throughput (so called bulk traffic) through the satellite path.  As I
> understand the Multipath QUIC proposal, the solution requires the end host
> to select the path to use (and is also oriented towards sending the same
> connection via multiple paths).  In the use cases we see, the end hosts are
> not cognizant of the multiple paths.  The edge router classifies traffic
> (perhaps with DSCP help from the end host) and selects the path.  The
> router also knows about path failures and degradations.   With QUIC,
> traffic classification is blocked.  Perhaps we can get end hosts to opt in
> and expose traffic classification via DSCPs.  But, that ha
>  s the potential of being carried farther than necessary.  A proxy could
> be trusted with just enough information to do the classification while
> removing the evidence before forwarding the traffic.
>
>     Does this fit?
>

I think this is a good use case.  A simple deployment setup might say
"everything sent to the proxy goes over satellite", and let the client
decide which path each connection should take by whether it uses the proxy
or not.

> 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!
>
> [1]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFMXV8K-fA$
> [2]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-00__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFNUKdnP3g$
> [3]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFPmGZef8g$
>
> --
> Masque mailing list
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Maxime Piraux <[email-masked]>
Date: Thu, 5 Mar 2020 14:27:48 +0100

Hello Chris,

We are working on a proposal to tunnel Internet protocols inside a QUIC 
connection [1]. We are interested in use cases in which the client can 
use several access networks to reach the tunneling server. Our current 
proposal defines a new application protocol on top of QUIC for this 
purpose, though our signaling protocol could use HTTP/3 to align with 
the current MASQUE proposal.

We are interested in integrating our efforts as part of this upcoming 
WG. An updated version of the document will be published on Monday [1] [2].

Maxime Piraux

[1] https://datatracker.ietf.org/doc/draft-piraux-quic-tunnel/
[2] https://datatracker.ietf.org/doc/draft-piraux-quic-tunnel-tcp/

Le 21/02/20 à 04:13, Christopher Wood a écrit :
> 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!
>
> [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: Dragana Damjanovic <[email-masked]>
Date: Thu, 5 Mar 2020 15:05:00 +0100

On Mon, Feb 24, 2020 at 6:53 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>
>
> On Mon, Feb 24, 2020 at 11:57 AM Spencer Dawkins at IETF <
> [email-masked]> wrote:
>
>> 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=
>> [email-masked] <[email-masked]>> 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?
>>
>> 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.
>
>  - 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)?
>>
>
> 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 was looking into implementing sending an IP address in CONNECT request to
a proxy instead of host name. It is not easy to figure out if connect
should be retried with another IP address. Having better error codes would
be helpful.

dragana

> 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.
>
>
>> Best,
>>
>> Spencer
>>
>>
>>> On Sat, Feb 22, 2020 at 6:14 PM Eric Rescorla <[email-masked]> 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 <[email-masked]>
>>>> wrote:
>>>>
>>>>> MASQUE
>>>>> obfuscation
>>>>> QUIC
>>>>> is another [3].
>>>>> it
>>>>> addresses important
>>>>> cases
>>>>> in more detail
>>>>> to
>>>>> discuss them!
>>>>> I'd like to ask interested parties to please surface use cases they
>>>>> know
>>>>> of (and care about).
>>>>>
>>>>> Thanks!
>>>>> Chris
>>>>>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 5 Mar 2020 14:19:04 +0000

On Thu, Mar 5, 2020 at 2:05 PM Dragana Damjanovic <[email-masked]>
wrote:

>
> I was looking into implementing sending an IP address in CONNECT request
> to a proxy instead of host name. It is not easy to figure out if connect
> should be retried with another IP address.. Having better error codes would
> be helpful.
>
> dragana
>

That's an interesting case. IIUC correctly, your client might ask the proxy
to use IPv6, which could fail, and your client might then try IPv4?

A failure such as this today would be communicated by returning an HTTP
error status. Is there a gap that mean HTTP cannot be used to communicate
the specific error condition you describe?

Cheers
Lucas

---

From: Dragana Damjanovic <[email-masked]>
Date: Fri, 6 Mar 2020 07:00:14 +0100

On Thu, Mar 5, 2020 at 3:19 PM Lucas Pardue <[email-masked]>
wrote:

>
>
> On Thu, Mar 5, 2020 at 2:05 PM Dragana Damjanovic <
> [email-masked]> wrote:
>
>>
> That's an interesting case. IIUC correctly, your client might ask the
> proxy to use IPv6, which could fail, and your client might then try IPv4?
>
>
yes. That would be most common case. We may retry a different ip address,
but I am actually not sure how often is something like this happening
because it may have a long delay depending on the netowrk error(try PIv4
address 1 and if it fails tray IPv4 address 2)

> the specific error condition you describe?

no, I think you cannot be 100% sure, the error may mean multiple things.

Thinking about it more, maybe it would be better to send a list of IP
addresses and let proxy chose one or do a happy-eyeballing for example.
That would mean a CONNECT with list of IP addresses instead of one or a
host name.

dragana

---

From: David Schinazi <[email-masked]>
Date: Fri, 6 Mar 2020 10:55:51 -0800

Hi Dragana,

What's your use-case where the client has a set of IP address literals but
no hostname?

David

---

From: Dragana Damjanovic <[email-masked]>
Date: Sat, 7 Mar 2020 13:51:24 +0100

> What's your use-case where the client has a set of IP address literals but
The client has both.
The idea was to use DoH to resolve host name. Send IP address to a proxy
and use ESNI (or what ever the new name might be). in this way you do not
reveal host names you are connecting to to the proxy.

dragana

>>>> I was looking into implementing sending an IP address in CONNECT
>>>> request to a proxy instead of host name. It is not easy to figure out if
>>>> connect should be retried with another IP address.. Having better error
>>>> codes would be helpful.
>>>>
>>>> dragana
>>>>
>>>

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 09 Mar 2020 13:23:52 -0700

Continuing the trend of use cases for this, we’ve got several in which we’d really like to have much better support for proxying of datagram flows, and MASQUE looks like it could be a really good start on a solution for those needs.

Thanks,
Eric

> On Mar 7, 2020, at 4:51 AM, Dragana Damjanovic <[email-masked]> wrote:
> 
> 
> 
> On Fri, Mar 6, 2020 at 7:56 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dragana,
> 
> What's your use-case where the client has a set of IP address literals but no hostname?
> 
> 
> The client has both.
> The idea was to use DoH to resolve host name. Send IP address to a proxy and use ESNI (or what ever the new name might be). in this way you do not reveal host names you are connecting to to the proxy.
> 
> dragana
>  
> David
> 
> On Thu, Mar 5, 2020 at 10:00 PM Dragana Damjanovic <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, Mar 5, 2020 at 3:19 PM Lucas Pardue <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, Mar 5, 2020 at 2:05 PM Dragana Damjanovic <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I was looking into implementing sending an IP address in CONNECT request to a proxy instead of host name. It is not easy to figure out if connect should be retried with another IP address.. Having better error codes would be helpful.
> 
> dragana
> 
> That's an interesting case. IIUC correctly, your client might ask the proxy to use IPv6, which could fail, and your client might then try IPv4?
> 
> 
> yes. That would be most common case. We may retry a different ip address, but I am actually not sure how often is something like this happening because it may have a long delay depending on the netowrk error(try PIv4 address 1 and if it fails tray IPv4 address 2)
>  
> A failure such as this today would be communicated by returning an HTTP error status. Is there a gap that mean HTTP cannot be used to communicate the specific error condition you describe?
> 
> Thinking about it more, maybe it would be better to send a list of IP addresses and let proxy chose one or do a happy-eyeballing for example. That would mean a CONNECT with list of IP addresses instead of one or a host name..
> 
> dragana
> 
> 
> 
> 
> Cheers
> Lucas
> 
>  
> -- 
> Masque mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> [email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Mar 2020 18:47:01 +0000

To add more: The QUIC as a substrate draft (https://datatracker.ietf.org/doc/draft-kuehlewind-quic-substrate/) describes multiple potential use cases. We are most interested in the case where a proxy in the access network (e.g. mobile networks) could either assist the endpoint with additional information about the (mobile) link or enable different congestion control on the tunnel connection between the client and the proxy that covers the mobile link only. As the characteristics of cellular links are often different than for rest of path on the Internet, congestion control and recovery could be optimized differently for that link segment in order to use the mobile network capacity most efficiently.

Mirja

From: Masque <[email-masked]> on behalf of Eric Kinnear <ekinnear=[email-masked]>
Date: Monday, 9. March 2020 at 21:25
To: Dragana Damjanovic <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, MASQUE <[email-masked]>, Ben Schwartz <bemasc=[email-masked]>, Spencer Dawkins at IETF <[email-masked]>, Lucas Pardue <[email-masked]>, David Schinazi <[email-masked]>, Christopher Wood <[email-masked]>
Subject: Re: [Masque] Call for MASQUE use cases

Thanks,
Eric

On Mar 7, 2020, at 4:51 AM, Dragana Damjanovic <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Mar 6, 2020 at 7:56 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dragana,

The client has both.

dragana

David

On Thu, Mar 5, 2020 at 10:00 PM Dragana Damjanovic <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 5, 2020 at 3:19 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 5, 2020 at 2:05 PM Dragana Damjanovic <[email-masked]<mailto:[email-masked]>> wrote:

dragana

dragana

Cheers
Lucas

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