Re: [Masque] QUIC proxy scenarios

[David Schinazi <[e-mail]>]

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 <[e-mail]>
wrote:

>
> On 6/12/2019 7:39 PM, David Schinazi wrote:
>
> 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>
> .
>
> Looks good.
>
>
>
> 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)
>
> 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
>
>
>
>
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>