IETF Logo Mail Archive

RE: Clarification of transport and HTTP version compatibility

Mike Bishop <mbishop@evequefou.be> Wed, 09 May 2018 21:02 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 6068712DB6B for <quic@ietfa.amsl.com>; Wed, 9 May 2018 14:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 NmqOzkhS-yuy for <quic@ietfa.amsl.com>; Wed, 9 May 2018 14:02:02 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9A612DA72 for <quic@ietf.org>; Wed, 9 May 2018 14:02:01 -0700 (PDT)
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=z9CQYWu2jP5Ni+evNPu4HxJLBmGhUJbxx1EJ7svjLmM=; b=g4w5jCwaP4CsxqpyXhUW+zuvdoPcLwgdPm6fK2GX5OrthI7/geoY9zBQKv2X6Z0BrNZQ4tVHKcp2jPhxqK9C65mAcOKtM5a+nHe6q8J8ou8xkW4VD2TfkiRE2QIfiXsMKGun4bGpA+Oz+bds6YRD+Dj+Er8E7rYlVfjR9DctpGM=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1423.namprd08.prod.outlook.com (10.162.1.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 9 May 2018 21:01:59 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d%13]) with mapi id 15.20.0735.018; Wed, 9 May 2018 21:01:59 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Sam Hurst-RD <samuelh@rd.bbc.co.uk>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Clarification of transport and HTTP version compatibility
Thread-Topic: Clarification of transport and HTTP version compatibility
Thread-Index: AQHT56+xI3vQwOQ++kOo1AZLBRUIXaQno4FAgAANUQCAADE84A==
Date: Wed, 09 May 2018 21:01:58 +0000
Message-ID: <SN1PR08MB1854FC73444239C609552459DA990@SN1PR08MB1854.namprd08.prod.outlook.com>
References: <906fdff3-8009-238b-998b-4ea515a2684d@rd.bbc.co.uk>, <SN1PR08MB1854826DACF0454471CB162DDA990@SN1PR08MB1854.namprd08.prod.outlook.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB2B67C@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB2B67C@bgb01xud1012>
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; SN1PR08MB1423; 7:lTgw/PORZ28wyTwrR85eQcw0WyO1iMigQPK66lZ/ELXADqzXPgaxoA+p3GsHPkNKCqTHYL6LqH64l3jNErFEx3TBPF1UwOUNbCd3I5oN3QeGJUiF0nvkarMbo9wIXgSIvzAR/KGZXW8w3B1RR6aBbSmh3mACMQqtpZYce1N5nPocV9feVhNbG293AGSjgXPLCFYJVWaZuvhi98X5WoOMGXbt/7ZBjOjUHu2IchqXUHxYJL0ZQwwxxOICX5cYJ0El
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1423;
x-ms-traffictypediagnostic: SN1PR08MB1423:
x-microsoft-antispam-prvs: <SN1PR08MB142302C72160D9FBA0D0DEEFDA990@SN1PR08MB1423.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(127952516941037);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(2016111802025)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1423; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1423;
x-forefront-prvs: 0667289FF8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(396003)(39830400003)(376002)(346002)(53754006)(199004)(189003)(13464003)(3660700001)(66066001)(53546011)(14454004)(110136005)(7736002)(105586002)(305945005)(33656002)(26005)(229853002)(7696005)(8936002)(6506007)(6436002)(316002)(5660300001)(2906002)(6116002)(3846002)(8676002)(59450400001)(81156014)(81166006)(68736007)(3280700002)(6246003)(186003)(5250100002)(478600001)(55016002)(486006)(11346002)(446003)(9686003)(99286004)(476003)(74482002)(102836004)(97736004)(86362001)(53936002)(106356001)(2900100001)(25786009)(76176011)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1423; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OooSWlx4t9wT4tGxonKkP5+Lmu0qILAHX9qvfQxP789oQoA2AXXJ8KqNH1fBljX8tQMALhfEKKQJs76nnoBb80G0TftpGYWNMp1gFJg3pjyUdbF8nKOT+lCKV9FvM8qMs54c6nepXwUSgp+rRWNFW01HZ0NXiX05/gKYzu5cTC0i1kFWpOAu6ve5xvZb73AN
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0f8651fd-51df-49f2-756c-08d5b5f01aeb
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f8651fd-51df-49f2-756c-08d5b5f01aeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 21:01:58.9960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1423
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ke3AAb1bYjaXCuFplO1z9GI1Hms>
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: Wed, 09 May 2018 21:02:04 -0000

They *shouldn't* be unanticipated protocol errors, because both are negotiated.  I would expect (or at least hope) that these will manifest as negotiation failures at worst.

-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] 
Sent: Wednesday, May 9, 2018 11:04 AM
To: Mike Bishop <mbishop@evequefou.be>; Sam Hurst-RD <samuelh@rd.bbc.co.uk>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Clarification of transport and HTTP version compatibility

I think this all works fine in the current stage of specification. 

Longer term, what is the failure case for interoperability where different implementations have  different rules for how to combine QUIC version and HTTP/QUIC version. Protocol error due to reception of unanticipated packets and or HTTP/QUIC frames?

Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Mike Bishop [mbishop@evequefou.be]
Sent: 09 May 2018 18:18
To: Sam Hurst-RD; IETF QUIC WG
Subject: RE: Clarification of transport and HTTP version compatibility

There's no firm restriction, no.  While I find it likely that draft deployments will choose to keep matching versions, the only restriction that the HTTP draft currently imposes is that it be a version of QUIC which uses TLS as the handshake protocol.

-----Original Message-----
From: QUIC <quic-bounces@ietf.org> On Behalf Of Samuel Hurst
Sent: Wednesday, May 9, 2018 9:05 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: Clarification of transport and HTTP version compatibility

Hi all,

Does the quic-transport version and the HTTP mapping version have to match? For example, could you negotiate QUIC draft-11, but the HTTP side is still using an older version (such as draft-09 to avoid the requirement of QPACK)?

As far as I understand it, the QUIC transport version is negotiated as part of the TransportParams in the appropriate TLS extension, and the HTTP mapping version is negotiated by ALPN. So in the example above, would it be acceptable to negotiate 0xff00000a as the transport protocol version, and then have an ALPN string of "hq-09"?

I'm then assuming that a valid Alt-Svc header for my example could be as
follows:

Alt-Svc: hq-09=":4443";quic="ff00000a"

The quic-tls draft mentions in Section 9.1 "The application-layer protocol MAY restrict the QUIC version that it can operate over", but none of the quic-http drafts that I've read list any such restriction.
Therefore, I'm then further assuming that it's safe to run whatever version of the HTTP mapping I like, unless there's a compatibility matrix between the various specs that I'm missing?

Best Regards,
Sam

v2.23.0 | Report a Bug | By Email