I think i'll agree with Manav - Lets leave the current draft as is. Its extensible and can support the future extensions that are being currently defined for OSPFv2.
Glen On Tue, Apr 12, 2011 at 11:04 AM, Bhatia, Manav (Manav) <[email protected]> wrote: > Hi Michael, > > Different boxes would require different kind of security properties. There > are many boxes/deployments that would not care about the inter-session replay > attack or may not have the capability to store additional information in > non-volatile memory or may not want the additional complexity that the nonce > and the session ID brings in. Those devices may just want to use the AT block > as is currently defined. > > I don't see any reason why we should preclude the possibility of such devices > existing. > > I would have agreed to delay this based on KARP result if it would have > entailed a significant change in the AT design. Since it doesn't, I see no > reason why we should do that. > > Cheers, Manav > >> -----Original Message----- >> From: Michael Barnes [mailto:[email protected]] >> Sent: Tuesday, April 12, 2011 10.57 AM >> To: Bhatia, Manav (Manav); Michael Barnes; [email protected]; Abhay Roy >> Cc: [email protected] >> Subject: RE: [OSPF] WG Last Call for Supporting >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >> >> Hello Manav, >> >> ------ Original Message ------ >> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >> From: "Bhatia, Manav (Manav)" <[email protected]> >> To: Michael Barnes <[email protected]>, "[email protected]" >> <[email protected]>, Abhay Roy <[email protected]>Cc: "[email protected]" >> <[email protected]> >> Subject: RE: [OSPF] WG Last Call for Supporting >> Authentication Trailer for >> OSPFv3 - draft-ietf-ospf-auth-trai >> >> > Hi Michael, >> > >> > > > right direction and would not have to be revisited >> quite as soon if >> > > > something more robust were proposed. >> > > > >> > > > Bottom line. Falls short of what I'd like to see but >> no objection. >> > > > >> > > > Curtis >> > > >> > > I agree with Curis. I'd really like to see the first version >> > > of this spec at >> > > least have the extended sequence number as is being >> discussed for v2. >> > >> > I disagree that AT should have a 64 bit sequence space in the base >> specification primarily because we are not yet sure if the >> KARP boot count >> approach is what the WG will finally converge on (in which >> case we would need >> an extended sequence space). Also note that the AT provides >> an "Auth Type" >> field which can be assigned a new value (similar to how it >> will be done for >> OSPFv2) once we decide to move to a different scheme. The >> same standard that >> extends the OSPFv2 sequence space can also do it for OSPFv3 >> AT block - really >> hardly an overhead. >> > >> > Also note that you could consider this proposal as just >> bringing OSPFv3 at >> par with OSPFv2. Once this is done, any proposal that extends >> OSPFv2 will >> natively work for OSPFv3 as well. >> >> So you are saying that this flaw is okay with you? I'd rather >> hold off on >> pushing this forward until this flaw is fixed. And I think >> waiting to see what >> happens in KARP might be a good idea. >> >> Regards, >> Michael >> >> > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
