Sorry .. I sent an incomplete mail .. ;)
On 29/08/06, Tom Sanders <[EMAIL PROTECTED]> wrote:
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.
I assume you are at this point referring to
draft-bhatia-manral-white-ospf-hmac-sha-02.txt. Lets not rehash the
same discussion regarding overloading Auth 2 here.
>
> 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.
Which is where the draft-bhatia-manral-crypto-req-ospf-00.txt helps.
The authors can correct me if i am wrong in my understanding here.
>
> 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?
MD5 is MUST- while HMAC-SHA-1 is SHOULD+.
I think the definitions in the beginning of the draft would help.
Reading those again tells me that we may at some later point deprecate
MD5 and mandate support for hmac-sha-1 for all the implementations.
hmac-sha-1 would then be a MUST and the other higher variants of
hmac-sha SHOULD+.
Toms.
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
