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

I just sent a message to the TRAM list on this - I think the only real
issue here is that the STUN demux procedure specific in 5764 is incorrect.
When FINGERPRINT is used, which is mandatory for ICE, there is no issue
with demuxing STUN from anything.

And there has never been a demux issue for TURN channels, since packets
from the TURN server will never be unencapsulated.

Ergo, we don't need any changes to the STUN registries or TURN channels. We
should just update 5764 to reference 5389, Section 7.3.

I agree it would be nice to have a first-byte registry for generic data,
e.g. RTP vs DTLS, to ensure that all application protocols can be properly
demuxed from each other.

On Wed, Jul 23, 2014 at 1:54 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>
wrote:

>
> 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.
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>