Subject: [tram] Request to update STUN's IANA registration in STUNbis work

From: Magnus Westerlund <[email-masked]>
Date: Mon, 5 May 2014 08:50:18 +0200

WG,

The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC 5764) and
STUN's IANA registrations. To ensure that the IANA rules are accurate
and reflect the reality of the environment STUN is operating in today,
there appear to be a desire to request that STUN's IANA rules are changed.

With the approval of RFC 5764 it was created a value overlap in the use
cases where DTLS-SRTP and STUN are co-existing on the same transport
flow. This value overlap exists for any method value outside the range
0-127 for each class of STUN methods. Thus to avoid any collisions in
future registrations it appears prudent to restrict method registrations
to this range to avoid collisions in the cases where one uses STUN and
DTLS-SRTP.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 07 May 2014 03:55:50 -0600

Hi Magnus,

> to this range to avoid collisions in the cases where one uses STUN and

I do not think this is the right thing to do.  The problem is that what
RFC 5764 did was allocating most of the IETF Review STUN Method
codepoints without IETF review and all of the Designated Expert STUN
Method codepoints without expert review, this last point being the main
problem in my opinion, as now nobody can request one of those.

So I have two proposals, first to fix the problem itself:

1. An additional problem with RFC 5764 is that not only it requisitioned
most of the STUN methods codepoints, but it did it unnecessarily.
Instead of this:

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 2   -+--> forward to STUN
                   +----------------+

It should have said this:

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 20  -+--> forward to STUN
                   +----------------+

That would have left 1280 codepoints instead of a mere 128.

So my proposal is that AVTCORE write a standard track RFC updating RFC
5764 with the modification above, and with a request to modify the IANA
registry so that the new RFC Review range is 0x000-0x2FF and the new
Designated Expert range is 0x300-0x4FF.

2. This problem is basically a failure in having RFC 5764 reviewed by
NAT traversal experts before its publication.  So to prevent this
problem from happening again, I am proposing the immediate creation of a
NAT Traversal Directorate which will do this kind of reviews, and I am
also volunteering to be the first member of this directorate.

Thanks.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 May 2014 08:38:32 +0200

Hi,

See inline.

On 2014-05-07 11:55, Marc Petit-Huguenin wrote:
>> The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC
>> 5764) and STUN's IANA registrations. To ensure that the IANA
>> rules are accurate and reflect the reality of the environment
>> STUN is operating in today, there appear to be a desire to
>> request that STUN's IANA rules are changed.
>> 
>> With the approval of RFC 5764 it was created a value overlap in
>> the use cases where DTLS-SRTP and STUN are co-existing on the
>> same transport flow. This value overlap exists for any method
>> value outside the range 0-127 for each class of STUN methods.
>> Thus to avoid any collisions in future registrations it appears
>> prudent to restrict method registrations to this range to avoid
>> collisions in the cases where one uses STUN and DTLS-SRTP.
>> 
> 
> I do not think this is the right thing to do.  The problem is that
> what RFC 5764 did was allocating most of the IETF Review STUN
> Method codepoints without IETF review and all of the Designated
> Expert STUN Method codepoints without expert review, this last
> point being the main problem in my opinion, as now nobody can
> request one of those.

Well, done is done. And it is an IETF consensus document. It likely
should have had more review when it was being pre-paired for publication.

I agree that the designated expert review range is in serious question
for now. We should clearly have discussion on what to do.

> 1. An additional problem with RFC 5764 is that not only it
> requisitioned most of the STUN methods codepoints, but it did it
> unnecessarily. Instead of this:
> 
> +----------------+ | 127 < B < 192 -+--> forward to RTP |
> | packet -->  |  19 < B < 64  -+--> forward to DTLS |
> | |       B < 2   -+--> forward to STUN +----------------+
> 
> +----------------+ | 127 < B < 192 -+--> forward to RTP |
> | packet -->  |  19 < B < 64  -+--> forward to DTLS |
> | |       B < 20  -+--> forward to STUN +----------------+
> 
> So my proposal is that AVTCORE write a standard track RFC updating
> RFC 5764 with the modification above, and with a request to modify
> the IANA registry so that the new RFC Review range is 0x000-0x2FF
> and the new Designated Expert range is 0x300-0x4FF.

Yes, the question is how many is really needed? If TRAM thinks it
necessary to have 1280 per class then I guess we will have to update
what RFC 5764 says.

I will note two things about this.

1. Considering that TRAM WG does have an WG item to update STUN, it
appears wrong that AVTCORE updates the IANA section of STUN. It
appears much wiser to have the future IANA section be part of the
actual STUN RFC in effect. Thus, I really like TRAM to do that part of
the work.

2. Extending the STUN processing range in DTLS-SRTP implementations is
on paper just adding a character. However, the legacy implications on
the deployed implementations needs to be considered. I would fear that
anyone getting the first codepoint in the range corresponding to B
values of 2-19 might get quite irritated due to compatibility issues.
I think we need to check with existing implementations what the impact
of this is.

Further I note that if we need to update RFC 5764 we need both a
stuckee to do the editing and AD approval for this. I think the
AVTCORE charter is fine to take on such an item.

> 
> 2. This problem is basically a failure in having RFC 5764 reviewed
> by NAT traversal experts before its publication.  So to prevent
> this problem from happening again, I am proposing the immediate
> creation of a NAT Traversal Directorate which will do this kind of
> reviews, and I am also volunteering to be the first member of this
> directorate.
> 

May be a good idea, however if RFC 5764 wasn't reviewed sufficiently
then it was an issue with the leadership as well as the participants,
it was not the lack of venues. At the time RFC 5764 went through IETF
last call (September 2008) as well as WG last call (August 2008)
BEHAVE WG was very active. One failure of ADs and WG chairs was to not
inform BEHAVE and ensure that it was reviewed from that perspective.

The main issue with cross-review and directorates is that someone
needs to ensure that they do happen, either by requesting review with
the right entity, or that the entity finds the document itself. Both
requires work and knowledge.

And I am quite certain that the TSV ADs are happy to ad you to the
transport directorate in your capacity as NAT traversal expert.

Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 08 May 2014 04:30:16 -0600

Inline.

> actual STUN RFC in effect. Thus, I really like TRAM to do that part of

Fair enough.

> I think we need to check with existing implementations what the impact

Right.  One way of doing that would be to write a short draft, then
collect RFC 6982 statements from implementers and decide on what to do
from there.

> AVTCORE charter is fine to take on such an item.

I may work on the AVTCORE and the TRAM drafts

> requires work and knowledge.

Yes.  The problem here is very specific:  Because of the nature of NAT
traversal protocols (they generally need to run on the exact same IP
address/port than the protocol they try to help, to be able to keep the
NAT ports open), there is a need for multiplexing.  In this case the
multiplexing rules are incorrect, but we can see that it is not specific
to STUN.  For example the multiplexing rules in RFC 5764 says that if
the first byte is between 20 and 63, then it should be forwarded to
DTLS.  Doesn't that mean that the IANA registry for TLS ContentType
should also be restricted to values between 20 and 63?

So what we need is to be able to review from a multiplexing point of
view all the drafts that will allocate a new TLS ContentType, all the
drafts that will allocate a new STUN Method (and all the drafts that
will define a new version of RTP, but that less likely), plus all the
drafts that define new protocols to be multiplexed inside RFC 5764
(using the non-allocated ranges: 2-19, 64-127 and 192-255).  I suppose
that a similar analysis needs to be done for other multiplexing rules
related to NAT traversal, if they exist.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2014 14:18:58 -0400

Here's my reasoning...

I'm pretty sure the RFC 5764 authors looked at RFC 3489, for which B < 2 
would have been correct. The fact that draft-mcgrew-tls-srtp-00, which 
did contain the above graph, was published long before RFC 5389 was 
reinforces that hypothesis.

With RFC 5389, B < 64 would be necessary, ergo the conflict with DTLS.

I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyone 
please spell it out for me? I'm just going to assume it is correct.

Fact: There are currently no registered STUN methods which would 
actually cause STUN packets to be wrongly forwarded to DTLS by an 
implementation of RFC 5764.

Fact: B < 2 limits the number of STUN methods to 128. There are 
currently 13 methods registered. I know of no plans to register many 
STUN methods such that a limit of 128 would become problematic.

Fact: If STUN-bis restricts to 128 the range of STUN methods, current 
implementations, of either STUNv1, STUNv2, or RFC 5764, will *not* need 
to be modified. STUN-bis could split on 0-63 for IETF Review and 64-127 
for Designated Expert so that we can keep our dual registration procedures.

Opinion: The only disadvantage I can see to making this change in 
STUN-bis would be a loss of STUN method range. I think we can live with 
it. If at some point we can't live with it anymore, which I doubt will 
ever happen, then we would need to revise both RFC 5764 and STUN-bis. 
There's no need for a revision of RFC 5764 now.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 16 May 2014 13:36:51 -0600

On 05/16/2014 12:18 PM, Simon Perreault wrote:
>> | packet -->  |  19 < B < 64  -+--> forward to DTLS |                | |
>> B < 2   -+--> forward to STUN +----------------+
> 
> Here's my reasoning...
> 
> would have been correct. The fact that draft-mcgrew-tls-srtp-00, which did
> contain the above graph, was published long before RFC 5389 was reinforces
> that hypothesis.

But the STUN usage is ICE connectivity check, which explicitly forbids RFC
3489 (see section 7 of RFC 5245).

> please spell it out for me? I'm just going to assume it is correct.

It's not, as it restricts TLS ContentType:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5.

At a minimum 0-19 and 64-255 should be marked as reserved.

> 
> Fact: There are currently no registered STUN methods which would actually
> cause STUN packets to be wrongly forwarded to DTLS by an implementation of
> RFC 5764.
> 
> Fact: B < 2 limits the number of STUN methods to 128. There are currently
> 13 methods registered. I know of no plans to register many STUN methods
> such that a limit of 128 would become problematic.

TURN had a limited deployment until now.  With WebRTC I expect more TURN
extensions coming and I myself have some currently being designed.  So that's
certainly not the right time to restrict the number of methods possible.

> implementations, of either STUNv1, STUNv2, or RFC 5764, will *not* need to
> be modified. STUN-bis could split on 0-63 for IETF Review and 64-127 for
> Designated Expert so that we can keep our dual registration procedures.

Maybe.  The main problem is that (implicit) assignments were done in TWO IANA
registries without following the process.  That's what need to stop.

> 
> Opinion: The only disadvantage I can see to making this change in STUN-bis
> would be a loss of STUN method range. I think we can live with it. If at
> some point we can't live with it anymore, which I doubt will ever happen,
> then we would need to revise both RFC 5764 and STUN-bis. There's no need
> for a revision of RFC 5764 now.

Or, we can reclaim 2-63 for STUN now and not have to pull an ugly EDNS(x)-like
workaround later.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2014 17:24:39 -0400

> At a minimum 0-19 and 64-255 should be marked as reserved.

Wow. So both DTLS and STUN are equally affected by RFC 5764.

If we restrict STUN to work with RFC 5764, it would make sense that the 
DTLS folks do the same.

Also, it now seems impossible to just fix RFC 5764 on its own without 
touching at least DTLS.

The DTLS folks need to get involved in this discussion...

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 May 2014 09:37:55 -0600

There is another thing that in missing in RFC 5764.  Because of ICE, a
socket can receive TURN packets in addition to the STUN connectivity
check packets not going through a relay (in this case the source IP:port
is used to differentiate them).  That's not an issue - unless the TURN
server is using channels because in this case packets starting with a
channel number will be received.  That will work because the first byte
will be in the 64-127 range, which is not used, but this is still
something missing from RFC 5764.

So my proposal is to update RFC 5764 changing the multiplexing algorithm
like this:

0-19: STUN
20-63: DTLS
64-127: TURN channels
128-191: RTP/RTCP
191-255: unallocated

Channel numbers 0x8000-0xFFFF will also have to be reserved in IANA's
TURN Channel Numbers Registry.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 21 May 2014 12:17:25 -0400

> something missing from RFC 5764.

Correct.

> TURN Channel Numbers Registry.

Seems correct to me.

I think at this point we need to start a thread in the TLS working 
group. Would you mind doing it?

When we have a clear cross-area understanding of what needs to be done, 
the hard part will be over.

Thanks,
Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 May 2014 10:23:02 -0600

> the hard part will be over.

OK, I'll send something before the week-end.