Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf