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

From: "Michael Barnes" <[email-masked]>
Date: Mon, 11 Apr 2011 22:27:27 -0700

Hello Manav,

------ Original Message ------
Received: Mon, 11 Apr 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <[email-masked]>
To: Michael Barnes <[email-masked]>,        "[email-masked]"
<[email-masked]>, Abhay Roy <[email-masked]>Cc: "[email-masked]"
<[email-masked]>
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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 Apr 2011 11:04:04 +0530

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-masked]] 
> Sent: Tuesday, April 12, 2011 10.57 AM
> To: Bhatia, Manav (Manav); Michael Barnes; [email-masked]; Abhay Roy
> Cc: [email-masked]
> Subject: RE: [OSPF] WG Last Call for Supporting 
> Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
> 
> Hello Manav,
>

---

From: Glen Kent <[email-masked]>
Date: Tue, 12 Apr 2011 20:42:32 +0530

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-masked]> wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Apr 2011 10:02:13 -0700

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 02:11:28 +0530

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-masked]]
Sent: Tuesday, April 12, 2011 10.32 PM
To: Michael Barnes
Cc: Bhatia, Manav (Manav); [email-masked]; Abhay Roy; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hello Manav,

------ Original Message ------
Received: Mon, 11 Apr 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <[email-masked]<mailto:[email-masked]>>
To: Michael Barnes <[email-masked]<mailto:[email-masked]>>,        "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>, Abhay Roy <[email-masked]<mailto:[email-masked]>>Cc: "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer for
OSPFv3 - draft-ietf-ospf-auth-trai

Regards,
Michael

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 13 Apr 2011 11:01:47 -0400

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,

Cheers, Manav

Cc: Bhatia, Manav (Manav); [email-masked]<mailto:[email-masked]>; Abhay Roy; [email-masked]<mailto:[email-masked]>

Hi Manav/ Mike,

Thanks,
Vishwas

------ Original Message ------
Received: Mon, 11 Apr 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <[email-masked]<mailto:[email-masked]>>
To: Michael Barnes <[email-masked]<mailto:[email-masked]>>,        "[email-masked]<mailto:[email-masked]>"

Regards,
Michael

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 21:26:20 +0530

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.

Cheers, Manav

> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Wednesday, April 13, 2011 8.32 PM
> To: Bhatia, Manav (Manav)
> Cc: Vishwas Manral; Michael Barnes; [email-masked]
> Subject: Re: [OSPF] WG Last Call for Supporting 
> 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
> 
> 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
> 
> Cc: Bhatia, Manav (Manav); 
> [email-masked]<mailto:[email-masked]>; Abhay Roy; 
> [email-masked]<mailto:[email-masked]>
> Subject: Re: [OSPF] WG Last Call for Supporting 
> 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).
> 
> On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes 
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hello Manav,
> 
> From: "Bhatia, Manav (Manav)" 
> <[email-masked]<mailto:manav.bhatia@alcatel-l
> ucent.com>>
> To: Michael Barnes 
> <[email-masked]<mailto:[email-masked]>>,      
>   "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Abhay Roy 
> <[email-masked]<mailto:[email-masked]>>Cc: 
> "[email-masked]<mailto:[email-masked]>"

---

From: Acee Lindem <[email-masked]>
Date: Wed, 13 Apr 2011 12:06:11 -0400

Hi Manav,

> 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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 21:42:01 +0530

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. 

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

> Sent: Wednesday, April 13, 2011 9.36 PM
> > 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
> >

---

From: Acee Lindem <[email-masked]>
Date: Wed, 13 Apr 2011 12:18:21 -0400

Hi Manav,

> 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…

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

---

From: Paul Wells <[email-masked]>
Date: Wed, 13 Apr 2011 11:50:13 -0500

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 22:59:24 +0530

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.

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

> Sent: Wednesday, April 13, 2011 9.48 PM
> > 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
> >

---

From: Acee Lindem <[email-masked]>
Date: Wed, 13 Apr 2011 13:40:24 -0400

Hi Manav,

> (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

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 13 Apr 2011 10:45:57 -0700

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 <[email-masked]>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?
> >
> > (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
> >

---

From: Russ White <[email-masked]>
Date: Wed, 13 Apr 2011 13:45:47 -0400

> 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-vola…

I'd vote for this option, as well. It provides the best chance of
providing what's needed to prevent replays.

:-)

Russ

---

From: Acee Lindem <[email-masked]>
Date: Wed, 13 Apr 2011 16:05:34 -0400

Hi Vishwas, Manav,

On Apr 13, 2011, at 1:45 PM, Vishwas Manral wrote:

Hi Acee/ Manav,

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.

This is ok with me as well - I'll simply include the sequence number requirements and we can review before resubmitting a new revision.

All,

Although we'll restart the WG last call with the new revision. Please send any additional comments on the draft.

Thanks,
Acee

Thanks,
Vishwas
On Wed, Apr 13, 2011 at 10:40 AM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:
Hi Manav,

Thanks,
Acee

>> From: Acee Lindem [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>
>>>> From: Acee Lindem [mailto:[email-masked]<mailto:[email-masked]>]
>>>> Cc: Vishwas Manral; Michael Barnes; [email-masked]<mailto:[email-masked]>
>>>>>> From: Acee Lindem [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> Cc: Vishwas Manral; Michael Barnes; [email-masked]<mailto:[email-masked]>
>>>>>> From: Vishwas Manral [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Abhay Roy;
>>>>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>> Hello Manav,
>>>>>>
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:manav.bhatia@alcatel-l<mailto:manav.bhatia@alcatel-l>
>>>>>> ucent.com<http://ucent.com/>>>
>>>>>> To: Michael Barnes
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>>>>> "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Abhay Roy
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>Cc:
>>>>>> "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
>>>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>>>>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>>>>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>