errata logo graphic

Found 4 records.

Status: Reported (1)

RFC5389, "Session Traversal Utilities for NAT (STUN)", October 2008

Source of RFC: behave (tsv)

Errata ID: 3737

Status: Reported
Type: Technical

Reported By: Spencer Dawkins
Date Reported: 2013-09-25

Section 17 says:

The IAB has mandated that protocols developed for this purpose
document a specific set of considerations. 

It should say:

The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. 

Notes:

The IAB UNSAF RFC (http://tools.ietf.org/html/rfc3424) is Informational, and the IAB hasn't "mandated" what IETF protocol documents contain for something like 20 years, if I understand correctly.


Status: Held for Document Update (2)

RFC5389, "Session Traversal Utilities for NAT (STUN)", October 2008

Source of RFC: behave (tsv)

Errata ID: 2010

Status: Held for Document Update
Type: Technical

Reported By: Pasi Eronen
Date Reported: 2010-01-21
Held for Document Update by: Lars Eggert

Section 7.2.2 says:

For purposes of usage with this specification, the client treats the
domain name or IP address used in Section 8.1 as the host portion of
the URI that has been dereferenced.

Notes:

The reference should be to Section 9, not 8.1.

Unfortunately, even with this purely editorial fix, the text is
ambiguous: the procedure described in Section 9 would typically use at
least three different domain names: (1) the configured domain name,
like "example.com"; (2) the domain name used in the SRV query, like
"_stuns._tcp.example.com"; and (3) the domain name found in the SRV
record and used for A/AAAA query, like "stunserver3.foobar.example".
And they have *very* different security implications...


Errata ID: 2972

Status: Held for Document Update
Type: Editorial

Reported By: Jack Bates
Date Reported: 2011-09-16
Held for Document Update by: Wes Eddy

Section 15.9 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Attribute 1 Type           |     Attribute 2 Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Attribute 3 Type           |     Attribute 4 Type    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 1 Type        |       Attribute 2 Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 3 Type        |       Attribute 4 Type    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Attribute 1 Type and Attribute 3 Type are 17-bits in original figure, Attribute 2 Type and Attribute 4 Type are 15-bits

This is a very cosmetic nit, since the meaning is perfectly clear (a list of 16-bit values)

In general however I find the decimal indices make all figures like this harder to read. I find hex indices an improvement:

<pre>
0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>


Status: Rejected (1)

RFC5389, "Session Traversal Utilities for NAT (STUN)", October 2008

Source of RFC: behave (tsv)

Errata ID: 3327

Status: Rejected
Type: Technical

Reported By: Todd Herman
Date Reported: 2012-08-20
Rejected by: Wes Eddy
Date Rejected: 2012-09-06

Section 15.3 says:

   The USERNAME attribute is used for message integrity.  It identifies
   the username and password combination used in the message-integrity
   check.

Notes:

There is no explanation or description as to where this "password" comes from. The statement indicates that the password is also part of the username field but that may not actually be true according to additional research I conducted and other portions of the specification.

If the password is part of this field than it should be explicitly noted how the two values are concatenated. If this is not accurate, than the "and password combination" portion should be removed.
--VERIFIER NOTES--
Based on BEHAVE mailing list discussion, other sections of the document (e.g. section 10) make this pretty clear, and there does not seem to be any need for a change or correction to the document.


Report New Errata