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

[Mark Smith <[e-mail]>]

Hi Fred,

On Thu, 14 Oct 2010 08:34:53 -0700
Fred Baker <[e-mail]> wrote:

> If the comment is not in this draft, then the work being done in the Broadband Forum on this topic should be replicated at Cable Labs for that class of networks. Question to their respective representatives: are you sufficiently on the same page that you can suggest a statement to go here, or would you prefer separate approaches from the Fora?
> 
> Mark: How would you suggest wording the "passing comment" regarding updates? It sounds like you would prefer something along the lines of:
> 
> REC-13:
> Residential Internet Gateways SHOULD provide a means for their owners to securely update their firmware, for the installation of security patches and other manufacturer-recommended changes. Owners are responsible to install the firmware, and encouraged to do so promptly, but the means of informing them of the availability of the update is beyond the scope of this document.
> 

Yes, I'd be happier with that. 

> </chair>
> I can see both sides of this. I configure my laptop (OS and applications) to automatically download patches and notify me of their availability, and I decide to install them. I like that on two counts: *I* maintain my patches, and I *maintain* my patches. The model makes sense with other software and firmware relevant to me as a consumer. On the other hand, patches get applied to my wife's and my daughter's laptops when I notice that they need to be applied (in my daughter's case, that means that I'm visiting her) and make it happen. If I were the manufacturer of the residential gateway in question, the only way I see to maintain the software would be to maintain an email list as people register their products and send them an email, as people can't be depended on to log into a manufacturer or ISP site periodically to get the news, and the residential gateway doesn't generally have a screen that the owner periodically looks at to announce the need for an update. We all know
  how emails tend to get lost in the noise...
> <chair>
> 

My issue isn't so much the automated downloading, it's the automated
installation. CPE typically needs to be rebooted to perform that task,
so automated installation means an unexpected service outage. So in the
middle of making a VoIP phone call to the boss (or to emergency
services!), accessing the corporate VPN, watching a streaming video
etc., there'd all of a sudden be an unexplained outage of typically a
few minutes, as well as typically would would be alarming flashing of
lights on the device. Very un-user friendly behaviour, and worse
because the ISP is likely to be the first to be blamed for it, and have
wear the consequences of dealing with unhappy customers. Unfortunately
I've recently had to deal with a situation where vendor faults on large
numbers of CPE devices were seen to be my (ISP) employer's
responsibility and it was very unpleasant to say the least.

As for mechanism for applying an update (which I do agree is out of
scope), one thought I had would be possibly an "Firmware Upgrade
Available" flashing LED on the CPE, and a specific button to be held
down for say 5 seconds to load it would be a fairly simple way to both
notify the end-user and allow them to control when it is applied.

Thanks,
Mark.



> All: opinions?
> 
> On Oct 14, 2010, at 3:21 AM, Mark Smith wrote:
> 
> > Hi Fred,
> > 
> > I'm really quite concerned about this new text,
> > 
> > REC-13: By DEFAULT, Internet gateways SHOULD, automatically download
> >   and install software updates for extending IPv6 simple security for
> >   support of future standard upper layer transports and extension
> >   headers.
> > 
> > in particular the automatic install, as I don't think the
> > consequences of automatically updating the firmware "behind the
> > customers back" have been fully considered. 
> > 
> > If there are any failures with this mechanism at all, the customer
> > will most likely be calling the ISP, not the product vendor, despite the
> > vendor being in control of and responsible for when this new firmware is
> > deployed. It will appear to the customer that the ISP's service has
> > failed. As an update is likely to be pushed out to many CPE at once,
> > that could result in floods of 100s, 1000s etc. of unexpected calls to
> > the ISP's helpdesk moments after the update occurs. It could also mean
> > that updates occur in the middle of when the ISP's services are most
> > used due to differing time zones between when the vendor pushes new
> > firmware out verses and when customers are most commonly using the
> > Internet services.  In this scenario the ISP should be in control of
> > when these updates are made available.
> > 
> > Following the model used by vendors of desktop OSes these days, it
> > would be better if when updates were pushed out, the customer was
> > alerted to an update being available, and the customer had to somehow
> > manually trigger the update, to avoid disrupting services. 
> > 
> > I think it'd probably be better to make only a passing comment about
> > keeping the firmware up to date, avoiding it being a specific SHOULD
> > recommendation, without details, in this document. The Broadband Forum,
> > with mechanisms such as TR-69, seem to be more thoroughly considering
> > these issues.
> > 
> > Regards,
> > Mark.
> > 
> > 
> > 
> > On Tue, 12 Oct 2010 11:36:09 -0700
> > Fred Baker <[e-mail]> wrote:
> > 
> >> This is a quick consensus check. The CPE Simple Security document is about to complete IESG review, and has gone through four revisions in the process of IETF Last Call and IESG review. I'd like to the working group to quickly ratify (or not) the changes that have been made and the current text.
> >> 
> >>    ftp://ftpeng.cisco.com/fred/v6ops/draft-ietf-v6ops-cpe-simple-security-11-15.html
> >>    http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-15.txt
> >>    http://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-simple-security
> >> 
> >> If you have any comments, please make them by the weekend. Silence will be presumed to be consent.
> >> 
> >> Begin forwarded message:
> >> 
> >>> From: [e-mail]
> >>> Date: October 12, 2010 11:00:01 AM PDT
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: [v6ops] I-D Action:draft-ietf-v6ops-cpe-simple-security-15.txt
> >>> 
> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >>> This draft is a work item of the IPv6 Operations Working Group of the IETF.
> >>> 
> >>> 
> >>> 	Title           : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
> >>> 	Author(s)       : J. Woodyatt
> >>> 	Filename        : draft-ietf-v6ops-cpe-simple-security-15.txt
> >>> 	Pages           : 35
> >>> 	Date            : 2010-10-12
> >>> 
> >>> This document identifies a set of recommendations for the makers of
> >>> devices describing how to provide for "simple security" capabilities
> >>> at the perimeter of local-area IPv6 networks in Internet-enabled
> >>> homes and small offices.
> >>> 
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-15.txt
> >>> 
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>> 
> >>> Below is the data which will enable a MIME compliant mail reader
> >>> implementation to automatically retrieve the ASCII version of the
> >>> Internet-Draft.
>