IETF Logo Mail Archive

RE: Long Headers and Version Negotiation

Mike Bishop <mbishop@evequefou.be> Fri, 05 January 2018 22:58 UTC

Return-Path: <mbishop@evequefou.be>
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 9E98A12D833 for <quic@ietfa.amsl.com>; Fri, 5 Jan 2018 14:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
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 MmZhzbagH_Xs for <quic@ietfa.amsl.com>; Fri, 5 Jan 2018 14:57:59 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B58126BF6 for <quic@ietf.org>; Fri, 5 Jan 2018 14:57:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=36ch1Lx0WU5G7KN66TgOLbXqFx5QruH1n6m8WsJdMuk=; b=RE7KrnIyLh2nmbsksPx04fdqES0v4MIqThs2CqQDdIdc/ywUIU35UMFdD45TGClz0XiK/7MYa0rUO1D3/9/zGLc1TPodh4eY9bdd8RCIQbjFXZHpoWKKhiUWzcmvJdWiSussML0SoOnRkzsTL1QTgOfIjmgIJTFYHwYodYoJiz4=
Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2431.namprd08.prod.outlook.com (10.169.203.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 5 Jan 2018 22:57:55 +0000
Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0386.006; Fri, 5 Jan 2018 22:57:55 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Martin Duke <martin.h.duke@gmail.com>, Nick Banks <nibanks@microsoft.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Long Headers and Version Negotiation
Thread-Topic: Long Headers and Version Negotiation
Thread-Index: AQHThnX9L2LzHEWFXk+2QU3wPj2mn6Nl4SWAgAABdICAAAFbQA==
Date: Fri, 05 Jan 2018 22:57:54 +0000
Message-ID: <MWHPR08MB2432DF994B55055CA2418D97DA1C0@MWHPR08MB2432.namprd08.prod.outlook.com>
References: <CAM4esxRroE5rOXEHgqJ-_5Vdm-=odN7VmWBweKQgTnT5pU87XA@mail.gmail.com> <BN6PR21MB01788D37BFE5700EB00F392AB31C0@BN6PR21MB0178.namprd21.prod.outlook.com> <CAM4esxRvb5-34kPGo4EHe00H-xC=dsi5zhy41z1K883QLurT-Q@mail.gmail.com>
In-Reply-To: <CAM4esxRvb5-34kPGo4EHe00H-xC=dsi5zhy41z1K883QLurT-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR08MB2431; 7:cWLfmjLUMxFDuxPeNviVInI6MxtDBhtplcKwAOKeZ7RnS1fD+eO0cAhysSLqEY6edTBxdj5/PVSKCSoOOFlv2HJOnj+fhzFvpkj4qdNUa813cyG42LvjoZVmSbjeblMVNB74RDGKHMcG5R6PgkGnmIDsUWqO+CwWj0T+XzWDCv7cFFdIaQSKQn7MvxlcVLnvxLGxKHiXbD2xveEyBprQxx540l54bjvs89fWYZHYtwSQSlb1mJgo8ExKHo2JTzQf
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: be4476cf-2c07-4157-68bf-08d5548fc1ce
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:MWHPR08MB2431;
x-ms-traffictypediagnostic: MWHPR08MB2431:
x-microsoft-antispam-prvs: <MWHPR08MB243163684D054B349B8EF7D6DA1C0@MWHPR08MB2431.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(189930954265078)(219752817060721)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2431; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR08MB2431;
x-forefront-prvs: 05437568AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(39830400003)(39380400002)(189003)(24454002)(199004)(14454004)(2906002)(86362001)(8676002)(19609705001)(25786009)(478600001)(606006)(81156014)(7696005)(229853002)(81166006)(53936002)(105586002)(790700001)(6116002)(2950100002)(53546011)(97736004)(106356001)(110136005)(6246003)(316002)(45080400002)(8936002)(74482002)(68736007)(102836004)(8666007)(3280700002)(74316002)(77096006)(3660700001)(1511001)(6436002)(7736002)(33656002)(55016002)(54896002)(76176011)(66066001)(6506007)(6306002)(4326008)(5660300001)(3846002)(39060400002)(9686003)(236005)(99286004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2431; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: /tCpZ/Wa09Cvx4ucTmWoUcv6yWeL7Npomx7hBqRoX6T7fUJGpZmaHJLgmniP4r0Kek7Cnwz/eYiGduWQ8Qs2Tw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432DF994B55055CA2418D97DA1C0MWHPR08MB2432namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: be4476cf-2c07-4157-68bf-08d5548fc1ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 22:57:54.9504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2431
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_OyRkaq9ZItilGr7ZqJgehEMOdo>
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: Fri, 05 Jan 2018 22:58:03 -0000

This is actually beneficial, albeit a corner case – if the Initial packet is lost, but the version is unknown, then the 0-RTT packets will still provoke the Version Negotiation packet and the loss doesn’t induce an RTO.

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:52 PM
To: Nick Banks <nibanks@microsoft.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Long Headers and Version Negotiation

I agree. The only other alternative I can see is to make 0xff an invariant for initial packets. I don't have a strong opinion one way or the other.

On Fri, Jan 5, 2018 at 2:46 PM, Nick Banks <nibanks@microsoft.com<mailto:nibanks@microsoft.com>> wrote:
If you are sending 0-RTT packets then you have connected to this server before and should be able to remember the version you used. The only issue then, is if the server stops supporting a particular version and then you try to reconnect. Either way, a server might want to have some throttling logic for VN packets sent out; but I don’t think it would be the end of the world if it didn’t.

- Nick Banks

From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:39 PM
To: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: Long Headers and Version Negotiation

The invariants draft<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-thomson-quic-invariants-00&data=02%7C01%7Cnibanks%40microsoft.com%7Cd3a2449b9239497e80a608d5548d1eff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636507887456170898&sdata=l1gMfIkx9QmJiJtkHRALPevafNru5A63IwiMsnUaj84%3D&reserved=0> only reserves the 0x80 and 0x40 codepoints in the first byte of the packet.

The transport draft suggests that only initial packets should trigger version negotiation. However, the Initial Packet byte (0xff) is not invariant. So for version negotiation to work at all, servers must send VN packets for any long header type where the version is unsupported -- otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers would ignore it.

On the other hand, in 0RTT cases this might create a storm of VN packets if the version is wrong. I suppose clients are probably not sending 0RTT if they don't know the supported versions.

Am I thinking about this correctly? If so, I'm happy to file an issue, and a PR if we agree that the correct solution is to reply with VN to all long headers with unsupported versions.

- Martin Duke

v2.23.0 | Report a Bug | By Email