Subject: [AVTCORE] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 02 Jul 2014 05:45:29 -0600

Following discussions with Martin Thomson and Magnus Westerlund, we
prepared this draft that aims to fix some issues in RFC 5764.

In addition to updating the IANA registries (which will be discussed in
TLS and TRAM), this draft proposes to update the RFC 5764 multiplexing
algorithm.  Because this may cause interoperability issues, we would
like to collect RFC 6982 templates from implementers willing to
implement these modifications.

We propose to keep the discussion about the RFC 5764 modification in the
AVTCORE mailing-list and the discussion about the IANA updates in the
TLS and TRAM mailing-lists.  We may have to move the IANA changes into
separate I-Ds later, but we thought that it was simpler as a starting
point to keep everything in one single draft.

Thanks.

URL:
http://www.ietf.org/internet-drafts/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00.txt
Status:
https://datatracker.ietf.org/doc/draft-petithuguenin-avtcore-rfc5764-mux-fixes/
Htmlized:
http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

-- 
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  [email-masked]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 23 Jul 2014 17:54:56 +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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jul 2014 13:41:56 -0700

On 23 July 2014 12:44, Martin Rex <[email-masked]> wrote:
> 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:

We discussed fixing that at the interim meeting where that proposal
was discussed.  The fix is trivial; we could, for instance, always
send 23.  Or, we could use Fluffy's proposed new registry to obtain a
different demux byte value.  I suspect that the former is fine.

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Jul 2014 21:44:38 +0200 (CEST)

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;

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?

-Martin

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 13:31:39 -0400

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) <[email-masked]>
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 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.
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 31 Jul 2014 15:30:52 +0000

> http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00#page-6

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.