Hi Manav, On Apr 13, 2011, at 11:56 AM, Bhatia, Manav (Manav) wrote:
> Hi Acee, > > I am ok with adding the sequence number strictly increasing in the AT draft. > What I was opposing was to include the nonce or the 64 bit auth sequence > space that has been proposed for OSPFv2. I agree with the nonce but I don't see why we don't use the 64-bit sequence number. We've changed a number of things from the existing OSPFv2 authentication trailer already and using a 64 bit non-decreasing sequence number is a relatively small change. Thanks, Acee > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:[email protected]] >> Sent: Wednesday, April 13, 2011 8.32 PM >> To: Bhatia, Manav (Manav) >> Cc: Vishwas Manral; Michael Barnes; [email protected] >> Subject: Re: [OSPF] WG Last Call for Supporting >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >> >> Hi Manav, >> >> OTOH, we could add the strictly increasing 64 bit sequence >> number to OSPFv3 Auth Trailer draft without too much trouble. >> Even though it might not end up to be exactly what is used >> for the OSPFv2 draft, it seems there is a requirement to do >> something better than is done today. Right now, the OSPFv2 IP >> layer security draft still has all the nounce stuff in it. >> The 64 sequence was primarily a product of the E-mail thread >> between you, Sam, and myself. >> >> Thanks, >> Acee >> >> On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote: >> >> Hi Vishwas, >> >> As i have explained earlier, AT is a complete solution and >> none of the current proposals in KARP (nonce ID, boot count, >> etc) will be invalidating it. AT provides the basic >> infrastructure over which other these will get built. The two >> are thus not comparable. >> >> Cheers, Manav >> >> ________________________________ >> From: Vishwas Manral [mailto:[email protected]] >> Sent: Tuesday, April 12, 2011 10.32 PM >> To: Michael Barnes >> Cc: Bhatia, Manav (Manav); >> [email protected]<mailto:[email protected]>; Abhay Roy; >> [email protected]<mailto:[email protected]> >> Subject: Re: [OSPF] WG Last Call for Supporting >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai >> >> Hi Manav/ Mike, >> >> Though it is ok to have another draft invalidate this one >> after some time. It would be a challenge to get >> implementations to change as fast (if at all). >> >> In my view if the current solution is deemed incomplete, we >> can correct the current solution. >> >> Thanks, >> Vishwas >> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes >> <[email protected]<mailto:[email protected]>> wrote: >> Hello Manav, >> >> ------ Original Message ------ >> Received: Mon, 11 Apr 2011 10:05:36 PM PDT >> From: "Bhatia, Manav (Manav)" >> <[email protected]<mailto:manav.bhatia@alcatel-l >> ucent.com>> >> To: Michael Barnes >> <[email protected]<mailto:[email protected]>>, >> "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>>, Abhay Roy >> <[email protected]<mailto:[email protected]>>Cc: >> "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[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]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
