Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 31 July 2014 15:30 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 [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 7C5FC1A00D7;
Thu, 31 Jul 2014 08:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -113.902
X-Spam-Level:
X-Spam-Status: No, score=-113.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, 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 ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Gl4TNWuO7l0L; Thu, 31 Jul 2014 08:30:55 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77])
(using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id A18651A00AB;
Thu, 31 Jul 2014 08:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=cisco.com; i=@cisco.com; l=2511; q=dns/txt; s=iport;
t=1406820654; x=1408030254;
h=from:to:cc:subject:date:message-id:references:
in-reply-to:content-id:content-transfer-encoding: mime-version;
bh=7Mx8Mf/Q4t4V3KcaHhJ6/ppgjt39tjh0Wsg5E5tu9nk=;
b=Rke4XeqSYHBHAqj+iiDU038jJhMwoTWIWhK4+MgJ+Worzaa1vzbdGP2H
wEo/QOUHPLbK1oPr+ND+sE7/Pn/UB4L1rXYViMLGPORIMXHYmvBcfy7N7
IRoBPaM3rCK8/RugzGHhb/3uHM4t0PH6Yqb66qs9azuCZSP61/GKOTUY3 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAOlf2lOtJA2L/2dsb2JhbABagw5SVwTLL4dJAYEHFneEAwEBAQECASdSBQsCAQgYLjIlAgQOBYg6CA2/dxeOewEBHDMCBYMvgRsFm2SBUpMBg0lsAYELOQ
X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344186002"
Received: from alln-core-6.cisco.com ([173.36.13.139])
by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2014 15:30:53 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87])
by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6VFUreg013865
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Thu, 31 Jul 2014 15:30:53 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by
xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 31
Jul 2014 10:30:53 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [tram] [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
Thread-Index: AQHPpp82fjgNGTILOE6Hla7Sj7WHspuuY6YAgAxLyoA=
Date: Thu, 31 Jul 2014 15:30:52 +0000
Message-ID: <A96AAFCA-0B31-48B4-84FD-89AE582C9B64@cisco.com>
References: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp>
In-Reply-To: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.70.167]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FF3A1E6EB356264899AC38450C038AFE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23BUai3MOuqC3LhhxOckraFA4zk
Cc: "tls@ietf.org" <tls@ietf.org>, "avt@ietf.org" <avt@ietf.org>,
"tram@ietf.org" <tram@ietf.org>
Subject: Re: [TLS] [tram] 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: Thu, 31 Jul 2014 15:30:57 -0000
On Jul 23, 2014, at 12:44 PM, Martin Rex <mrex@sap.com> wrote: > Cullen Jennings (fluffy) wrote: >> >> 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'm slightly confused. Is that first byte in Figure 3: > > http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00#page-6 > > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | > packet --> | 19 < B < 64 -+--> forward to DTLS > | | > | B < 2 -+--> forward to STUN > +----------------+ > > Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. > Here the field B denotes the leading byte of the packet. > > the actual "ContentType" byte of the (D)TLS record protocol, > which happens to currently be visible on the outside of the (D)TLS > record protocol with a fairly small set of values: > > enum { > change_cipher_spec(20), alert(21), handshake(22), > application_data(23), (255) > } ContentType; > > > There has been a proposal to hide the ContentType for TLSv1.3 > and break lots of existing software that relies on being able > to parse TLS records: > > https://www.ietf.org/mail-archive/web/tls/current/msg13055.html > > > Will rfc5764 have to be added to the list of things that would break > by such a (needless) TLSv1.3 change? > my understanding of the proposal would be they would use and existing record or create a new code point but that code point would be in the 19 to 64 range so I don’t think RFC 5764 would be broken by the proposal. The proposal might still be sort of lame but I don’t think it breaks this demux.
- [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fix… Marc Petit-Huguenin
- [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fix… Cullen Jennings (fluffy)
- Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux… Martin Rex
- Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux… Martin Thomson
- Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux… Yoav Nir
- Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5… Justin Uberti
- Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5… Cullen Jennings (fluffy)