Re: Potential conflict between draft-ietf-quic-transport and RFC 7983

"Eggert, Lars" <lars@netapp.com> Thu, 18 May 2017 06:52 UTC

Return-Path: <lars@netapp.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 8C037129B11 for <quic@ietfa.amsl.com>; Wed, 17 May 2017 23:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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=netapp.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 ZpnQ01zuZ46K for <quic@ietfa.amsl.com>; Wed, 17 May 2017 23:52:00 -0700 (PDT)
Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE54129577 for <quic@ietf.org>; Wed, 17 May 2017 23:46:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.38,357,1491289200"; d="asc'?scan'208";a="194020713"
Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx143-out.netapp.com with ESMTP; 17 May 2017 23:29:44 -0700
Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 May 2017 23:45:28 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 17 May 2017 23:45:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eBeRCG64LVryoR/ABtJKX+0HEfDwAPq85wGoNQQOack=; b=dr/d8SEpQguHqXFhw1m6x1yczm9o5DfrP2wN8LRxW4E5z+pk8kLqX5fovgLOZIUh0YgoXk+yDlPYgLow5ohn6/O2R3e7xGkH66poqag2fN0Jq1BTT1xOdXLiVaxoQ6XjykgQ9VauMZy2qvqgpdxbQcm8ynyvBnY7jDw347YzyIE=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 18 May 2017 06:45:27 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1101.019; Thu, 18 May 2017 06:45:27 +0000
From: "Eggert, Lars" <lars@netapp.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>, "marc@petit-huguenin.org" <marc@petit-huguenin.org>, "pthatcher@google.com" <pthatcher@google.com>, Colin Perkins <csp@csperkins.org>
Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983
Thread-Topic: Potential conflict between draft-ietf-quic-transport and RFC 7983
Thread-Index: AQHSz1XIXCzACO/170yWGyUYF0R/0aH5pfsA
Date: Thu, 18 May 2017 06:45:27 +0000
Message-ID: <8FFA81A9-C08E-4856-B058-AC2766FD931C@netapp.com>
References: <CAOW+2dtLDB+hq2u9BA4JYBOt+nRv0G3P+00c7wfPyz5+ftEiRA@mail.gmail.com>
In-Reply-To: <CAOW+2dtLDB+hq2u9BA4JYBOt+nRv0G3P+00c7wfPyz5+ftEiRA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3273)
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=netapp.com;
x-originating-ip: [217.70.211.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 7:351/dT55o7qOGYSatHqnZ3At7As/nm4yLm1jVdSGxwbAwx289vg7hilH+5E0MygffVY/wsUxYkktiEduyvY+iUzmw1ESe2eKJA1uSB3bqCzUgVkNAiPcEfA9kFxcAu2WRz5OMSdi/AofurE4bnz5HGdr1zjqhPNV8v3E+ePjd9NFWUhNf+zmnzVvn2ZxgJpYdAZ45+/QoCXqOh/1dGib5yk0ZNIAB7JgSYLHBr67qM/nDEC5u+v+hmAsomZOQUJ+OPOl1yhBirhPOhSpCKg8cS5lFriNG6Za5vB+blokLT4q7hqUWKinGOhOUfB6qD0z0eSMEtHcmGbrVWeSgTOCfQ==
x-ms-traffictypediagnostic: BLUPR06MB1761:
x-ms-office365-filtering-correlation-id: 1a4af2b2-cf12-4cb0-da2f-08d49db97804
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: <BLUPR06MB17617791BC19615B397D761DA7E40@BLUPR06MB1761.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761;
x-forefront-prvs: 0311124FA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(377424004)(69234005)(24454002)(38730400002)(110136004)(54906002)(4326008)(6512007)(6306002)(99286003)(4001150100001)(229853002)(122556002)(6436002)(6246003)(57306001)(33656002)(76176999)(53546009)(25786009)(99936001)(83716003)(82746002)(966005)(39060400002)(50986999)(66066001)(6506006)(53936002)(230783001)(8936002)(50226002)(7736002)(305945005)(478600001)(102836003)(6116002)(8676002)(81166006)(3846002)(5660300001)(2900100001)(6486002)(77096006)(6916009)(2950100002)(36756003)(86362001)(2906002)(3660700001)(189998001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_33E65924-12AD-4766-90B3-AEF5F339523C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 06:45:27.1875 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761
X-OriginatorOrg: netapp.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oObUuKEyEBProYfyxYmfMnyH4WA>
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, 18 May 2017 06:52:03 -0000

FYI, Colin raised this issue in the past and we have ticket #426 on it open: https://github.com/quicwg/base-drafts/issues/426

Lars

> On 2017-5-17, at 23:36, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> There appears to be a potential conflict between draft-ietf-quic-transport and RFC 7983. Looking at draft-ietf-quic-transport, both the short and the long headers appear to conflict with the de-multiplexing scheme defined in RFC 7983, which is based on the value of the first byte of multi-plexed protocols:
> 
>    The process for demultiplexing a packet is as follows.  The receiver
>    looks at the first byte of the packet.  If the value of this byte is
>    in between 0 and 3 (inclusive), then the packet is STUN.  If the
>    value is between 16 and 19 (inclusive), then the packet is ZRTP.  If
>    the value is between 20 and 63 (inclusive), then the packet is DTLS.
>    If the value is between 64 and 79 (inclusive), then the packet is
>    TURN Channel.  If the value is in between 128 and 191 (inclusive),
>    then the packet is RTP (or RTCP, if both RTCP and RTP are being
>    multiplexed over the same destination port).  If the value does not
>    match any known range, then the packet MUST be dropped and an alert
>    MAY be logged.  This process is summarized in Figure 3.
> 
>                     +----------------+
>                     |        [0..3] -+--> forward to STUN
>                     |                |
>                     |      [16..19] -+--> forward to ZRTP
>                     |                |
>         packet -->  |      [20..63] -+--> forward to DTLS
>                     |                |
>                     |      [64..79] -+--> forward to TURN Channel
>                     |                |
>                     |    [128..191] -+--> forward to RTP/RTCP
>                     +----------------+
> 
>      Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
> 
> 
>