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)
(Tim Polk)
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.