Hi Vishwas,
To quote the old adage, "You can bring a horse to water but you can't
make'em drink."
Maybe a document of a more general dealing with IGPs in RPSEC WG
would be more appropriate. I just don't think we're ever going to
agree on this document in this WG.
Thanks,
Acee
On Mar 28, 2007, at 12:01 PM, Vishwas Manral wrote:
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
