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

[Vishwas Manral <[e-mail]>]

Hi Acee/ Manav,

Good to see we have nearly converged.

I see no reason to mention how to break up the 64 bit sequence number, we
should just mention the behavior desired from that sequence number.

The actual generation of the should be implementation specific. This is no
different from any other spec.

Thanks,
Vishwas
On Wed, Apr 13, 2011 at 10:40 AM, Acee Lindem <[e-mail]>wrote:

> Hi Manav,
>
> On Apr 13, 2011, at 1:29 PM, Bhatia, Manav (Manav) wrote:
>
> > Ok, I give up - lets increase the sequence space to 64 bits! I seem to be
> the only one who is opposing adding something that I have myself proposed in
> some other draft! :)
> >
> > I am not very comfortable with mandating that upper 32 bits should be
> retrieved from the non volatile storage because there may be devices that
> cannot do this (i.e. may not be able to store data in nvram) and they will
> thus become non compliant to the about-to-be-RFC. How does a device that's
> wants to do AT but cant store info in nvram ever become compliant to this
> standard?
> >
> > I see two ways to deal with this:
> >
> > (1) The text on upper 32 bits should be a MAY and not a MUST, so that
> implementations that don't have nvram or don't want to implement this part
> of the spec still remain compliant to the standard.
>
> I'd vote for this option since I'd bet that devices sophisticated enough to
> run OSPFv3 deployed in places where you care about replay protection across
> cold restarts will have some form of non-volatile memory. Hence, I'd make it
> a SHOULD instead of a MUST.
>
> Thanks,
> Acee
>
>
> >
> > OR
> >
> > (2) We just increase the sequence space to 64 bits and don't say anything
> about it. We let a later RFC define how the upper 32 bits may be populated.
> >
> > Cheers, Manav
> >
> >> -----Original Message-----
> >> From: Acee Lindem [mailto:[e-mail]]
> >> Sent: Wednesday, April 13, 2011 9.48 PM
> >> To: Bhatia, Manav (Manav)
> >> Cc: [e-mail]
> >> Subject: Re: [OSPF] WG Last Call for Supporting
> >> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
> >>
> >> Hi Manav,
> >>
> >> On Apr 13, 2011, at 12:12 PM, Bhatia, Manav (Manav) wrote:
> >>
> >>> Hi Acee,
> >>>
> >>> The reason I didn't want a 64 bit non-decreasing sequence
> >> number in AT is because we are not yet sure if that's the
> >> final approach that we will take. While it appears that this
> >> is probably the path that we will go down with eventually, I
> >> would really like to wait till this gets finalized.
> >>
> >> I believe we all accept that this is not necessarily the
> >> final solution. However, the 64 bit sequence number is better
> >> (as discussed in the E-mail thread between you, Sam, and
> >> myself) is much better than what we have with OSPFv2 today.
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >>>
> >>> In the OSPFv2 draft, its trivial to define a new Auth type
> >> for OSPFv3 which expands the sequence space to 64 bits, for
> >> folks that really want to use an expanded sequence space.
> >>>
> >>> Cheers, Manav
> >>>
> >>>> -----Original Message-----
> >>>> From: Acee Lindem [mailto:[e-mail]]
> >>>> Sent: Wednesday, April 13, 2011 9.36 PM
> >>>> To: Bhatia, Manav (Manav)
> >>>> Cc: Vishwas Manral; Michael Barnes; [e-mail]
> >>>> Subject: Re: [OSPF] WG Last Call for Supporting
> >>>> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
> >>>>
> >>>> 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:[e-mail]]
> >>>>>> Sent: Wednesday, April 13, 2011 8.32 PM
> >>>>>> To: Bhatia, Manav (Manav)
> >>>>>> Cc: Vishwas Manral; Michael Barnes; [e-mail]
> >>>>>> 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:[e-mail]]
> >>>>>> Sent: Tuesday, April 12, 2011 10.32 PM
> >>>>>> To: Michael Barnes
> >>>>>> Cc: Bhatia, Manav (Manav);
> >>>>>> [e-mail]<mailto:[e-mail]>; Abhay Roy;
> >>>>>> [e-mail]<mailto:[e-mail]>
> >>>>>> 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
> >>>>>> <[e-mail]<mailto:[e-mail]>> wrote:
> >>>>>> Hello Manav,
> >>>>>>
> >>>>>> ------ Original Message ------
> >>>>>> Received: Mon, 11 Apr 2011 10:05:36 PM PDT
> >>>>>> From: "Bhatia, Manav (Manav)"
> >>>>>> <[e-mail]<mailto:manav.bhatia@alcatel-l
> >>>>>> ucent.com>>
> >>>>>> To: Michael Barnes
> >>>>>> <[e-mail]<mailto:[e-mail]>>,
> >>>>>> "[e-mail]<mailto:[e-mail]>"
> >>>>>> <[e-mail]<mailto:[e-mail]>>, Abhay Roy
> >>>>>> <[e-mail]<mailto:[e-mail]>>Cc:
> >>>>>> "[e-mail]<mailto:[e-mail]>"
> >>>>>> <[e-mail]<mailto:[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
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OSPF mailing list
> >>>>>> [e-mail]<mailto:[e-mail]>
> >>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OSPF mailing list
> >>>>>> [e-mail]<mailto:[e-mail]>
> >>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>
>