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

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 17 May 2017 21:52 UTC

Return-Path: <Michael.Bishop@microsoft.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 D8BAD12009C for <quic@ietfa.amsl.com>; Wed, 17 May 2017 14:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ByN1usJVrRPx for <quic@ietfa.amsl.com>; Wed, 17 May 2017 14:52:17 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0096.outbound.protection.outlook.com [104.47.32.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91EC126DD9 for <quic@ietf.org>; Wed, 17 May 2017 14:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l8Z/39fHKmd2DGk6iKtBn1xtSRJV4fsEyWiWLrP1nnI=; b=Fv7k6e4rG1nxmbPPG3IRd5k+Sp0H9jM9LI8tslxufD5dpKD+fZXtnhdcwtyM9ISye7iEtiuBPCV4u0X7nYJ/q25DWjCtXce+HXrWOj/Vpypt+f2eNeeNtWCE6BY6CVmYdX6SzvIxndJOkJhlLi0hCwVH7y/v/2vQHKO530Mx2Kg=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Wed, 17 May 2017 21:52:14 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1084.029; Wed, 17 May 2017 21:52:14 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, "quic@ietf.org" <quic@ietf.org>
CC: "marc@petit-huguenin.org" <marc@petit-huguenin.org>, "pthatcher@google.com" <pthatcher@google.com>
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: AQHSz1XB0XTUZmZUbU2a1ilYEZYs7KH5DrUQ
Date: Wed, 17 May 2017 21:52:13 +0000
Message-ID: <BN6PR03MB27088B21ED2D58F609EBA50287E70@BN6PR03MB2708.namprd03.prod.outlook.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:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:c::660]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:ghAQQwUuIbyO0BplOGOPtC8mNEuE6glWYkh7X30Me7ynvlzCj/5L+nVDjiDeXSNCqCtQCtOWaFcX+Tp9jMIIENHE308gKtuZjU6rWvtjK8rF05WLjwm9lrhFdajmVykKXG+XH5ZYPMcth8JGKuQs2oF2yMb25hBrFAoRlD66P53MLfcxIguCHO5kgvU8vpw5e3i6LOHJgvd37QxTg9UgTxAM0UGX56tddw7fAJ304f+DO9oke88HTxb/0qhWEM+0/OVO+vODRdJ91wbfQb1mpoJNWtWol8DT5nrST28cItAX8irZjPEqMVHGge/mR9oYhXGZEAwApGU5E42LRyRPuLmLbVEB5iwGuT9zaPYdjBo=
x-ms-office365-filtering-correlation-id: 50b9288a-7106-4730-9094-08d49d6efa96
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <BN6PR03MB27083BF4C4EA1D682812013B87E70@BN6PR03MB2708.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(377454003)(2501003)(10290500003)(39060400002)(54906002)(230783001)(99286003)(6506006)(2900100001)(53546009)(189998001)(7736002)(6306002)(74316002)(4326008)(6436002)(53936002)(10090500001)(5005710100001)(86362001)(86612001)(9686003)(54896002)(72206003)(6246003)(25786009)(76176999)(33656002)(8676002)(54356999)(38730400002)(229853002)(50986999)(77096006)(5660300001)(8990500004)(3280700002)(7696004)(8936002)(478600001)(102836003)(790700001)(2950100002)(2906002)(6116002)(81166006)(3660700001)(122556002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27088B21ED2D58F609EBA50287E70BN6PR03MB2708namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 21:52:13.9545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HjZdSXoU1Q7PK9qPMaNMdfDHHlQ>
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, 17 May 2017 21:52:20 -0000

7983 is a bugfix to 5764 section 5.1.2, per a quick perusal.  I didn’t read either of those RFCs as purporting to constrain the first byte of all future UDP-based protocols.  5764 says:

   When DTLS-SRTP is used to protect an RTP session, the RTP receiver
   needs to demultiplex packets that are arriving on the RTP port.
...
   If other packet types are to be multiplexed as well, implementors
   and/or designers SHOULD ensure that they can be demultiplexed from
   these three [or five, given 7983] packet types.

Is it a goal for QUIC and DTLS-SRTP to coexist on the same port?

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 17, 2017 2:37 PM
To: quic@ietf.org
Cc: marc@petit-huguenin.org; pthatcher@google.com
Subject: Potential conflict between draft-ietf-quic-transport and RFC 7983

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.