Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

["Cullen Jennings (fluffy)" <[e-mail]>]

On Jul 23, 2014, at 12:44 PM, Martin Rex <[e-mail]> 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.