Glen, > > (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i > think there clearly is a need to move away from IPsec security for > OSPFv3.
Thanks! I believe we have a good consensus on this draft. We have seen support on the mailing list earlier and the folks who were there in Beijing. > > (4) I am not comfortable with > draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently > stands. While i understand that the author of this draft was one of > the co-authors of RFC 5709, i would like to first understand the > rationale behind introducing Apad in the crypto computation as has > been described in 5709. Thats clearly not a part of the original HMAC > specification. The authors have modified that without giving any > explanation in 5709, and i think its best that we first understand why > that change was introduced before we accept any changes (or > enhancements if you will) to it. We were categorically told that NIST wanted to see the construction (using Authentication Pad (Apad)) that we have finally used in RFC 5310 and RFC 5709. Given that NIST owns the Secure Hash Standard family of algorithms that we're using in these standards it makes sense to follow NIST's instructions. Compliance with NIST cryptographic modes, and general cryptographic guidance is a practical market requirement when creating a specification that uses NIST standard algorithms, regardless of whether one likes or dislikes particular choices that NIST has made. If these specifications were *not* using a NIST algorithm, then NIST's views could be ignored, but not when youre working with a NIST standard algorithm. Hope this helps. Cheers, Manav _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
