Re: [Masque] QUIC proxy scenarios

David Schinazi <dschinazi.ietf@gmail.com> Thu, 13 June 2019 02:39 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 8831112016B for <masque@ietfa.amsl.com>; Wed, 12 Jun 2019 19:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 XCggyi4i8Bev for <masque@ietfa.amsl.com>; Wed, 12 Jun 2019 19:39:35 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 072DF12008B for <masque@ietf.org>; Wed, 12 Jun 2019 19:39:35 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id 16so16927401ljv.10 for <masque@ietf.org>; Wed, 12 Jun 2019 19:39:34 -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=ywqxqUN3yYEzvsKyqIiLxXa5tkzUs5wZFPRnucb4BeY=; b=YZwXZl2CT14DU7lrgQ1i4/yuoQCLvDzrfP3mbdnVJEagJhCoNgT0hWw9fFcxFs0dx2 mXbH2AbRVXuenW1vNnlcLZUMglcweoWL4HSGQyRwSXbjcmaAchhR0hfLlh9dhOYyLRXd YVbtjttw0om2oe+8ZxuRG5HKPyGmWvKE7ckiYmWLX4hZB1cqXDZXloOn5yPebor4LRew iqU8Sf3AKW8gHBnD3VM23Mw3wFea0rbGNo4pJrvy3ZftcJRQ/AZD4mkeaUXU00uXAG1j 2sEy/Du9wKxt7NNw7IL59QSSBmxiXDPMgta4OTzKHsEvCAXi6CnKGTPFhETt51v3Beum 0EOw==
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=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: <273b9eaf-5d9d-949f-7d43-95293248f43f@huitema.net> <CAPDSy+5neR6j7VCeXs=uqTWDP8EwmFGjW4DCw3t3b8tFMp7AdA@mail.gmail.com>
In-Reply-To: <CAPDSy+5neR6j7VCeXs=uqTWDP8EwmFGjW4DCw3t3b8tFMp7AdA@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 12 Jun 2019 19:39:21 -0700
Message-ID: <CAPDSy+4Dj5-nnKDCRAdch=MgwgZ=73EjFvWxwwgLrqCOB7NHLg@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: masque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a3ddb8058b2b70d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/oL1gE2pzl4B1Q5gCteqWP_Ym1d4>
Subject: Re: [Masque] QUIC proxy scenarios
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: 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
<https://github.com/DavidSchinazi/masque-drafts/pull/2/files> 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
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html>;.

I'm thinking as a next step we may want to flesh out the details of the QUIC
proxy
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html#rfc.section.5.4>?
(e.g., how to negotiate its use and to compress QUIC connection IDs)

Thanks,
David


On Tue, May 21, 2019 at 3:59 AM David Schinazi <dschinazi.ietf@gmail.com>;
wrote:

> 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!
> https://github.com/DavidSchinazi/masque-drafts
>
> 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 <huitema@huitema.net>;
> 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
>> Masque@ietf.org
>> https://www.ietf.org/mailman/listinfo/masque
>>
>