Subject: Re: [Masque] QUIC proxy scenarios

From: David Schinazi <[email-masked]>
Date: Wed, 12 Jun 2019 19:39:21 -0700

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 <[email-masked]>
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 <[email-masked]>
> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/masque
>>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Jun 2019 20:16:23 -0700

On 6/12/2019 7:39 PM, David Schinazi wrote:
> <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.
>

Looks good.

>
> I'm thinking as a next step we may want to flesh out the details of
> the QUIC proxy

Yes. This is something that I want to start implementing soon, but first
I need to implement ESNI in picoquic, which will probably take a week.
Then I will need to align to draft 21 when it comes out...

There are a couple drafts that we may want to also consider, notably
Mirja's requirement draft, and the load balancer draft -- many common
points between a proxy and a load balancer.

I have been thinking about the management of connection ID. The big
question is whether we want to have a proxy serve multiple home servers
or home clients (I believe the answer is yes), and also whether the home
server wants to be able to use multiple proxies. The latter requirement
drives some additional complexity.

The basic scenario will be:

1) Client and proxy negotiate usage by the client of a set of CID

2) Client announces one of those CID during handshake

3) Peer sends packet to proxy with CID, proxy relays to client

4) Client sends the other CID to the peer in NCID frame

5) Peer picks one of those when migrating to new address

6) Proxy recognizes CID and routes to client.

7) Peer sends RETIRE CID frame to client

8) Client tells the server that retired CID are not useful anymore

9) Client cleans the connection, and tell the peer to retire all CID

The client (in some cases) may want to use migration to establish a
direct connection and bypass the proxy. That migration will consume some
of the negotiated CID.

If we want client (home servers) to support several proxies, then the
same set of CID must be negotiated with multiple proxies. This implies
something like:

a) Client proposes a set of new CID to proxy1

b) Proxy1 checks whether the CID collides with something used by another
client, marks the colliding ones as rejected

c) Proxy1 replies with the accepted subset

d) Client proposes accepted subset to proxy2

e) Proxy2 does its own checks, reply with a subset of confirmed CID

f) Client is polite and retires the CID rejected by proxy2 from the set
managed by proxy1

Proxies may want to impose some minimal CID length.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Thu, 13 Jun 2019 09:48:31 -0700

I was thinking among the same lines. I think their are three ways the proxy
can vend CIDs to clients:
(1) server says minimum length is X, clients generate them pseudo-randomly
and we hope to avoid collisions
(2) server vends individual CIDs
(3) server vends a scheme, e.g.: CID is AES_ECB(key, prefix || client
chosen bytes) and server tells client key and prefix and client can
increment the client chosen bytes for each new CID

I think (1) should work well enough in practice. Today Google QUIC CIDs are
64bits randomly chosen by clients and we operate at massive scales without
collisions being an issue yet.
(2) and (3) unfortunately break down when you have multiple servers

But if we want to handle collisions while assuming they're rare, using (1)
with a way for proxies to reject CIDs should work.

On Wed, Jun 12, 2019 at 8:16 PM Christian Huitema <[email-masked]>
wrote:

> <https://github.com/DavidSchinazi/masque-drafts/pull/2/files> and added
> it to the document.
> Yes. This is something that I want to start implementing soon, but first I
> need to implement ESNI in picoquic, which will probably take a week. Then I
> will need to align to draft 21 when it comes out...
>
> question is whether we want to have a proxy serve multiple home servers or
> home clients (I believe the answer is yes), and also whether the home
> The client (in some cases) may want to use migration to establish a direct
> connection and bypass the proxy. That migration will consume some of the
> negotiated CID.
>
> If we want client (home servers) to support several proxies, then the same
> set of CID must be negotiated with multiple proxies. This implies something
> like:
>