Re: [OSPF] Re: Stronger Non-IPSec OSPFv2 Authentication

["Phil Cowburn" <[e-mail]>]

Acee and Vishwas:

I find value in the spirit behind
draft-bhatia-manral-crypto-req-ospf-01.txt and would like to see it
kept alive.

There may not be a burning need for such a document today because
there arent many authentication algorithms that can be used for OSPF
currently. However, with time as those would grow, you would have to
define some minimal set of algorithms that each implementation would
have to support for the basic interop to work.

This is not a new point and has been raised earlier also in this WG.

http://www.mail-archive.com/[e-mail]/msg00155.html
http://www.mail-archive.com/[e-mail]/msg00156.html

Now whether this work belongs to this WG or some other (RPSEC?) is an
altogether different issue. Regardless of that, i would like to see it
progressed further.

While we're on this topic i would also like to lend my support for
draft-bhatia-manral-white-ospf-hmac-sha-03.txt to be made as a WG doc.

Phil.

On 3/29/07, Vishwas Manral <[e-mail]> wrote:
> Hi Acee,
>
> I did hear a similar requirement from Sandy and may be a few others
> too regarding this very document.
>
> If we dont hear from others here anymore we can probably look what we
> can do for the progress of the draft. Suggestions like the ones you
> have given would be helpful.
>
> Thanks,
> Vishwas
>
> On 3/28/07, Acee Lindem <[e-mail]> wrote:
> > 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 <[e-mail]> 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
> > >> [e-mail]
> > >> https://www1.ietf.org/mailman/listinfo/ospf
> > >>
> > >> _______________________________________________
> > >> OSPF mailing list
> > >> [e-mail]
> > >> https://www1.ietf.org/mailman/listinfo/ospf
> > >>
> > >>
> >
> >
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf