Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for consistency with draft-ietf-karp-ospf-analysis. KARP is chartered to figure out what improvements we need in routing protocol authenticationq. While draft-ietf-karp-ospf-analysis has not been approved by the WG, I think it's fairly close to our current thinking on what needs to be done to OSPF authentication. I believe we should either be consistent with that thinking or if during the discussion we discover that what we're doing in KARP is incorrect decide to update the KARP document. Based on this review I have a few recommendations for the OSPF v3 authentication trailers document. 1) The v3 authentication trailer takes a step back in the ability to rekey security associations both from OSPF v2, from IPsec for OSPF v3 and from draft-ietf-karp-crypto-tables. At the top of page 231 of RFC 2328, OSPF v2 security associations are defined with four lifetimes: KeyStartGenerate, KeyStartAccept, KeyStopGenerate and KeyStopAccept. Similarly, RFC 4301 defines a lifetime value for the SAs used by OSPFv3; in that case, whether an SA is an outbound or inbound SA controls whether it can be used for reception, generation or both at the current time. In the KARP crypto tables, lifetimes related to when packets can be sent are included: SAs are deleted from the crypto table to prevent reception. However the V3 auth trailer draft leaves this all up to implementation defined behavior. draft-ietf-karp-ospf-analysis indicates that we're going to remind people of the existing OSPF requirements for keylifetimes because they are necessary for key rollover. I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs to be revised to require implementation behavior at least as flexible as draft-ietf-karp-crypto-tables. That is, associated with each security association is a time for when sending packets can start with a given SA and for when it must stop. Infinity and 0 should of course be supported for the appropriate times. 2) I notice terminology inconsistency between key identifier and security association identifier. This should probably be cleaned up, although it's not that big of a deal. 3) draft-ietf-ospf-analysis says that we are going to solve related protocol attacks. That is, we recognize that it's quite likely that some people will use the same preshared key both for OSPF authentication and for something else. We need to mix something into the key or hash or something that is unlikely to appear in any other use in order to make it cryptographically unlikely for the resulting OSPF authentication hash to be a hash useful in some other protocol or for the hash from some other protocol to be useful in OSPF. This draft does not do that. One possible way to solve this would be to prepend a constant in front of the key in the key preparation step or a constant in front of every packet that gets hashed. The constant should be the same for OSPFv3 and not used for any other purpose. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf