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

Colin Perkins <csp@csperkins.org> Thu, 18 May 2017 11:20 UTC

Return-Path: <csp@csperkins.org>
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 68CC912EAFF for <quic@ietfa.amsl.com>; Thu, 18 May 2017 04:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NPForC8dKBdK for <quic@ietfa.amsl.com>; Thu, 18 May 2017 04:20:34 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B3E12EBB2 for <quic@ietf.org>; Thu, 18 May 2017 04:15:12 -0700 (PDT)
Received: from [130.209.247.112] (port=59868 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1dBJOf-0002Ok-MG; Thu, 18 May 2017 12:15:10 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAOW+2dv-UR5DonWQG4Zm_U9u2A8L+s6a8Eh32fhU9Mhg2qB_gQ@mail.gmail.com>
Date: Thu, 18 May 2017 12:15:08 +0100
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, "marc@petit-huguenin.org" <marc@petit-huguenin.org>, "quic@ietf.org" <quic@ietf.org>, "pthatcher@google.com" <pthatcher@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D307E719-6FC3-450C-B238-2CC5E00D86F8@csperkins.org>
References: <CAOW+2dtLDB+hq2u9BA4JYBOt+nRv0G3P+00c7wfPyz5+ftEiRA@mail.gmail.com> <BN6PR03MB27088B21ED2D58F609EBA50287E70@BN6PR03MB2708.namprd03.prod.outlook.com> <CAOW+2dv-UR5DonWQG4Zm_U9u2A8L+s6a8Eh32fhU9Mhg2qB_gQ@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2QvXm9k4vV4M0k9NvwyAM6RMsrU>
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 11:20:35 -0000

> On 17 May 2017, at 23:31, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> Mike asked: 
> 
> "Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"? 
> 
> [BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to co-exist on the same port.  Within the scheme, DTLS is used for transport of WebRTC's DTLS/SCTP/UDP data channel and DTLS-SRTP is used for key management of SRTP/SRTCP.  
> 
> While within WebRTC, DTLS currently provides both data channel transport as well as SRTP key management, it is not clear that initial QUIC implementations within WebRTC will attempt to provide alternatives for both of these functions.  
> 
> For example, experimental implementations of a QUIC data channel may wish to focus solely on that objective without having to provide an alternative to DTLS-SRTP.  In such an implementation, QUIC and DTLS-SRTP would need to co-exist on the same port. 

Being able to co-exist with STUN and TURN on the same port is likely important if we ever want QUIC to work peer-to-peer through NATs, too.

Colin


-- 
Colin Perkins
https://csperkins.org/