Subject: Re: [AVTCORE] Errata on RFC 5764 : Errata ID: 3913

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 May 2014 10:26:27 +0200

Hi,

Regarding Errata ID: 3913

I am not certain that the current text is wrong. I think we need to dig
into this a bit more before deciding what to do.

So, to my understanding the following requirements do exists.

For STUN, a first byte value of 0 and 1 MUST be counted as STUN, as STUN
encodes the higher bit of the message class in the first bytes lowest
bit (bit 7). There already exist STUN messages with this bit set to 1.
Thus, B < 2 is absolutely correct.

We also know that DTLS uses byte values (B) of 20-63.

Formally this is a value overlap between what STUN could potentially use
(0-63) and what DTLS can potentially use 20-63.

However the reality is that it is unlikely that we ever is going to need
that many STUN messages. What we come down to is the question is how
much we want to restrict the future assignment of STUN messages. If we
assume B < 2 is correct, then RFC 5764 did restrict STUN messages to no
more than 128 methods per message class (This due to one bit in the
second byte of the STUN message is for message class).

If I remember correctly, I think the non specification of the B values
2-19 is actually intentional. The values assigned was only the ones that
was required, to not unnecessarily limit any future actions.

If one think this restriction on STUNs extension space is okay, and my
personal opinion is that it is more than sufficient. Then we reject this
errata.

If you are stongly in the camp that STUN should be allowed to use all
the way up to and including 19 of B values, then something must be done.
 Then the question comes if this is something an errata can change, i.e.
this was only a typo. If it can be determined that this was intentional
then I would say that an RFC update will be required to change this.

Regarding the STUN specification: Yes, it would be good to update the
IANA section to introduce the correct limit to future extension based on
DTLS-SRTP. But, that is not this WG's work, rather someone should take
this issue to TRAM and let them introduce that correction.

To conclude I have two questions:

1. To any in the WG: Do you really think there is an issue of
restricting STUN to 128 methods per class per existing RFC?

2. To Martin: What made you think there was an error in RFC 5764?

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: Martin Thomson <[email-masked]>
Date: Fri, 2 May 2014 10:10:26 -0700

> restricting STUN to 128 methods per class per existing RFC?

This is an alternative to what I proposed, which would leave 5764
alone.  You need to make some allowance for this though:
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#stun-parameters-2
 (Note the range 0x800-0xFFF, which is currently unused)

> (0-63) and what DTLS can potentially use 20-63.

I don't think that it's quite fair to say that it's a fault of STUN.
STUN was there first, so arguably the fault lies with RFC 5764.

As I said, it's a minor issue.  There doesn't seem to be any need for
the overlap, so it's probably safe to retroactively change the rules
for STUN method registrations.

---

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

>  (Note the range 0x800-0xFFF, which is currently unused)

Yes, and from my personal position, I think it is fine to leave RFC 5764
alone here. The 128 methods per class should be sufficient.

But I do agree that we should work to ensure that these limitations are
reflected in STUN's IANA section.

> STUN was there first, so arguably the fault lies with RFC 5764.

Agreed, but it was a decision that was discussed in the community when
it happened.

> for STUN method registrations.

I also think so. And, I think the minimal work needed here is to address
STUN's IANA rules within the TRAM WG, not also change values in RFC
5764. Therefore I would like to reject this Errata.

I will give everyone two weeks to think this over and object against my
proposal to reject the errata.

Cheers

Magnus Westerlund