Re: [Masque] QUIC proxy scenarios

David Schinazi <> Thu, 13 June 2019 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8831112016B for <>; Wed, 12 Jun 2019 19:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XCggyi4i8Bev for <>; Wed, 12 Jun 2019 19:39:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 072DF12008B for <>; Wed, 12 Jun 2019 19:39:35 -0700 (PDT)
Received: by with SMTP id 16so16927401ljv.10 for <>; Wed, 12 Jun 2019 19:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywqxqUN3yYEzvsKyqIiLxXa5tkzUs5wZFPRnucb4BeY=; b=YZwXZl2CT14DU7lrgQ1i4/yuoQCLvDzrfP3mbdnVJEagJhCoNgT0hWw9fFcxFs0dx2 mXbH2AbRVXuenW1vNnlcLZUMglcweoWL4HSGQyRwSXbjcmaAchhR0hfLlh9dhOYyLRXd YVbtjttw0om2oe+8ZxuRG5HKPyGmWvKE7ckiYmWLX4hZB1cqXDZXloOn5yPebor4LRew iqU8Sf3AKW8gHBnD3VM23Mw3wFea0rbGNo4pJrvy3ZftcJRQ/AZD4mkeaUXU00uXAG1j 2sEy/Du9wKxt7NNw7IL59QSSBmxiXDPMgta4OTzKHsEvCAXi6CnKGTPFhETt51v3Beum 0EOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ywqxqUN3yYEzvsKyqIiLxXa5tkzUs5wZFPRnucb4BeY=; b=eil046gWpRZT19/HbQ9DIlVTMYoOtK937Mj5NI7P/iGEaYnKsGyRVcrC2IaLlzQlZi nrublMxDC5nTQHuZKrcapis/cCPU4i4YwFY9g87mn27zBW917R8nBY+fY3None4KarSt VwmYUdARYh5SWvHQdF4wiyDkUfOswObHRcvnR1fn4FlrYqwEEPKnwHIN3QZT1E5+RerA 7UjUWLwa9S7TbjPvIZy+czbPWy2dVI+fqGm1COzlVXW7En8m06XHLtekMfn7rRG+9Es8 8buHwQSnZ7k/AuDlt8Xv/mOWfkwlNbOMOjLYD+jRuqDnjOZzs3OARkMeJkVdQE9tqGHZ zIyA==
X-Gm-Message-State: APjAAAW+6C1PqIjF2uusKD474FEvA11r43D06qPJ40UgDsth02EZcgaU 30GbuifGtne7mLh2Z9it+R3CwwH77+0nMuY8zzJA0g==
X-Google-Smtp-Source: APXvYqxXZx6IcfSj96QGtugLNXPqn1DIShn18+RiLbTW1oA9RXiPZF3ghJSQ4oM+1IIVXCJNDn3Q65/OEmvyQYBqbds=
X-Received: by 2002:a05:651c:150:: with SMTP id c16mr3938278ljd.193.1560393573193; Wed, 12 Jun 2019 19:39:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Wed, 12 Jun 2019 19:39:21 -0700
Message-ID: <>
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="000000000000a3ddb8058b2b70d3"
Archived-At: <>
Subject: Re: [Masque] QUIC proxy scenarios
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2019 02:39:38 -0000

Hi Christian,

Apologies for the delayed response, it's been a busy few weeks.

I've taken a lot of text from your PR
<> and added it
to the document.
I think we can have MASQUE be a framework where both proxy and VPN can be
negotiated and co-exist.

Please let me know what you think of the latest text

I'm thinking as a next step we may want to flesh out the details of the QUIC
(e.g., how to negotiate its use and to compress QUIC connection IDs)


On Tue, May 21, 2019 at 3:59 AM David Schinazi <>

> Hi Christian,
> These are definitely interesting use-cases, and I think the draft could
> use more text to that extent.
> A pull request would be most welcome!
> In the Home Server Scenario, can you elaborate on who the
> client/server/proxy is? Is the goal to access home services from anywhere
> in the Internet?
> David
> On Tue, May 21, 2019 at 10:04 AM Christian Huitema <>
> wrote:
>> During the first day of the QUIC interop in London, we discussed the
>> scenarios for a QUIC proxy. This is what I am looking at:
>> # Scenarios
>> ## Home Server Scenario
>> Home server establishes QUIC connection with proxy server "in the
>> cloud", publishes name in DNS with address of cloud server.
>> Client sends QUIC messages to proxy.
>> Proxy recognizes the SNI in Initial packets, or the Destination CID in
>> handhsake and short packets.
>> Proxy forwards packets to QUIC server as "datagram".
>> Home server treat packets as if received on UDP socket.
>> Home server forwards packets to proxy as datagram.
>> Proxy relays QUIC packets to the client.
>> Optional: QUIC server may use the "preferred address" mechanism to
>> suggest migration to a direct connection, bypassing the proxy.
>> Optional: local clients may discover the local server, without using the
>> proxy.
>> ## Hidden client scenario
>> Client establishes connection with proxy. Sends QUIC messages to proxy
>> as datagrams.
>> Proxy decapsulates the messages, sends them to destination server.
>> Destination server replies to proxy.
>> Proxy examines CID, determines which client it belongs to, forwards QUIC
>> messages as Datagrams to appropriate destination.
>> ## Onion scenario
>> Client establishes connection to proxy, then through that to another,
>> etc. This creates a tree of proxies rooted at the client.
>> QUIC connections are mapped to a specific branch of the tree.
>> Hidden server can similarly hide between several layers of proxy. Hidden
>> servers should not publish their address in the DNS.
>> May use an Onion DHT service instead (see Tor ".onion"), or in fact any
>> other mechanism. This is out of scope in this spec.
>> -- Christian Huitema
>> --
>> Masque mailing list