Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai

["Bhatia, Manav (Manav)" <[e-mail]>]

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:[e-mail]] 
> Sent: Tuesday, April 12, 2011 10.57 AM
> To: Bhatia, Manav (Manav); Michael Barnes; [e-mail]; Abhay Roy
> Cc: [e-mail]
> 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)" <[e-mail]>
> To: Michael Barnes <[e-mail]>,        "[e-mail]"
> <[e-mail]>, Abhay Roy <[e-mail]>Cc: "[e-mail]"
> <[e-mail]>
> 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
> 
>