[TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Wed, 23 July 2014 17:55 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E80B31B2A22; Wed, 23 Jul 2014 10:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h16fw0oysHy4; Wed, 23 Jul 2014 10:55:13 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76A71B2B0F; Wed, 23 Jul 2014 10:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1406138100; x=1407347700; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/dLFWfN95CJ6yKnv/vBf0sETzZoyiZ0OduS04zlmCM0=; b=MNWM5RaH0vS/YLsP1cwaTWxg2+o/GAuBYlGxynIAQD6wCfgsGBN3F1wW DovEaNItcuP3h61au/IkBVlAvo06wdb73pdH1hwvBqa4i1KzQWAmGesT9 tB2s/TD0cLHZWLQowFXHaXi0Qx4nuafDaEPzHRip+C5o5klePoC3OdAAb 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FANr1z1OtJA2B/2dsb2JhbABZgw6BLc8qAYELFnaEBAEBBHkQAgFOMiUCBA6IR8AxF49LB4MugRgBBJstlECDSIIx
X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342268064"
Received: from alln-core-9.cisco.com ([]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2014 17:54:59 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com []) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6NHsvqF022898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:54:59 GMT
Received: from xmb-aln-x02.cisco.com ([]) by xhc-aln-x13.cisco.com ([]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:54:56 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Marc Petit-Huguenin <marcph@getjive.com>
Thread-Topic: draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
Thread-Index: AQHPpp82fjgNGTILOE6Hla7Sj7WHsg==
Date: Wed, 23 Jul 2014 17:54:56 +0000
Message-ID: <CE9DACA8-F719-44E0-B085-7B615FE16C34@cisco.com>
References: <53B3F0D9.2010107@getjive.com>
In-Reply-To: <53B3F0D9.2010107@getjive.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <19C0B5070E4F854BA66EBA021DF681AA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3JRCeYQxTllmpHD8feDJhPY5Yu0
Cc: "tram@ietf.org" <tram@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 17:55:15 -0000

Thank you for doing this - I’ve wanted to have this fixed for a long time. 

I think this is good but some recommendations I would make.

We should make a new IANA registry that keeps track of for each value of the first byte, which protocol it is allocated to. I would suggest that it require "Standards Action” to allocate a new code point to a protocol but of course one allocated to that protocol, the protocol would manager it within it’s existing IANA registry for that protocol with that protocols existing rules. 

The advantage of this is we can allocate the points as needed instead of guessing if TLS or STUN  or some new protocol will need a given number points. There is no implementation problem for the demux because things that use the new code points would know how to demux them. 

I think that STUN and TURN should use up the minimal number of code points in the registry that they easily can. Later, if they need more code points, they can co back registry to get more. 

I would suggest that 256 channels would be enough for TURN. If a given TURN client needs more than that, it just needs to allocate a second local UDP port. So TURN probably needs 1 code point for now. 

It would be good to allocate one code point for experimental use.