Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard

[Acee Lindem <[e-mail]>]

Hi Manav,

On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote:

> Hi Acee,
> 
>>>> 
>>>> We change the hex that's repeated in the Apad from 
>> 0x878FE1F3 to 0x878FE1F4. This value will be unique for 
>> OSPFv3. Other protocols that use this mechanism must use a 
>> different value of Apad - you could think of this as 
>> "salting" the Apad.
>>> 
>>> Could we simply use the OSPFv3 protocol number, 89, in the 
>> Apad, e.g., 0x898FE1F4,  (or at least the first instance of 
>> Apad). Otherwise, we probably need a registry for IANA Apads. 
>> 
>> I meant 0x898FE1F3 as to not change the last 3 octets of the 
>> existing HMAC-SHAx Apad. 
> 
> We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad.

That's exactly what I'm proposing. 

> If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise.

Are you forgetting about the version as the first nibble of the header? 

> 
> This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. 

UDP/TCP protocols would need a scheme that includes their well-know port - perhaps, the second octet of the first instance of Apad ;^). 

> 
> We thus need a unique Apad that each standard can define if we want to protect ourselves from the attack that Sam describes.

Thanks,
Acee


> 
> Cheers, Manav