Re: [Masque] QUIC proxy scenarios

Christian Huitema <huitema@huitema.net> Thu, 13 June 2019 03:16 UTC

Return-Path: <huitema@huitema.net>
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 7641E120177 for <masque@ietfa.amsl.com>; Wed, 12 Jun 2019 20:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.013
X-Spam-Level:
X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tXyojo0BOMxV for <masque@ietfa.amsl.com>; Wed, 12 Jun 2019 20:16:34 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29213120169 for <masque@ietf.org>; Wed, 12 Jun 2019 20:16:33 -0700 (PDT)
Received: from [66.113.192.14] (helo=xsmtp06.mail2web.com) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1hbGE2-000ADK-Ox for masque@ietf.org; Thu, 13 Jun 2019 05:16:32 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtp (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1hbGDy-0003iO-0i for masque@ietf.org; Wed, 12 Jun 2019 23:16:27 -0400
Received: (qmail 20400 invoked from network); 13 Jun 2019 03:16:23 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <masque@ietf.org>; 13 Jun 2019 03:16:23 -0000
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: masque@ietf.org
References: <273b9eaf-5d9d-949f-7d43-95293248f43f@huitema.net> <CAPDSy+5neR6j7VCeXs=uqTWDP8EwmFGjW4DCw3t3b8tFMp7AdA@mail.gmail.com> <CAPDSy+4Dj5-nnKDCRAdch=MgwgZ=73EjFvWxwwgLrqCOB7NHLg@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <05fc564e-6eef-9663-4991-7de735434659@huitema.net>
Date: Wed, 12 Jun 2019 20:16:23 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAPDSy+4Dj5-nnKDCRAdch=MgwgZ=73EjFvWxwwgLrqCOB7NHLg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F67C0BC9BCDA2782616C9577"
Content-Language: en-US
X-Originating-IP: 66.113.192.14
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.192.14
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Q9DGisTdy29Heef28Cu3sipSDasLI4SayDByyq9LIhVI9tibm/OsjBn A3ikzdCcCETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDLFrcqaxDIU8vFldGbCR/osRX qYbtEQV1z/L435ZRxFRcyUiLYXi9Oqr0cPRcN/iU5EYKk9ePgXGbt5xuMhAKm1ZiUSAofzQZyw1N o2+95uScbEFMQEHcY1gOuErbvRTKK5uN4Nhp7uOkWlmbQCkb20TPhU3goSfeZ3FRZeTXp/1uwfTD UUz/IMrauEP0IARAT9bZnTCIQ4C96g4mKe6NiGYbkIWSKodQEiewuMhOtmK5/BpNYAQEvig3GMx7 MpXZ3WOGcz8xu9rZctX8sgTNoiY/SOc5OwzuESxfsyWF3826CT9M1stWoUTybRqU5J7031/E3ahF 5MMcDI7KdpjQKU5lRZ094UyTENZdfY1zhq4hEWyJzIkwSFAW0Pw8uiKe79Ir/Me7RAJ5cVVkcq6a It2zYvPTd+DTpPBZoZwGv5Fn6p9MIdoVmwQd+5hcJZ3T6J1fhOzjF0b4LXcjJZ5louZdkd+OFbW3 tZOhTHnfaNaUwbkUC3efQxX081Uu4CHRXS97PvK9t7qTKwm0TQlPrYe5ALa+6loncFiHKXZysSaD LT4PBIvkxZFg1HsGn09MNQSIKMznUZcFqGs41thPHj3KyNX+kDcmnP+9Ez78VNaLBDMrD7q/cJog wbqzsuokhGmaOYL/X8rhoXFOgTB1ujSxnqQ5eTkkXXEhnQlrl1oKbAAMMhWe/rIDnPorDxie/ymH KVf3AgfEiVP9XNrw1B7Oiwo2XvIlW0xK+GaMnDxO8iSbXbehPAyorygrFjnWuVGBtJ1DsK23UcLY dhI56G6gIHbmXm17lUweLCEIWKlP9DbK43kvDm9XK01IC3BpIRFsicyJMEhQFtD8PLoink2oV0uz 1ws450298AxBBxbzOWlxaUzOk1oSeJNWp1+1XkgMLOZvYCakZp5atAhVig==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/C_fA1z__6Cnw74I3fQE7P5K9fok>
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 03:16:37 -0000

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