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

Magnus Westerlund <> Fri, 02 May 2014 08:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C4231A0A71 for <>; Fri, 2 May 2014 01:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LEx3Lqw9plnZ for <>; Fri, 2 May 2014 01:26:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 871B51A016A for <>; Fri, 2 May 2014 01:26:30 -0700 (PDT)
X-AuditID: c1b4fb30-f790e6d000001067-82-536356b470d7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 14.FC.04199.4B653635; Fri, 2 May 2014 10:26:28 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 2 May 2014 10:26:27 +0200
Message-ID: <>
Date: Fri, 02 May 2014 10:26:27 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Martin Thomson <>, Christer Holmberg <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje6WsORgg7ZJshYve1ayW1w784/R gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp49e4hc8Ff0Yp9M3cxNjDuEuxi5OSQEDCR aGz4wARhi0lcuLeerYuRi0NI4CijxO3d/9khnGWMEjs6z7OAVPEKaEtMe3aVGcRmEVCR6Dp2 GqybTcBC4uaPRjYQW1QgWGLDw7/sEPWCEidnPgHq5eAQEUiWmPaODyTMLCAkcXrON1YQW1jA WmL6+q9g5UICkxglnj2SAbE5BQIlnn45B9YqISAu0dMYBNGqJzHlagsjhC0v0bx1NjNEq7ZE Q1MH6wRGoVlIFs9C0jILScsCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFBfHDLb4Md jC+fOx5iFOBgVOLhLf4SGSzEmlhWXJl7iFGag0VJnPfbWfdgIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYy2kw+E2bLmuYYpnGJb//3VlxWL11z8/F5vIq/T58RTV762PXrm+IDTLetotOnB LVtE32+88zRo4i/bOz25EgIbn9+PmGOnuLpoquSSz/9fhn81/9Uxb9nsJbsT7BYe1fX6Gvh/ 56l34W+iSlbqHdJu7imzv/zocnyCiqK7pLzS7tkfDBulOayylViKMxINtZiLihMB6L/dX0MC AAA=
Subject: Re: [AVTCORE] Errata on RFC 5764 : Errata ID: 3913
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 May 2014 08:26:33 -0000


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

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?


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: