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
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
