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

David Schinazi <dschinazi.ietf@gmail.com> Tue, 28 July 2020 01:10 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF83A094E for <masque@ietfa.amsl.com>; Mon, 27 Jul 2020 18:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0h0b0f6zjTr for <masque@ietfa.amsl.com>; Mon, 27 Jul 2020 18:10:16 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAE63A0878 for <masque@ietf.org>; Mon, 27 Jul 2020 18:10:16 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id h8so10038317lfp.9 for <masque@ietf.org>; Mon, 27 Jul 2020 18:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rv5plC3khsALP7KXGH9InGa7BSy/VyFx+MUarQXwueE=; b=X84qH9eJnidztCwhk7liyGYpqtckWrfOSWD0lxfO9zQFAPqb0hBcqYQuuIBq4QG7vc HLJbMWayLU5o9zpCj+4z4MTIL/lQkVo+HTtjroFOJXV3gZDDbwaOfE6K2fTMInJb6Eok doXZ14KAa2x8bGYJosyJdfcOI4uFUEVHsYougafFSv7gJ/FjrJAEvBl9rb7/Qkpqvvq9 iZMoRTOWtdowfcYnRo2v2L8PL35d35N3DM+preNJBU0p4HCxMqqi5iv3cSyrejwnBDMJ AhaAmP9ej+lZkO2vQqSawtwbuh/lJ2kz7hFJ6t4/MdO9DRJ/8L2aheX9yzP0JSWboqzk rQRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rv5plC3khsALP7KXGH9InGa7BSy/VyFx+MUarQXwueE=; b=eKDwvBSjq6/nStzvdCaXA8aa1ivLiC64c0DI5CUFHRIJjP/GLikhkzeVURrxHHhUJD NYihX3t8je5a1s5w3wOfG/R9M/FDgv18hWJ7Z8SAtXBNyA08czf/gR6G48AS6UAwPy6G plXPWx1eNvj/AOzSBfDoGHliENOdfHxv0wH/tOHNOU6cEPO/XQzD9eN3HLmuCjHJpseM HdUdf4sKDyjzBr3+fVSOBPltCS5/KiAwfh8A5GW3h50fs2RvEIRVmZVxDsWO4fm1i07j WJ0YhgXGpdqsU80Otxlyx5C7jayjOrh3DuLahGSOMp644eb50Vf7OW+gWpDs5zXji2Ch PIqg==
X-Gm-Message-State: AOAM533hUK3htjoZzAazS09f2ja9euO93qOd04rLXK+JqhQtgqD0jbCw ovVrqDbDvO5AeSquhJafelzDRkUamoxcloZoZKmfhA==
X-Google-Smtp-Source: ABdhPJwKiz9sUnScfHMrs25eZtc0QZmpwh0ssQriB+u+ApPbni0aj3xi1QkkEUYXaMeagJoEtmIx9VDyxnD0V7It/i4=
X-Received: by 2002:ac2:4d16:: with SMTP id r22mr12965972lfi.21.1595898614174; Mon, 27 Jul 2020 18:10:14 -0700 (PDT)
MIME-Version: 1.0
References: <20200722053656.4a4qj7j6sedsxu6l@bamsoftware.com> <CAPDSy+6zYs0aGTJy8u5SBH4nqwy5NhAfXFgf=YFRoDNpL5OZ1w@mail.gmail.com> <20200728001502.otnd5ycgyj5vmaqq@bamsoftware.com>
In-Reply-To: <20200728001502.otnd5ycgyj5vmaqq@bamsoftware.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 27 Jul 2020 18:10:03 -0700
Message-ID: <CAPDSy+6G8i1YCFbXQpJxyCgPWPCpKPM3UXOWBrCwZ4gZOvFdfg@mail.gmail.com>
To: David Fifield <david@bamsoftware.com>
Cc: MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fed93b05ab7619d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/_BAQFW6kBIsRlcRGSv-YpZOFBoU>
Subject: Re: [Masque] Feedback requested on paper draft that mentions MASQUE
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 01:10:19 -0000

Thanks for following up, David!

I agree with you on the details, and the revised paragraph looks great!

David

On Mon, Jul 27, 2020 at 5:15 PM David Fifield <david@bamsoftware.com> wrote:

> 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.
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>