Re: [Masque] Feedback requested on paper draft that mentions MASQUE

[David Fifield <[e-mail]>]

On Wed, Jul 22, 2020 at 10:11:32AM -0700, David Schinazi wrote:
> Regarding your description of MASQUE, it reflects my original
> vision for MASQUE, but that has changed a little bit in the
> last year of IETF discussions, so I would add some tweaks:
>
> - Obfuscation is no longer the main goal of MASQUE, though
> it is a requirement, so I'd rephrase the first sentence to
> something along the lines of:
> <<   MASQUE is a proposal to colocate proxy servers with
>         existing web servers, over HTTP/2 (TLS/TCP) or HTTP/3
>         (QUIC/UDP); it allows proxying capability to be
>         indistinguishable from regular Web Traffic.>>

Thanks for this explanation. It helped me understand how MASQUE has
developed. That, and the IETF 107 slides helped.
https://www.ietf.org/proceedings/107/slides/slides-107-masque-masque-master-slide-deck-02

> - I would link to the charter of the MASQUE working group at
> https://datatracker.ietf.org/wg/masque/about/ instead of
> draft-schinazi-masque-obfuscation.

Okay.

> - When you say "MASQUE is not really an example of the
> Turbo Tunnel idea", I think you're right, though I'll point out
> that you could use multiple layers of MASQUE to accomplish
> that. In other words, you could run MASQUE as both your
> pluggable transport and as your Turbo Tunnel session layer.

Yes -- I'm glad you picked up on this. QUIC works both as a covert
obfuscation protocol and as a session protocol, and there's nothing
incoherent about QUIC-in-QUIC, with the outer QUIC being a disposable
pure transport mechanism and the inner layer holding the actual session
state. It's really no different than KCP-in-TCP, say: replace KCP
(session protocol) with QUIC, and replace TCP (transport protocol) with
QUIC.

I was reluctant to mention the QUIC-in-QUIC idea only because, in my
experience trying to explain the Turbo Tunnel idea, the biggest point of
confusion is that as soon as you mention QUIC, people's minds turn to
UDP and they think you are proposing a UDP-based pluggable transport.
It's a bit of work to communicate the idea that if QUIC is used for its
session properties, the QUIC packets are not sent as UDP datagrams but
are encoded into some other obfuscation protocol, which may not be
UDP-based at all. The fact that QUIC actually works in both places
doesn't help the explanation :)

> So I would perhaps rephrase the rest of the paragraph to
> mention that:
>   - as a pluggable transport, MASQUE only has the option
>     of looking like Web traffic
>   - MASQUE could also be used as a Turbo Tunnel session
>     layer inside another pluggable transport

Here is how I have revised the paragraph:
	MASQUE~\cite{masque-wg} is a proposal to colocate proxy servers
	with web servers, over HTTP/2 (TLS/TCP) or HTTP/3 (QUIC/UDP),
	such that proxy traffic looks like ordinary web traffic. Despite
	the use of QUIC, MASQUE is not really an example of the Turbo
	Tunnel idea---the key difference is that it puts QUIC on the
	outside of the protocol stack, not the inside. To put it in
	terms of this paper, in MASQUE, QUIC is the obfuscation layer
	(chosen to look like web traffic), not the session/reliability
	layer. However, thanks to the fact that QUIC works well both as
	a session protocol and as an obfuscation protocol, MASQUE could
	be adapted into a Turbo Tunnel design in two ways. First, one
	could run some other session protocol through the MASQUE tunnel,
	treating MASQUE as just another obfsucated proxy protocol.
	Alternatively, one could encapsulate MASQUE's QUIC packets into
	some other obfuscation layer (obfs4, say, or even another
	instance of MASQUE) and use MASQUE as an inner session layer.