Re: Is "Version Greasing" a new benfit or a new obstacle?

Roberto Peon <fenix@fb.com> Fri, 12 April 2019 16:16 UTC

Return-Path: <prvs=9005e680f9=fenix@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 2EEEC1202F4 for <quic@ietfa.amsl.com>; Fri, 12 Apr 2019 09:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.336
X-Spam-Level:
X-Spam-Status: No, score=-1.336 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=QdgJ2stn; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=YH2fHmzJ
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 uDM-juqlQleB for <quic@ietfa.amsl.com>; Fri, 12 Apr 2019 09:16:15 -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 DFF621200D7 for <quic@ietf.org>; Fri, 12 Apr 2019 09:16:14 -0700 (PDT)
Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x3CGELDA005076; Fri, 12 Apr 2019 09:15:56 -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=AcFl6zLDFjOpoOYJUvHedLClhBV08NVyxryqFGIIcYc=; b=QdgJ2stnPko3vr5DL1oKlPIjSM+JNzaNOwbRUQr/cpGOTFrHST/JrG7ygJ56nZo3pYz3 2IVzsKm/BKqe2fw6Xd03wOicDqwKxMNk8vRIAQ33W7Jul+4Ss2NQXQNgs3R45bOxk9CZ i9JQhLQdMoTJwfdxqv8xEWMHw2TqhagUHXM=
Received: from mail.thefacebook.com (mailout.thefacebook.com [199.201.64.23]) by m0001303.ppops.net with ESMTP id 2rtfspa7mr-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 09:15:56 -0700
Received: from prn-hub03.TheFacebook.com (2620:10d:c081:35::127) by prn-hub04.TheFacebook.com (2620:10d:c081:35::128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 12 Apr 2019 09:15:53 -0700
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Fri, 12 Apr 2019 09:15:53 -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:X-MS-Exchange-SenderADCheck; bh=AcFl6zLDFjOpoOYJUvHedLClhBV08NVyxryqFGIIcYc=; b=YH2fHmzJOy52j3tAQ/Pn6W8e06doZRnNG/ywoQXY8DbcrEHrCTMhWJF9BfOF2qZG315EaNxxGU7JhU+oP1qwtB2mXYYQsCEAEyd8D3kNIPJDRmJbvlEAQ58FXWE2w3qut3NASjEItEd++dm/wGdxgeCfNBplA98gfU6rE92CP3o=
Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB3237.namprd15.prod.outlook.com (20.179.57.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Fri, 12 Apr 2019 16:15:51 +0000
Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 16:15:51 +0000
From: Roberto Peon <fenix@fb.com>
To: Christian Huitema <huitema@huitema.net>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
CC: "Gorry (erg)" <gorry@erg.abdn.ac.uk>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, "Border, John" <john.border@hughes.com>
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?
Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle?
Thread-Index: AQHU73o3xTufubPn9E2URSuto2uLa6Y1JwYAgAB3W4CAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQ3wCAAACXAIAAAIaAgAAEgoD//4tNAA==
Date: Fri, 12 Apr 2019 16:15:51 +0000
Message-ID: <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com>
References: <5CADADDD.7010005@erg.abdn.ac.uk> <EBF1BF30-62A5-4659-8AEC-0D5B3F2D65C6@fb.com> <BL0PR11MB3394294313F8F54A3D0CF4A3902E0@BL0PR11MB3394.namprd11.prod.outlook.com> <CAN1APdcm0hnT_Mu7D7x5QM6pApOQw1RdWCBkgY16bd5YWNtFkA@mail.gmail.com> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <CAN1APdeSF0-_N=mb1xkoe_qLwoVqP+X9_Wawi=Zu__6wdHtbOQ@mail.gmail.com> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <CAN1APde2SO6fkNzyznbv2-xNuXkkuC=bN3p8xRgwmRAmsZxrgA@mail.gmail.com> <MW2PR2101MB104902B6BC7C67D8688EA852B6280@MW2PR2101MB1049.namprd21.prod.outlook.com> <MW2PR2101MB104996C29680DF7B79230C8CB6280@MW2PR2101MB1049.namprd21.prod.outlook.com> <CAKcm_gMwcwZ0VzK4vDt-sCQctHVrwOm9ekPPi3O3Y2UnRrZaBw@mail.gmail.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net>
In-Reply-To: <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
x-originating-ip: [2620:10d:c090:200::1ab6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ca072af8-96be-430e-fd7e-08d6bf622205
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR15MB3237;
x-ms-traffictypediagnostic: BYAPR15MB3237:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR15MB3237C58618531B73C4777895CD280@BYAPR15MB3237.namprd15.prod.outlook.com>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(366004)(346002)(136003)(199004)(189003)(6486002)(6246003)(66574012)(6436002)(54906003)(2616005)(11346002)(6116002)(229853002)(6306002)(53936002)(2906002)(25786009)(110136005)(6512007)(58126008)(36756003)(4326008)(486006)(97736004)(33656002)(68736007)(54896002)(46003)(6506007)(446003)(53546011)(186003)(102836004)(5660300002)(76176011)(105586002)(14454004)(81166006)(81156014)(8936002)(71190400001)(106356001)(476003)(99286004)(316002)(82746002)(478600001)(256004)(7736002)(83716004)(71200400001)(14444005)(8676002)(86362001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB3237; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: BJG9BdmBO+zkzQjg1vl/71aXW/FEBpzgITOJ8MFSpRHyQCLZOWuRPsB3xwW4fklfdYLJxhMxZoBDqVL/kt1mSELMILoV341T+U7dY1eTsOuFv+BIwlmMy13vYhufiTnB5Y78VkUOnlnMXH1UNNOe4Vl/7mYnc6Y03SjjtnF5LklKjvkUamErm+df5EUBYd98Yj6AIeOn7dHV2x0C68wV+SuRi4QWe82A3EJSFEkMxa4ELyYlO6SopESOIpDuveO4t3M0KwfotOKGaSWamuuIzbzeP3j3wNf72Q99LXQzS3hp6hOcP+U4Q3DPFGmpXmo72GUW7vpC39BVwE/ekls8Hn6qKgCNnda6Ya9ZPGgBb4PrLtkLfE9Qeje2VJqVN+ipnTMyS3d8j2FxGdEuse1mLjdts1dIshyT0+NS3kDK+x0=
Content-Type: multipart/alternative; boundary="_000_9C6D92FF763548BDA65BFAB4B544476Dfbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ca072af8-96be-430e-fd7e-08d6bf622205
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:15:51.6280 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3237
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-12_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FiNWHnBna-m0LNIqaDwVScmHAr8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Apr 2019 16:16:17 -0000

For any large deployment, I suspect they’ll need LB.

For most kinds of LB-ing, I’d expect the LB system to either directly or indirectly be involved in choosing/vending connection IDs.

If it is involved in vending/choosing connection IDs, it can encode version information into the CID.

-=R

From: Christian Huitema <huitema@huitema.net>
Date: Friday, April 12, 2019 at 9:13 AM
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: "Gorry (erg)" <gorry@erg.abdn.ac.uk>, Roberto Peon <fenix@fb.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, "Border, John" <john.border@hughes.com>
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?



On 4/12/2019 8:57 AM, Ian Swett wrote:
From: Praveen Balasubramanian
...
Version greasing will create problems for DDoS protection. The DDoS protection middlebox will have to treat all traffic with unknown version numbers as plain old QUIC and rate limit it. Any solution that requires per connection state to track version numbers doesn’t scale. Especially in the cloud scenario customers bring their own web servers so this makes any opt-out solution not good enough. So I do think this is an obstacle for many deployments.

Don't we have an example of middle-box ossification just there?

Praveen's example points to the perils of the "shortest path" approach to middle-box design. Taking the shortest path means finding something that works now, and once you have found it deploy it without worry about consequences -- which very often include ossification. If the DDOS protection box looks for "QUIC versions that it knows" and just rate limits the other types of packets, then the box will by design prevent deployment of versions that it does not know.

I assume that big organizations like Azure will update their protections once a new version is out, but the experience shows that many other organizations don't. And even when they do, the focus on published versions will block experimenting with new versions, not to mention interfering with other features like connection migration. I take Praveen's example as an argument why we should in fact standardize version greasing, precisely to avoid this "shortest path middle-box design".

In the case of DDOS protection, I will point out that DDOS protection also needs to work with short header packets, which do not carry any version number. In order to avoid DDOS by short header packets, the boxes have to be able to distinguish between packets that belong to authorized connections and packets that don't. And if you do that, then you don't really need to look at the version numbers, you can simply rely on the invariants.

-- Christian Huitema