Manav,
We dont need to use a new auth type value for each new authentication scheme >
that comes up in the future.
One can define a new generic auth type 3, which would carry the authentication
> algorithm details in addition to the Key ID, auth data length and the crypto
sequence number. The authentication data for type auth type 3 would be the
same as type 2, except that the reserved bytes would get replaced with the
authentication algorithm ID.
Excellent, this is much better than our initial guess.
Actually one octet is enough for carrying the Algo ID. You are still
left with one reserved octet. Go Play!
However, i dont think this is required.
Well, thats something that the WG, and not you and me, have to decide! :)
Cheers,
Manav
>> On 20/08/06, Phil Cowburn <[EMAIL PROTECTED]> wrote:
>>
>> I strongly agree with Manav here and an implementation must be able to
>> demultiplex using the Key ID in the incoming packet. It is afterall
>> for this very reason that we put the Key ID in the packet.
>>
>> Erblichs point, as i read it is, that most implementations (if not
>> all) currently take type 2 to mean MD5. This may break once this draft
>> becomes a standard, which it would, in some time.
>>
>> My take on this is that even if the WG agrees to Erblichs solution and
>> introduces a new type, say 3 for HMAC-SHA-1 authentication, then
>> somebody else could repeat the same argument and clamour for a new
>> type when we're introducing newer authentication algorithms in the
>> future.
>>
--
Toms.
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
