Subject: [Netconf] Upgrade vs. downgrade

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 03 Mar 2014 12:16:54 -0500

A point was raised during the meeting that the ZeroTouch draft should 
allow for an image _upgrade_ only (where new image has a version > old 
image).  There were counter points raised that as long as the image is 
signed, it shouldn't matter the direction (up or down[grade]).

I agree with the counter points.  We have seen cases where a newer rev 
of code (sometimes with newer features) includes new security bugs that 
can be exploited when the older version of code is safe.  To say we can 
only go up doesn't protect the operator from a security vulnerability.

Additionally, as was raised as a counter-point, operators may have a 
standard image that they need for their environment (sometimes to have 
the device work at all).  This may be a down-revved image from what is 
shipped on the device.

I think we should allow for image moves in any direction as long as they 
can be verified and validated as is pointed out in the draft currently.

Joe

---

From: ian duncan <[email-masked]>
Date: Mon, 3 Mar 2014 12:39:35 -0500

Hello --

Having taken to the mike to challenge Wes I offer the following.

Believe I understand a desire to confirm one is NOT regressing to a more
broken code image. What I'd wanted to question is whether the mechanism
suggested was suitable to achieve this goal, and in particular in a case
where little to no correlation exists between the code running the initial
ZTP firmware and the ultimate desired functional code image. Phrased as a
question, how can one presumptively infer from arbitrary version numbering
embedded that some code image has fewer issues--security related or
otherwise?

Thanks .. Ian

On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke <[email-masked]>wrote:

> I agree with the counter points.  We have seen cases where a newer rev of
> code (sometimes with newer features) includes new security bugs that can be
> exploited when the older version of code is safe.  To say we can only go up
> doesn't protect the operator from a security vulnerability.
>
> standard image that they need for their environment (sometimes to have the
> device work at all).  This may be a down-revved image from what is shipped
> on the device.
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 03 Mar 2014 18:54:27 +0000

There may also be occasions where a few devices are moved from a system 
running version n+1 to another running version n and it would be easier 
or even necessary to downgrade the few than upgrade the many.

Jonathan

On 03/03/2014 17:39, ian duncan wrote:
> Believe I understand a desire to confirm one is NOT regressing to a 
> more broken code image. What I'd wanted to question is whether the 
> mechanism suggested was suitable to achieve this goal, and in 
> particular in a case where little to no correlation exists between the 
> code running the initial ZTP firmware and the ultimate desired 
> functional code image. Phrased as a question, how can one 
> presumptively infer from arbitrary version numbering embedded that 
> some code image has fewer issues--security related or otherwise?
>
> Thanks .. Ian
>
>
>
>
>
>
>
>
>
> On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     A point was raised during the meeting that the ZeroTouch draft
>     should allow for an image _upgrade_ only (where new image has a
>     version > old image).  There were counter points raised that as
>     long as the image is signed, it shouldn't matter the direction (up
>     or down[grade]).
>
>     I agree with the counter points.  We have seen cases where a newer
>     rev of code (sometimes with newer features) includes new security
>     bugs that can be exploited when the older version of code is safe.
>      To say we can only go up doesn't protect the operator from a
>     security vulnerability.
>
>     Additionally, as was raised as a counter-point, operators may have
>     a standard image that they need for their environment (sometimes
>     to have the device work at all).  This may be a down-revved image
>     from what is shipped on the device.
>
>     I think we should allow for image moves in any direction as long
>     as they can be verified and validated as is pointed out in the
>     draft currently.
>
>     Joe
>
>     [email-masked] <mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Mar 2014 17:47:22 +0000

The majority sentiment seems to be that the draft should not require images to be greater than what the device is running.

So no update to the text in the draft on this point.

K.

From: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 3, 2014 6:54 PM
To: ian duncan <[email-masked]<mailto:[email-masked]>>, Joe Marcus Clarke <[email-masked]<mailto:[email-masked]>>
Cc: NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Upgrade vs. downgrade

There may also be occasions where a few devices are moved from a system running version n+1 to another running version n and it would be easier or even necessary to downgrade the few than upgrade the many.

Jonathan

Believe I understand a desire to confirm one is NOT regressing to a more broken code image. What I'd wanted to question is whether the mechanism suggested was suitable to achieve this goal, and in particular in a case where little to no correlation exists between the code running the initial ZTP firmware and the ultimate desired functional code image. Phrased as a question, how can one presumptively infer from arbitrary version numbering embedded that some code image has fewer issues--security related or otherwise?

Thanks .. Ian

On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke <[email-masked]<mailto:[email-masked]>> wrote:
A point was raised during the meeting that the ZeroTouch draft should allow for an image _upgrade_ only (where new image has a version > old image).  There were counter points raised that as long as the image is signed, it shouldn't matter the direction (up or down[grade]).

I agree with the counter points.  We have seen cases where a newer rev of code (sometimes with newer features) includes new security bugs that can be exploited when the older version of code is safe.  To say we can only go up doesn't protect the operator from a security vulnerability.

Additionally, as was raised as a counter-point, operators may have a standard image that they need for their environment (sometimes to have the device work at all).  This may be a down-revved image from what is shipped on the device.

I think we should allow for image moves in any direction as long as they can be verified and validated as is pointed out in the draft currently.

Joe

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

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