Re: [Masque] QUIC proxy scenarios

David Schinazi <> Thu, 13 June 2019 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01C9A120164 for <>; Thu, 13 Jun 2019 09:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 mcDYgh06MEWW for <>; Thu, 13 Jun 2019 09:48:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B84D12044D for <>; Thu, 13 Jun 2019 09:48:44 -0700 (PDT)
Received: by with SMTP id t28so19203126lje.9 for <>; Thu, 13 Jun 2019 09:48:44 -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=h2/d3cWiccNI+m+972lGQ2mdZSsYi2y/5eiPhtg5GY0=; b=VY3uCPy36tq9O77q0iwDWBVGF9zCEJ5cRjqkOuU0Zn55k59/uwIMcoZhT9T0nFr07r PxJAXQlKcMveEWt4LHen6dCo4C3AYJ6LRB+WiJK4h0jetO9TXKHRKM9NMZHx3VNYtk3B Bm6NAHw4+FUpE2vtWruzY17NAGh2U1LF403gpVSY+4ol4dR6XsO7Zdnkwbbd/LnVNXPb a8+WUpJ+RF1kX2sFFurQBdOuWXbGs+vbst16ed0EcPDlCTEl0u0hPyDzTV6UbNSAHewf ZETOA3o/gQkmD87wxjCNO2Q+rzcYykwxYuf5InQrDidDiOkpomDfW1vsvRuY78ejbxg1 3BqA==
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=h2/d3cWiccNI+m+972lGQ2mdZSsYi2y/5eiPhtg5GY0=; b=q4AhztQQMGc9hbJek7TDa81T4Y9fn23UuO9fpyFvu/jQZwnMiZl2Rx5UgDOJZYtDWq as5sIrRDfce6VpBk7gM6v2RvPl5u9ZRCCJUPSS3GbR1iepFNSniHB5VK6ZOHP/Q735bV fIm0IjkCnPMOuYy47d2D+nbwYiVznA4OQ9HG/1UuowkStigSACYmjqS2z+o3cNG/iGV9 FtygoVswuj+zHVgR3U+xMWqIqJ+a6bLdVl4dCyJVB0TOuv2ddx57YLpRyqcoPbv2ErkQ xkhZfIYhuGjX1/QXHYcQ1PA1vYWNAVkIlpKw5h4wR0xOnmlJyEacsU9ejCpu/RCuQOR7 Cp+A==
X-Gm-Message-State: APjAAAX2e6gfUvx5Ke3bpDfpmhDuO3V0Nd9ha1hWK2k3KKQMEStRbvOv 5FgxII6VNImQcxofKerupFLra5WzSf2dcSTbzsaZvg==
X-Google-Smtp-Source: APXvYqxfir7SXynfErdWfkqOa9G7hGRw1XKYPwo94hKSqbQpMYuqajbvdy0gabAEozfDFu/IN/hmOW0rQ+exWpSR4es=
X-Received: by 2002:a2e:82c5:: with SMTP id n5mr8406556ljh.175.1560444522306; Thu, 13 Jun 2019 09:48:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 13 Jun 2019 09:48:31 -0700
Message-ID: <>
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="00000000000071a1ff058b374d6c"
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 16:48:55 -0000

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 <>;

> 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
> <> 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
> <>
> .
> Looks good.
> I'm thinking as a next step we may want to flesh out the details of the QUIC
> proxy
> <>?
> (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