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

[Paul Wells <[e-mail]>]

Hi Manav,

I'd like to second this. I'd like to minimize the number of 
variations I need to develop and support. The 64-bit sequence 
number space may not be the ultimate answer, but it's just as easy 
to implement as a 32-bit space and can more readily be made 
non-decreasing.

Put another way, what is the advantage of a 32-bit sequence number?

Regards,
Paul

On 04/13/2011 11:18 AM, Acee Lindem wrote:
> 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