Re: Exercising Version Negotiation
Subodh Iyengar <subodh@fb.com> Thu, 22 March 2018 17:22 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 57FA912EC81 for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 10:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=Gehz6DRO; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=anWlLkg9
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 I-dXxUg8KcUb for <quic@ietfa.amsl.com>; Thu, 22 Mar 2018 10:22:40 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 F0A31126D45 for <quic@ietf.org>; Thu, 22 Mar 2018 10:22:30 -0700 (PDT)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w2MHJ07R023847; Thu, 22 Mar 2018 10:22:27 -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=N20fIODanNG7Ffmy8f44N3jifuiBE5G4LNQI+XPUc0Q=; b=Gehz6DRO4JU4PDjXXWsL5EVv5i2DAg0k9Jbqdd9afr7miNubcsTe40q/gpy40/coFeQZ YKDBQf8OeoJVjrDa575d6PKC7rT6u970AU7pQ+7abUE0ObXb9iIzqwULb2z4fZz31JnX 7NBI331JlcVUtGcWsCbmxQjn9g1HrAviScs=
Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2gve6f0jsj-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2018 10:22:27 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Mar 2018 13:22:26 -0400
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=N20fIODanNG7Ffmy8f44N3jifuiBE5G4LNQI+XPUc0Q=; b=anWlLkg94+gLhgWLda1TmWBH17I6N7h+TvjFD5tIfIxnb2rM29V1Bsj8VA22wYNgyEZq1jBw0oiSlvs9oLn7zRYI16zKBx2yPmw1+iYGELwlAPUGFkfSIxhR6ptD3Zl8IGx2Rn0jwAkWCss2bu6qWkdo46MafRkDQbJBy3QgNqY=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1215.namprd15.prod.outlook.com (10.175.2.145) 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 17:22:24 +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 17:22:23 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Ian Swett <ianswett@google.com>
CC: Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>
Subject: Re: Exercising Version Negotiation
Thread-Topic: Exercising Version Negotiation
Thread-Index: AQHTwdX66S1uG5wKa0SeezpL/OgUTaPcb5CAgAAAlz6AAAZ5AIAAAJNZgAABiCeAAAcsAIAAAH9J
Date: Thu, 22 Mar 2018 17:22:23 +0000
Message-ID: <MWHPR15MB18210CE4685F879B64EED3ACB6A90@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> <MWHPR15MB1821A942282B917BB786913BB6A90@MWHPR15MB1821.namprd15.prod.outlook.com> <MWHPR15MB18212BAC58BEB251940C11FAB6A90@MWHPR15MB1821.namprd15.prod.outlook.com>, <CAKcm_gNYr8VGrxcTQNRfJ3P6=kiCiax6rOCkBw5S3zgS85aUeA@mail.gmail.com>
In-Reply-To: <CAKcm_gNYr8VGrxcTQNRfJ3P6=kiCiax6rOCkBw5S3zgS85aUeA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c092:180::1:daa7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1215; 7:QDnFyK7cseiApW8AJUqadjH5WK+iIuykdyNToqbUmU9rXcJ3AxRSGRRAk5CMU8AUGdfDPj2cY14++VrP4hZabYLbamBjtaHToMRrJVZo1ReypHohYV/49Ct2vMvotGaKaCHu9Un4iBWxevGgc+naj8s5Qo7GjAHg6RxNJUPUe903yS8cYhRFxZWwNYZt7moQ4oOfMOy5GuQ19lBg+rGWAoWp7nrhei2cTwww38qfXgSec/KLBrXA7HmRM9MMMG22; 20:M6I8QpfNwAVKwjlQtZSbAiseisRZmLKo9V3mCp9u5TX4J0aDS3r1xR7C2U4z2Mk9kqkywTlOPqTO+P4B/LmtpqwffOnc949CrIjkSLi/NPYUG2w2Nq2zfeIlOTh+xbcPKwUT7GCHb7WHBPgvtbZHiVxJHwFQux1gzDBaRZYVGgA=
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(396003)(39380400002)(189003)(199004)(33656002)(561944003)(93886005)(186003)(14454004)(55016002)(6436002)(6246003)(9686003)(54896002)(236005)(53936002)(102836004)(5250100002)(7696005)(229853002)(99286004)(446003)(11346002)(76176011)(81156014)(316002)(53546011)(8676002)(54906003)(46003)(3660700001)(3280700002)(3480700004)(74316002)(2906002)(7116003)(6606003)(8936002)(25786009)(478600001)(6116002)(4326008)(2900100001)(68736007)(6916009)(5660300001)(105586002)(6506007)(81166006)(7736002)(19627405001)(86362001)(106356001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1215; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 017f4171-2556-49b0-ce04-08d5901979e0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1215;
x-ms-traffictypediagnostic: MWHPR15MB1215:
x-microsoft-antispam-prvs: <MWHPR15MB1215D8F4FC1911698DFC60D4B6A90@MWHPR15MB1215.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(67672495146484)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(3002001)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR15MB1215; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1215;
x-forefront-prvs: 0619D53754
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 2MQ6OPk7y0W+kqAAVl8Hc0Ds3QfaWrza9NfPUy4oMa8ReEJ4BNRw3gn000pRfPTcMXhNxvtkE+TSeix0BxcnO7XzpOaKkt9Dv227OOb4Yfj/pc+1/in9QV5TzO5Vqh/GETHDMWveFYbi+0ZwyVfStLPmLtRwolzYpKpXmoqWnEcFgyXsTUGOTKA0m1k4qpE44l0nDXdGBVIqnlLC6t12AmVeb/LsmGo0tL9EV6DLxJsnBKkr40iU8DT58WBsKnI7g8bArMhd1qatBVLZ8X2WX/VorSTwoNxRYsuW/Cn0j3xYEdjmWM0G0IT3tOQRIOEAc/L1xSQgKwrqkaLn3v/Gew==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18210CE4685F879B64EED3ACB6A90MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 017f4171-2556-49b0-ce04-08d5901979e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 17:22:23.4432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1215
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-22_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TTan0BTmfE2eKbJAGpSvAVq-mD8>
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 17:22:44 -0000
> Just curious, what is the use case for this? I assume the server still controls its own connection ID and would prefer to keep it consistent for routing purposes. I feel bad for hijacking ekr's thread. But you can have an algorithm that generates multiple connection ids that route to the same server. We can discuss the use cases for this on another thread. !Ekr ________________________________ From: Ian Swett <ianswett@google.com> Sent: Thursday, March 22, 2018 10:18:26 AM To: Subodh Iyengar Cc: Eric Rescorla; IETF QUIC WG; Roberto Peon Subject: Re: Exercising Version Negotiation I think you were poking holes in my suggestion from this morning :) And I agree that's an issue. !Ekr On Thu, Mar 22, 2018 at 12:53 PM Subodh Iyengar <subodh@fb.com<mailto:subodh@fb.com>> wrote: Oh sorry i completely misunderstood what you're saying, ignore my previous email. Subodh ________________________________ From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of Subodh Iyengar <subodh@fb.com<mailto:subodh@fb.com>> Sent: Thursday, March 22, 2018 9:49:53 AM To: Eric Rescorla Cc: IETF QUIC WG; Roberto Peon Subject: [Potential Spoof] Re: Exercising Version Negotiation 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<mailto: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.
- Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Eric Rescorla
- RE: Exercising Version Negotiation Mike Bishop
- Re: Exercising Version Negotiation Spencer Dawkins at IETF
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Ian Swett
- Re: Exercising Version Negotiation Subodh Iyengar
- RE: Exercising Version Negotiation Lubashev, Igor
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Ryan Hamilton
- RE: Exercising Version Negotiation Lubashev, Igor
- Re: Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Christian Huitema
- RE: Exercising Version Negotiation Mike Bishop
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Ted Hardie
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Philipp S. Tiesel
- Re: Exercising Version Negotiation Christian Huitema