Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-security-15.txt

From: David Conrad <[email-masked]>
Date: Fri, 15 Oct 2010 12:16:26 -1000

Mark,

On Oct 15, 2010, at 11:48 AM, Mark Smith wrote:
> So it won't be possible for the ISP to provide a
> managed CPE service, because they don't control and can't be in control
> of when the firmware is released to the CPE customers.

I'd think that recommending having an option that disables unattended automatic update would address this concern.  Managed service providers, since they'd be controlling the CPE, could go in and disable unattended automatic updates (if they so desire).

> If the draft is going to persist with specifying that firmware is
> automatically distributed and installed, then it is also going to have
> to specify mechanisms as to how ISPs are going to put inline with this
> process, between the vendor and the CPE, so they're going to be able to
> prevent automatic upgrades occurring at times when it is inconvenient to
> customers.

Not really.

> o  would you be happy that your Internet attached TV's firmware is

Sort of like my TiVo updating itself?

> o  would you be happy that your (eventual) Internet attached ECU's
[...]
> o  would you be happy that your Internet attached plane's firmware is

Presumably, vendors would figure out how to do upgrades with minimal risk if the decided to follow the IETF recommendations, e.g., the ECU can easily tell when the car isn't running (or even occupied) and a plane's systems can easily determine whether the engines are running (or whatever). Posing reductio ad absurdum scenarios probably isn't really helping the discussion.

> I certainly understand the issue of CPE firmware not being upgraded
> regularly.

According to recent data out of DNS-OARC, there are between 160,000 and 320,000 name servers on the Internet still running BIND version 4 -- a name server that has been deprecated by ISC now for almost a decade.

People generally do not interact with CPE devices outside of perhaps initial installation/configuration.  They might cycle the power once in a while, but otherwise it is a black box.  These unattended devices have proven to be a target for various forms of attacks. I believe we should learn from past (and current) experiences and make recommendations that address those experiences.  Assuming that folks are going to become more conscientious about installing updates hasn't really worked in the past, I'm unsure why it will work in the future.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Oct 2010 11:40:21 +1300

> I'd think that recommending having an option that disables unattended automatic update would address this concern.  Managed service providers, since they'd be controlling the CPE, could go in and d…

I think the discussion has shown that we (the IETF) don't have consensus
and that legal and commercial requirements will vary enormously in the
real world. To me there's only one possible conclusion: the IETF can't
"legislate" on this. So again here is my suggestion:

REC-13:
Residential Internet Gateways SHOULD provide a convenient means to
securely update their firmware, for the installation of security patches
and other manufacturer-recommended changes.

    Brian

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Oct 2010 11:40:07 -0700

> and other manufacturer-recommended changes.

I have been following this discussion with a view to figuring out what recommendations SHOULD be made :-) A key concern I have here, as I said last week, is the difference between a residential gateway and a laptop; A laptop's owner at least knows whether an irritating icon is jumping up and down or has the opportunity to see a dialog box; I don't see that happening with the router in my equipment closet under the stairs.

It seems that we agree that there are at least two options that need support:
   - automated software update
   - manually initiated software update

One could go into other mechanisms such as having the user download the new image to a laptop and then TFTP it to a router. Some things are best left unsuggested, for fear that the vendor might say "hey, that's a great idea!".

In both cases, the update has to be initiated by the residential CPE, for scale and reliability, and if automated should be randomized in time for reasons discussed in RFC 3439. Having the ISP or the vendor manage a list of the IP addresses of deployed routers is (ahem) problematic.

In both cases, we need a way to specify the URL and certificate of the download site. I should imagine the vendor would preconfigure them, and an ISP running managed services could configure a different URL+certificate in routers it deploys. There is of course the question of what happens should the parameter memory get zapped; I would leave that to the vendor. There is also the question of how the device knows whether it has already downloaded the image; I for one would do that by having the URL change itself, so that the client system ca always get access to an older image as a recovery path and so it can tell whether the image it is requesting is in fact new.

In preceding recommendations, the format of the document is to state a recommendation and follow it with an explanatory note. 

Which brings me to this suggestion:

/*
 * suggestion
 */
REC-13:
Residential Internet Gateways SHOULD provide a convenient means to securely update their firmware, for the installation of security patches and other manufacturer-recommended changes.

Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automated update and some preferring manual initiation, and those preferring automated update wanting to download from a vendor site or one managed by the network operator. To handle the disparity, vendors are well advised if they provide manual and automated options. In the automated case, they would do well to facilitate pre-configuration of the download URL and a means of validating the software image such as a certificate.
/*
 * end of suggestion
 */

Opinions?

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Oct 2010 21:16:59 +0200

Hi,

> Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automated update and some preferring manual initiation, and those preferring…

Works for me.  Both from the ISP side and from the end user side.

Gert Doering
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 19 Oct 2010 15:19:06 -0400

Me too

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gert Doering
> Sent: Tuesday, October 19, 2010 3:17 PM
> To: Fred Baker
> Cc: Operations; IESG IESG; [email-masked]
> Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-
> security-15.txt
> 
> Hi,
> 
> securely update their firmware, for the installation of security
> patches and other manufacturer-recommended changes.
> >
> > Vendors can expect users and operators to have differing viewpoints
> on the maintenance of patches, with some preferring automated update
> and some preferring manual initiation, and those preferring automated
> update wanting to download from a vendor site or one managed by the
> network operator. To handle the disparity, vendors are well advised if
> they provide manual and automated options. In the automated case, they
> would do well to facilitate pre-configuration of the download URL and a
> means of validating the software image such as a certificate.
> > /*
> >  * end of suggestion
> >  */
>

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Tue, 19 Oct 2010 16:11:15 -0400

It's fine.
Barbara

> Of [email-masked]
> Sent: Tuesday, October 19, 2010 4:01 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops]Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-
> security-15.txt
> 
> I like it. As Gert already said, it speaks to both views.
> 
> Of Fred Baker
> Sent: Tuesday, October 19, 2010 2:40 PM
> To: Operations; IESG IESG
> Cc: [email-masked]
> >> I'd think that recommending having an option that disables
> unattended automatic update would address this concern.  Managed
> service providers, since they'd be controlling the CPE, could go in
and
> disable unattended automatic updates (if they so desire).
> >
> patches
> I have been following this discussion with a view to figuring out what
> recommendations SHOULD be made :-) A key concern I have here, as I
said
> last week, is the difference between a residential gateway and a
> laptop; A laptop's owner at least knows whether an irritating icon is
> jumping up and down or has the opportunity to see a dialog box; I
don't
> see that happening with the router in my equipment closet under the
> stairs.
> 
> One could go into other mechanisms such as having the user download
the
> new image to a laptop and then TFTP it to a router. Some things are
> best left unsuggested, for fear that the vendor might say "hey, that's
> a great idea!".
> 
> In both cases, the update has to be initiated by the residential CPE,
> for scale and reliability, and if automated should be randomized in
> time for reasons discussed in RFC 3439. Having the ISP or the vendor
> manage a list of the IP addresses of deployed routers is (ahem)
> problematic.
> 
> In both cases, we need a way to specify the URL and certificate of the
> download site. I should imagine the vendor would preconfigure them,
and
> an ISP running managed services could configure a different
> URL+certificate in routers it deploys. There is of course the question
> of what happens should the parameter memory get zapped; I would leave
> that to the vendor. There is also the question of how the device knows
> whether it has already downloaded the image; I for one would do that
by
> having the URL change itself, so that the client system ca always get
> access to an older image as a recovery path and so it can tell whether
> the image it is requesting is in fact new.
> 
> In preceding recommendations, the format of the document is to state a
> recommendation and follow it with an explanatory note.
> 
> Vendors can expect users and operators to have differing viewpoints on
> the maintenance of patches, with some preferring automated update and
> some preferring manual initiation, and those preferring automated

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2010 09:29:21 +1300

Works for me too.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Oct 2010 07:23:04 +1030

Hi Fred,

I'm ok with it.

Regards,
Mark.

On Tue, 19 Oct 2010 11:40:07 -0700

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 16:00:48 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Tuesday, October 19, 2010 2:40 PM
To: Operations; IESG IESG
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-security-15.txt

/*
 * suggestion
 */
REC-13:

Opinions?

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 19 Oct 2010 22:20:06 -0500

I'm afraid if we use "SHOULD", CPE vendors will follow the path so far
followed, which is not building that option into their product.

I'd rather see a "MUST" to the automatic update functionality, but a
"SHOULD" in regards whether it's turned on by default or not.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred Baker
Sent: Tuesday, October 19, 2010 1:40 PM
To: Operations; IESG IESG
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D
Action:draft-ietf-v6ops-cpe-simple-security-15.txt

On Oct 15, 2010, at 3:40 PM, Brian E Carpenter wrote:

>> I'd think that recommending having an option that disables unattended
automatic update would address this concern.  Managed service providers,
since they'd be controlling the CPE, could go in and disable unattended
automatic updates (if they so desire).

I have been following this discussion with a view to figuring out what
recommendations SHOULD be made :-) A key concern I have here, as I said last
week, is the difference between a residential gateway and a laptop; A
laptop's owner at least knows whether an irritating icon is jumping up and
down or has the opportunity to see a dialog box; I don't see that happening
with the router in my equipment closet under the stairs.

It seems that we agree that there are at least two options that need
support:
   - automated software update
   - manually initiated software update

One could go into other mechanisms such as having the user download the new
image to a laptop and then TFTP it to a router. Some things are best left
unsuggested, for fear that the vendor might say "hey, that's a great idea!".

In both cases, the update has to be initiated by the residential CPE, for
scale and reliability, and if automated should be randomized in time for
reasons discussed in RFC 3439. Having the ISP or the vendor manage a list of
the IP addresses of deployed routers is (ahem) problematic.

In both cases, we need a way to specify the URL and certificate of the
download site. I should imagine the vendor would preconfigure them, and an
ISP running managed services could configure a different URL+certificate in
routers it deploys. There is of course the question of what happens should
the parameter memory get zapped; I would leave that to the vendor. There is
also the question of how the device knows whether it has already downloaded
the image; I for one would do that by having the URL change itself, so that
the client system ca always get access to an older image as a recovery path
and so it can tell whether the image it is requesting is in fact new.

/*
 * suggestion
 */
REC-13:
Residential Internet Gateways SHOULD provide a convenient means to securely
update their firmware, for the installation of security patches and other
manufacturer-recommended changes.

Vendors can expect users and operators to have differing viewpoints on the
maintenance of patches, with some preferring automated update and some
preferring manual initiation, and those preferring automated update wanting
to download from a vendor site or one managed by the network operator. To
handle the disparity, vendors are well advised if they provide manual and
automated options. In the automated case, they would do well to facilitate
pre-configuration of the download URL and a means of validating the software
image such as a certificate.
/*
 * end of suggestion
 */

Opinions?

---

From: Sam Silvester <[email-masked]>
Date: Wed, 20 Oct 2010 22:25:53 +1030

> Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automated update and some preferring manual initiation, and those preferring…

Covers both cases and explains the situation well. Looks good.

Sam