Re: Exercising Version Negotiation

Subodh Iyengar <subodh@fb.com> Thu, 22 March 2018 16:50 UTC

Return-Path: <prvs=66190ed8da=subodh@fb.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7C31242F5 for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 09:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=brh8O7Di; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZD7OZ/Ov
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 qNY6t0H8-qvg for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 09:49:58 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 2C432120726 for <quic@ietf.org>; Thu, 22 Mar 2018 09:49:58 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2MGmjoS024433; Thu, 22 Mar 2018 09:49:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=MQDZpgmlfcM0BmJZaROd6iLbT1nLdFboufMIBdjC05Y=; b=brh8O7Dik/ljYBi9JZkMfaHtL1gj4+76f1IHYGI4XFpn18mv2PmsVOrmh4wJfurHBZpM 52UEKxbFmPgyUifhUKK+QKvFptcVCDFXI4HrNzt5qPeLI/FaxBiOYCcT9khfOgI7aXXJ qGHALdz+Y67Z8iK9vJuD8GN9pMhVeqEeMXc=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2gvf7nr8rm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2018 09:49:57 -0700
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Mar 2018 09:49:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MQDZpgmlfcM0BmJZaROd6iLbT1nLdFboufMIBdjC05Y=; b=ZD7OZ/OvlQl5/qQAd0BltAySBQJ1FLgcJORXpYWNfFrtsZwqNdFOYDCP69pj1NBJzU7jcVRcNvzfkjySy7ppggGX/ARCoHYXB1raxlAblJjgax/44MScxUaZfrMFecdN5yzD1X7jeyFdnRFy1X91LO9QOq7kTRSqTbGpqzlIPJI=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1232.namprd15.prod.outlook.com (10.175.2.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Thu, 22 Mar 2018 16:49:54 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b431:b2fb:1912:34d8]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b431:b2fb:1912:34d8%17]) with mapi id 15.20.0588.017; Thu, 22 Mar 2018 16:49:53 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Roberto Peon <fenix@fb.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Exercising Version Negotiation
Thread-Topic: Exercising Version Negotiation
Thread-Index: AQHTwdX66S1uG5wKa0SeezpL/OgUTaPcb5CAgAAAlz6AAAZ5AIAAAJNZ
Date: Thu, 22 Mar 2018 16:49:53 +0000
Message-ID: <MWHPR15MB1821A942282B917BB786913BB6A90@MWHPR15MB1821.namprd15.prod.outlook.com>
References: <CABcZeBMv5BqZOtgVA2wfqaaGCd94gcNPB9bTXkrvNXXRveU8wA@mail.gmail.com> <BY2PR15MB0775F2D1CDEA831B64491A67CDA90@BY2PR15MB0775.namprd15.prod.outlook.com> <MWHPR15MB18211F884674B6FC01BCD2E9B6A90@MWHPR15MB1821.namprd15.prod.outlook.com>, <CABcZeBN8hN7w0NsRBshkhu9vEwiq5_AbaTBBv7arKY5C=yv0oA@mail.gmail.com>
In-Reply-To: <CABcZeBN8hN7w0NsRBshkhu9vEwiq5_AbaTBBv7arKY5C=yv0oA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:67c:370:128:3cc1:8c99:1ed7:bcc4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1232; 7:kx6f855eE5o6cXJIO+c+51our5bAKYHodi3L+JWSx4Pv4xhCPEMhGdcE8NMF98Klbkal0jFCw1VhxGQbCTXKiReUc1odlaIfZCFdefK6t7rG6lvTbXt4flMHlrvvg0jW5z45pfAHXG6NLh9HkVuP6ATDPQ5Mpzr7o9QHAbZt9UOCO25yeYHk3GNBsRLBAUFWNfAxLeSQJHX9kjThS7nPguuxOBGjeI3U9EOD1L1O92mum8k0P5F5Rs9sbvWw+W61; 20:6lqoFMqU3AaRFry8ZVTm8CDOsPxn2YPUxJ6s8WDVfnIfb/YYWXamG/OECr8OZmE2g/cAfL3X4vX22Ub8f/K2IsNluM7gEBY1M95ETEAW/wsrx8Bu6zIXXqLID5PleNjvjc2L9kJ4USQiNLG9eg6pPudiDN2cgFCp/6dtUKzkWGw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(396003)(366004)(39380400002)(189003)(199004)(74316002)(2900100001)(236005)(6506007)(53546011)(76176011)(86362001)(81166006)(99286004)(3660700001)(81156014)(8676002)(7696005)(8936002)(6116002)(186003)(54906003)(446003)(2906002)(102836004)(5250100002)(93886005)(14454004)(478600001)(6606003)(316002)(33656002)(561944003)(46003)(53936002)(19627405001)(6916009)(105586002)(97736004)(106356001)(68736007)(55016002)(6436002)(3280700002)(25786009)(3480700004)(7736002)(4326008)(9686003)(6246003)(7116003)(5660300001)(229853002)(54896002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1232; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 17825dcd-1899-46be-9554-08d59014efb3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1232;
x-ms-traffictypediagnostic: MWHPR15MB1232:
x-microsoft-antispam-prvs: <MWHPR15MB1232CF1797F505D66E8B42DBB6A90@MWHPR15MB1232.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(67672495146484);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR15MB1232; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1232;
x-forefront-prvs: 0619D53754
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 6jpJZEO09shsf9bTBvVZkaebPaXve2KcLyWSXg1JqLeG2caeW81R22aihwxSBQzABA5myugPDwmA2mpQJUJuSBcvgSUBKvG9ZjgicBODA+YSmIi3qR1LBy7RuiB8p96IdyOpoRUnhJvH0t1sU8r5RXbAxbgSRZQe9MqYO/lueCV4gKGLcodoTSWUFyFo0LkVPI5r7r7pqYFcsvJ3fKrKMTjk4PDSvp19iRSdn2uaEBNCcGvX32tLzSiPPcp3GIc9xVTjglg6vNeSFaOZx6WBtJfdrvD0cxZwTby/Bl/VhfPqLprXnEvr+p2fyzJttEypQIeRhM6W7WvOfGiRMp6JkQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821A942282B917BB786913BB6A90MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 17825dcd-1899-46be-9554-08d59014efb3
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 16:49:53.6343 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1232
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-22_08:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z1jcx7j_DkiD3crpRPBtYgpAx5Q>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 16:50:01 -0000

My understanding is that your proposal says that the interpretation of a particular bit in the public header is determined by the version, i.e. the server and client will negotiate a particular version if they need a spin bit. What I was saying is that if that is true, the middlebox needs to look at the negotiated version and hence creates the aforementioned concerns.


Subodh

________________________________
From: Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, March 22, 2018 9:45:14 AM
To: Subodh Iyengar
Cc: Roberto Peon; IETF QUIC WG
Subject: Re: Exercising Version Negotiation

Hi Subodh,

I'm sorry, I'm not following you. I'm not talking about the spin bit here, just about exercising the regular negotiation function.

-Ekr


On Thu, Mar 22, 2018 at 4:26 PM, Subodh Iyengar <subodh@fb.com<mailto:subodh@fb.com>> wrote:

I don't think using version negotiation is as simple as it seems:


  1.  My understanding is that the current draft and the data that was shown doesn't even look at the handshake negotiation and only looks at short headers.
  2.  Short headers have no version. So to use version negotiation correctly as a signal of the spin bit, the middlebox MUST intercept the handshake negotiation.
  3.  Each 5 tuple could potentially have multiple connections and we are apparently designing for that use case, so the middlebox needs to use connection id
  4.  Some implementations are thinking of changing connection ids very frequently, maybe in each RTT.


Given these are we saying that when using the spin version you must not change the conn id per RTT so that the middlebox can observe the spin?


Subodh

________________________________
From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>
Sent: Thursday, March 22, 2018 9:19:57 AM
To: Eric Rescorla; IETF QUIC WG
Subject: [Potential Spoof] Re: Exercising Version Negotiation

Love it. This is a great idea!

I'd suggest being more agressive with deployment,  e.g. recommend that servers negotiate speaking version +1 to more like 50% of the clients, and swap guid/ip mappings to have clients formerly using +1 switch  to -1 and vice versa weekly or so.

-=R



Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: Exercising Version Negotiation

Following up on the discussion at the mic, I do think it is useful to exercise the VN function, but I don't think it's useful to have those versions be different, because that creates perverse incentives.

Here's what I suggest instead: create two versions (we can call them QUIC v1+i  and QUIC v1-i), each with its own code point [0]. They should be essentially identical except for two trivial differences, intended to ensure that if you screw up version negotiation, you get failed interop.

- The constant in the handshake salt (5.2.2)
- The HKDF expansion constants

I suggest we handle each of these by just inverting the bits.

We would then suggest to people that they somewhat randomize their preferences (e.g., 99% of the time prefer v1+i, 1% of the time prefer v1-i). This will almost always result in matching versions, but will occasionally result in a mismatch, thus forcing us to test VN.

-Ekr

[0] Obviously we can do this for draft versions. We just say that the two versions are
ff0000XX and ffffffXX.