Test Vectors for Session Traversal Utilities for NAT (STUN)
Note: This ballot was opened for revision 04 and is now closed.
(Magnus Westerlund) Yes
(Jari Arkko) No Objection
Comment (2008-11-06 for -)
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."
(Ross Callon) No Objection
Lars Eggert No Objection
(Pasi Eronen) (was Discuss, No Objection) No Objection
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)
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) No Objection
Comment (2008-11-05 for -)
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.