11. (2004-06-10, 02:53:11)hta > I believe this needs a respin for other reasons. But the number of > language issues identified in Patton's review is large enough that it > should have a careful language review in the same respin. So if there > hadn't been other reasons to respin it, this might have been a > (marginal) DISCUSS. Reply: It sounds like what is wanted here is heavy editing by an English language native speaker. We will see that this is done. ------------- Michael A. Patton wrote: >> 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, >> are 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. ------------- Jari Arkko writes: Addressed all of the above, except: >> 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. No changed requested. Trust us (?), it works ;-) >> 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. A generic timestamp would be possible, but we like to do protocol designs for a specific purpose, and it is not clear that the generic option would meet the requirements of other applications. >> 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. No change requested. >> 6.1 Certificate Format No change requested. >> 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. No change requested. >> encoding of the previous field", but the previous field is only ASN.1 >> in one of the two types. Fixed as a part of another issue. >> 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, >> are 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... Fixed as a part of another issue.