Document: draft-ietf-ospf-ospfv3-auth-04 Reviewer: Joel Halpern Date: June 18, 2004 This draft is on the right track but has open issues, described in the review. [The first issue is the only one major enough to warrant this grade. If I am confused about this, then the response can be upgraded one notch to ~still nits to be addressed~.] Major: I can not find in section 8 where it defines what keying shall be used for virtual links. Either the intention is that a single key be used over the whole domain, which would need to be stated, with its security implications, or else IKE needs to be used, in which case that needs to be stated, along with moving IKE to a normative reference. Or maybe there is some alternative I have missed. Large Nits: I presume that this has received sufficient security review that I am missing something, but the description of the security associations (SA) requirement in section 6 seems incorrect to me. It appears that each participant could use a single (distinct) SA for sending, and each participants could configure all other participant SAs for receiving. This would require each participant to configure a large number of incoming SAs, and would require additional configuration whenever a new participant is added. Arguably, using a single SA for all participants is for efficient and meets the requirements. But the explanatory text which says that it is impossible otherwise seems wrong to me. (There are those who would argue that the extra configuration of different SAs and presumably different keys for receiving from each neighbor is actually a security improvement, but that is probably not sufficient to cause a change in the mandate.) In the security considerations section it says "The use of manual keying does not provide very high level of security as compared to IKE..." Aside from a missing article (~does not provide A very high level~) this text leaves the reader wondering. Other than the issue of replay protection in section 11, are there other issues? If so, what other issues? Nits: Section 2 (OSPFv2 to OSPFv3) begins with a very strange "MUST". The first sentence appears to be intended to be a statement of the security approach taken to OSPFv3. If that is the intent, it would be much better served by the sentence: The design of OSPFv3 removes all security concerns from the OSPFv3 protocol and instead relies on the IPv6 AH and ESP mechanisms. In the unlikely event that the above is not the intent, then there is a larger problem. The second sentence of section 2 then goes on to assert that OSPFv3 "MUST NOT receive any unauthenticated packets." This would make OSPFv3 one of the first protocols to not merely mandate the ability to support security, but to mandate the use of security. Given external realities, this is not a requirement that will be met by real world implementations. Presumably, what is intended is approximately OSPFv3 and the IPv6 stack, when operating securely must drop all unsecured OSPFv3 packets. Something better than unsecured ought to be used. The idea is to say "if you expect auth, then everything has to have been authenticated. If you expect encrypt, then everything has been encrypted." This interpretation is consistent with the following sections. It would be helpful to the reader if the line mandating manual keying reference the multicast issue. (A simple "see section 6" would suffice.) The "iface" in the tables in section 10 ought to be explained. In fact, the presence of the "interface" column ought to be explained since the caption says "for interface...". In the fourth paragraph in section 10 it talks about installing all 3 virtual link rules (2, 5, and 6) on all interfaces. This seems misleading: 1) The drop incoming rule (rule 6) ought to be on all interfaces 2) The apply ESP / AH incoming rule (rule 5) ought to only be on the interface the packet will be accepted on 3) The apply ESP / AH outgoing rule (rule 2) ought to be only on the interface the packet will be sent on. Further, it would seem that when security is turned on one should simply install the rule src=*, dst=*, protocol=OSPF -> DROP on all interfaces, thus removing the need for rule 6 entirely. In the security considerations section it says "The use of manual keying does not provide very high level of security as compared to IKE..." Aside from a missing article (~does not provide A very high level~) this text leaves the reader wondering. Other than the issue of replay protection in section 11, are there other issues? If so, what other issues?