Document: draft-ietf-send-ndopt-05 Reviewer: Michael Patton Date: June 9, 2004 Summary: This draft is basically ready for publication as PS, but has LOTS of nits that should be fixed before publication. Not being a security weenie, I did nothing to check whether the described protocol actually provides the security it claims. However, given that disclaimer, it does seem to me to meet the requirements. I'm also not really a wizard on IPv6 (specifically ICMPv6), and wondered about a special timestamp option just for this purpose, I would have thought that leveraging a more generic timestamp option would have been better. Overall the document seems well organized and complete. There were a few questions and/or spots where I think clarification would help. There were also a very large number of typos. Given the number of typos that I caught, I'm sure there are some that I missed (or that will be introduced with other changes). Therefore I suggest that another reviewer good at this aspect look over the results (that may just be a recommendation for more detailed language review in the RFC prep stage) after these are fixed (and it wants to be after so that these don't distract from finding new ones). I think the extent of these comments suggests the document be respun at least once, but probably limiting the changes so it doesn't require a full review cycle after that. In 6.2.2 it first talks about splitting the certificates to avoid IP fragmentation, and sounds like it's recommending applications prepare to deal with losing some elements (presumably by re soliciting), but then later it says that they must be sent in a specific order. Since the first pretty much guarantees out-of-order, and you can't generically expect in order delivery, I don't think the ordering guarantee can be realized... In 6.2.5 which has the "Processing Rules for Routers" which generate these, it doesn't talk about splitting at all. This all needs to be adjusted to be consistent. In 6.2.6 "Processing Rules for Hosts" there is a "Routers MUST ..." which is a processing rule for routers, not for hosts. And again it talks about loss and reordering... I didn't understand why, in Section 8, you are allowed to ignore some responses on the 2nd DAD round. This is explained away in 9.2.3, so sewction 8 at least needs a forward reference. But the explanation is unconvincing to me. Either some security guru with a little bit of routing clue should think carefully about this, or perhaps a security guru and a router guru should get together and try and do some detailed analysis. It's possible that this is just something that can't be done both completely and securely at the same time thus requiring a compromise, but the description here doesn't seem to me to be enough to justify that... I was going to offer suggestions on people to work on it, and then noticed that one of them was an author (Bill Sommerfeld) so maybe I'm not so bothered any more. If Bill signed off on that, you probably really can't do better. In 6.2.3 when they refer to FQDNs they use the presentation format from 1034 rather than the wire format, but they are defining a wire format. The two formats are the same length in the normal case, they should use RFC1034 wire format for FQDNs. Additionally, there are valid domain names that "preferred name syntax" can't represent, but that wire format can... They do restrict the FQDNs to ones that can be represented in "preferred name syntax", but using wire format is more flexible for possible future use. At the end of 6.2.3 it says the padding starts "after the ASN.1 encoding of the previous field", but the previous field is only ASN.1 in one of the two types. I had a vague frisson when I saw the start of section 5. There's a vaguely circular feeling about requiring that the following must be implemented by all SEND nodes when the definition of a SEND node is a node that implements these... Then throughout the rest of section 5 it keeps saying that various options MUST be included in certain messages. Of course it means that "complying SEND nodes" MUST include them. Non-SEND nodes, of course, ar not required to include those options. I'm not sure there's a good way to fix this, but it kept grating on me each time I came across it... Does the use of [19] in 6.1 make it normative rather than only informative? I don't have the time to understand what the reference is actually about, so I can't be sure, but it seems like it to me... It's importing definitions... Typos and other trivialities...my suggested replacements indicate the problem and solve it, but other rewordings do as well. Abstract: "Unlike to the original" => "Unlike the original" 2. Terms: "NDP contains also" => "NDP also contains" (or remove the word "also" completely). In section 4 "This specification also allows..." should reference the spec that it is within the scope of, if there is one (I couldn't find it in the references), or state that it is "for future work". 5.1.2 "MUST be also treated" => "MUST also be treated" 5.2.1 "signature is put to the Digital Signature field" => "signature is put in the Digital Signature field" 5.2.2 "MUST be also treated" => "MUST also be treated" 5.2.2 "options the come after" => "options that come after" 5.3.4.2 is missing a close paren at the end of the first paragraph. 6. "In the typical case, a router already connected to beyond the link, can (if necessary) communicate with off-link nodes and construct such a certificate chain." => "In the typical case, a router already connected beyond the link, can (if necessary) communicate with off-link nodes and construct such a certificate chain." The Secure Neighbor Discovery Protocol mandates a certificate format and introduces two new ICMPv6 messages that are used between hosts and routers to allow the host to learn a certificate chain with the assistance of the router. 6.1 Certificate Format The certificate chain of a router terminates in a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router. Because authorization chains are not a common practice in the Internet at the time this specification was written, the chain MUST consist of standard Public Key Certificates (PKC, in the sense of [19]). The certificate chain MUST start from the identity of a trust anchor that is shared by the host and the router. This allows the host to anchor trust for the router's public key in the trust anchor. Note that there MAY be multiple certificates issued by a single trust anchor. 6.1.1 "authorized to to advertise" => "authorized to advertise" 6.1.1 is very long and several pages in is the first use of the term "DCA" in the document. It should be expanded here. Ah, I just found the expansion (in 6.2). Simplest is to move the expansion from there up to 6.1.1, but better would be to include it in Section 2 "Terms". Several other TLAs also could benefit from being in Section 2 "Terms". 6.2 "between a router and the one of the host's trust anchors" => "between a router and one of the host's trust anchors" 8. "the entry issecured" => "the entry is secured" Sections 10 and 11 are very short (less than a dozen lines each), putting them on separate pages seems wasteful. Couldn't they be combined on one page (maybe as one section with two subsections, if needed to make it happen). Appendix A and B have this same problem... Appendix C: "avoid he dangers" => "avoid the dangers" Appendix C: "The goal here is clearly make sure" => "The goal here is to make sure" Appendix C: "is very discriminative against" => "is very discriminatory against" Appendix C: "its clock difference into arbitrarily small" => "its clock difference to arbitrarily small" Appendix C: (last paragraph on page 56) refers to the "sec parameter" and "larger sec", buth uncapitalized. Everywhere else in the doc it's the "Sec value" with "Sec" capitalized.