Hi Acee, Thanks for the comments.
I agree we can get stronger authentication, but its of no use unless we specify that in case we want security we MUST support the algorithm. As the number of algorithms increase we need to specify a minimal set of algorithms that need to be supported, else the interoperability between implementations that want to support security is not guarenteed . Also, as has been pointed out earlier, we have seen in IPsec RFC4305 as well as RFC4305-bis (of which I am the author), as the computing power increases and security algorithms become vulnerable to new attacks, we do not have to change RFC's that talk about how to use the algorithm. The only RFC that changes is the one that specifies the support levels of various security algorithms. Though it may sound obvious, the support for NULL algorithm states that if we need support for Security we should not use the NULL authentication algorithm. These were the exact lessons learnt in the past in IPsec. I guess we should take care not to repeat the mistakes again. Thanks again, Vishwas On 3/28/07, Acee Lindem <[EMAIL PROTECTED]> wrote:
Speaking as a WG member (so I can state my opinion without having to be nice :^): I like this option the best since it allows us to get the stronger authentication without having to agree on the requirements text. Since it was presented in Paris, I've never liked the text in draft-bhatia-manral-crypto-req-ospf-01.txt. While footnotes have been added to address my concerns, it might be easier not to try and agree on this at all. I don't like section 3 since, until you read the footnotes, it implies NULL and simply authentication MUST NOT be used. Null authentication is by far the easiest to administer, the most efficient, and, I'd wagger, the most widely deployed. Simple authentication can be useful in situations where you simply want to run two communities of OSPF routers on the same wire. It is also good for places where you don't want inadvertent participation in the OSPF routing domain. You many "trust" the people who have access to the physical networks running OSPF or have sufficient motivation for them to behave. With respect to MD5 authentication - this is currently widely deployed and it will take some time to be replaced. Hence, I think the whole draft could be replaced by a statement to the effect that "Users desiring cryptographic authentication may consider using algorithms x, y, or z due to the vulnerabilities in MD5. ....". Thanks, Acee On Mar 28, 2007, at 8:43 AM, Acee Lindem wrote: After discussions with members of the ISIS WG, there is a third option which would be to accept draft-bhatia-manral-white-ospf-hmac-sha-03.txt but not draft-bhatia-manral-crypto-req-ospf-01.txt. I'd like to throw that out as an option. Thanks, Acee On Mar 27, 2007, at 9:16 AM, Acee Lindem wrote: These drafts were presented in San Diego and seem to have considerable support. draft-bhatia-manral-crypto-req-ospf-01.txt draft-bhatia-manral-white-ospf-hmac-sha-03.txt Hence, we plan to make these WG documents unless there is significant opposition or a compelling reason not to do so. Thanks, Acee _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
