Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft

Hi Tom,

[..] 

> What i miserably fail to understand is the reluctance in the WG to use
> a new authentication type. We have 16 bits reserved for this field and
> i dont see this being used up any time in the coming future.
> 
> Explictly indicating the auth algo details in the header makes, in my
> view, debugging extremely easy. I understand that we would be eating
> up type codes that we would have to fill in the OSPF header each time
> we come up with a new authentication algorithm but given the size of
> this field i dont think its a point of concern.
> 
> The poll should be on whether we should proceed as-is in the draft or
> should we use a new type field for each new authentication scheme that
> we come out with?

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.

However, i dont think this is required.

Cheers,
Manav

>> On 20/08/06, Phil Cowburn <phil.cowburn@gmail.com> 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.
>>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf