Erblichs,
I am not sure if Vishwas addressed your concern. If he did, then i am
at fault in understanding your concern. However, let me give it a
shot.
First. Up to this point, IMO, 99%+ nbr misconfigs
could be debuged at 1 local router with review of
incoming pkts. With this "work-in-progress",
this will NO longer be the case if we overload
type 2.
What is a 'Must' clause going to achieve?
By default ALL implementations support MD5, simple/clear,
and NULL auth. The only high probability of a nbr
formation is to use one of these three. Yes, MD5 was
the defacto standand auth 2 algor.
Thus, any algor that super-ceeds one of these auths,
at this time, will not guarantee interoperability.
However, as pointed out in the draft, the highest
common auth is not highly secure, but could be used
as a fall back. Yes, the admin would see either before
or after a nbr formation attempt that a mismatch
exists, and reconfigs the routers to use the fallback.
Thus, to support backward compatibility and to secure
against SOME attacks, IMO all configs SHOULD/MUST support
MD5.
If this is the case, would the clause only improve the
chance that "MD5" is not removed as newer algors are
supported?
Or is their a thought for a algor other than MD5 to
specified as the MUST algor?
Mitchell Erblich
----------------
Vishwas Manral wrote:
>
> Sujay,
>
> I agree we can include that in the draft. The reason as well as the
> links to the draft.
>
> Thanks,
> Vishwas
>
> On 8/24/06, sujay <[EMAIL PROTECTED]> wrote:
> > Agree,
> > While a failed authentication could be basically due to configuration issues
> > or
> > Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported
> > algo'
> > may need an Image upgrade. It's my guess image upgrade may not be
> > thoroughly welcome.
> > We do need a 'Must' support algo. clause.
> >
> > Vishwas ; would it be a nice idea to add a section in the current draft,
> > talking about this issue
> > and with cross reference to the below mentioned drafts??
> >
> >
> > Regds,
> > Sujay G
> > My Location;
> > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h
> > &hl=en
> >
> >
> > This e-mail and attachments contain confidential information from HUAWEI,
> > which is intended only for the person or entity whose address is listed
> > above. Any use of the information contained herein in any way (including,
> > but not limited to, total or partial disclosure, reproduction, or
> > dissemination) by persons other than the intended recipient's) is
> > prohibited. If you receive this e-mail in error, please notify the sender by
> > phone or email immediately and delete it!
> > -----Original Message-----
> > From: Vishwas Manral [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 24, 2006 10:24 AM
> > To: [EMAIL PROTECTED]
> > Cc: [email protected]; Mailing List
> > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft
> >
> > Paul,
> >
> > > There is though value in defining "MUST support" algos, otherwise poor
> > > users could be faced with having routers which all implement OSPF but
> > > can be made to interoperate unless authentication is left
> > > unconfigured.
> > We have drafts to meet the following exact requirements:
> > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t
> > xt
> > and
> > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t
> > xt
> >
> > for OSPF and IS-IS respectively.
> >
> > Thanks,
> > Vishwas
> >
> > On 8/24/06, Paul Jakma <[EMAIL PROTECTED]> wrote:
> > > On Wed, 23 Aug 2006, Dave Katz wrote:
> > >
> > > > Sigh. C'mon, folks, there is no problem.
> > >
> > > > At the end of the day it doesn't matter if the value of 2 or 3 or
> > > > 42 is used; if there's a mismatch on the the algorithm ID, the
> > > > algorithm, or the key, the authentication will fail, and if it all
> > > > matches, it will work.
> > >
> > > Strongly concur.
> > >
> > > There is though value in defining "MUST support" algos, otherwise poor
> > > users could be faced with having routers which all implement OSPF but
> > > can be made to interoperate unless authentication is left
> > > unconfigured.
> > >
> > > MD5 at least should be defined as a MUST support.
> > >
> > > (Despite the pre-image weaknesses, it's still not yet completely
> > > insecure in MAC mode)
> > >
> > > regards,
> > > --
> > > Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
> >
> > _______________________________________________
> > 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
--
Toms.
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
