Skip to main content

Test Vectors for Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-stun-test-vectors-04

Yes

(Magnus Westerlund)

No Objection

(Chris Newman)
(Cullen Jennings)
(Lars Eggert)
(Mark Townsley)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 04 and is now closed.

Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2008-11-06) Unknown
Christian Vogt's review:

I was asked to do a review of draft-ietf-behave-stun-test-vectors-03 for
IESG evaluation, and I found the document to be ready for publication:

This document provides samples of STUN messages that have been found to
cause interoperability problems across implementations.  The goal is to
help making implementations standard-conform and interoperable.
Overall, the document is certainly ready for publication.  Just a minor
editorial improvement suggestion below.

In section 2, the document states:

    In this document, ASCII white spaces (U+0020) are used for padding
    within the first three messages - this is arbitrary.  Similarly,
    the last message uses nul bytes for padding. [...]

For the sake of clarity, there should be a statement about the possible
values that a padding byte may take.  I understand the text above to
mean that padding bytes can take any value.  Suggest re-wording to:  "In
general, padding bytes may take any value.  For the sample messages in
this document, ASCII white spaces (U+0020) were used for padding in the
first three messages, and null bytes were used for padding in the last
message."
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2008-11-06) Unknown
A clarifying question: is the user name in Section 2.4 before
SASLprep processing or after? (or does it matter for this string?)

It would be useful to show the password in Section 2.4 also
after SASLprep processing (it seems this particular string
is changed by SASLprep)
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-11-05) Unknown
I am comfortable with the technical content in this draft, but find the Abstract and body of the
text internally inconsistent.  It seems that the scope kept expanding as the authors progressed
through the document, but never revised the front matter.

Specifically, the Abstract implies that there are only two STUN attributes that can appear in
STUN messages.  The Introduction indicates that there are two STUN attributes that include
hashes in STUN messages, and that these are in the sample messages.  Section 2, Test
Vectors, notes that the three most problematic STUN attributes are FINGERPRINT,
MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS and the document has test vectors for
each of these attributes. An additional message covers STUN authentication with long term
credentials.

From the Abstract and Introduction, I am afraid the reader will not realize the full scope of
the test vectors and may not perform some appropriate tests.  I would suggest a quick scrub
to consistently present the actual scope of the given test vectors.