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

[Mark Smith <[e-mail]>]

Hi Ron,


On Fri, 15 Oct 2010 14:56:45 -0400
Ronald Bonica <[e-mail]> wrote:

> Folks,
> 
> I think that the business model is important, here. 
> 
> Assume that I have purchased an "managed service" from my friendly, local ISP. They provide IPv6 connectivity and drop off a router in my kitchen. I plug my computer into the router and never think about it again. If the ISP discovers a bug in the router software, they update it automatically and I am none the wiser. (This is the model that Jari suggests. It is also my ISP's service model.)
> 

The fundamental problem is that this draft is aimed at vendors. With
this clause the vendor chooses when and where to provide firmware
updates to the CPE users. 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. They may not
even be aware of a new firmware release until they get a flood of
support calls about the Internet breaking.

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. Of course, that will only be successful if all CPE vendors
comply with this "ISP controlled" mechanism. That'll also create an
additonal burden on the ISPs because they'll end up being responsible
for software maintenance for their customer's CPE, even in markets
where customers can purchase CPE independently of ISPs.

Think about applying this model to other devices and I hope you'll see
the fundamental problem -

o  would you be happy that your Internet attached TV's firmware is
automatically updated and installed when the vendor makes firmware
available, right in the middle of a movie?

o  would you be happy that your (eventual) Internet attached ECU's
firmware is automatically updated and installed when the car vendor
makes firmware available, right at the moment when you're travelling at
100Kph/60Mph?

o  would you be happy that your Internet attached plane's firmware is
automatically updated and installed when the plane vendor makes
firmware available, right at the moment you're a passenger in it at it,
and it is in the middle of taking off?

In each of these cases, the operator of the device has to be in control
of when these firmware upgrades occur as they can make the best
operational choice as to when they should occur. Device vendors
usually aren't also operators. For ISP managed CPE, the ISP is
the operator. For privately purchased CPE, the customer has chosen to
take on the responsibility of being the device's operator and is
therefore responsible for it's maintenance - if they don't want to be an
operator, they need to be prepared to engage somebody else to
perform that function. 

I certainly understand the issue of CPE firmware not being upgraded
regularly. However I think that may be more of a human-computer
interface issue. It isn't easy enough for non-technical people to do -
methods such as a flashing LED, persistent beeper and a upgrade
firmware button might be far more successful. But automated updates that
are distributed and installed without notice or control by ISPs or the
end-CPE owners won't solve the problem without causing possibly bigger
ones.

Regards,
Mark.

> Now, assume that I purchase an "unmanaged service". The ISP provides IPv6 connectivity and I go to Crazy Eddy's Electronics World to purchase an Acme-100 router, running ACME-OS Version 1.1. A few months later, the Acme corporation discovers a bug in their implementation of feature X. So they release ACME-OS Version 1.2. While version 1.2 corrects the bug in feature X, it introduces another bug in feature Y.
> 
> In this case, the user knows best whether he wants to upgrade to version 1.2. Users who rely on feature X will want to upgrade, while users who do not rely on feature X will not be so motivated. In this case, the model that Mark suggests makes most sense.
> 
> Acme corporation wants to sell their gear into both managed and unmanaged environments. So, we need to find some middle ground. I would suggest a configuration switch between the two modes proposed above. Since the vast majority of residential users have no idea what their routers are doing, I would suggest Jari's mode as default.
> 
>                                                                      Ron
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Joel Jaeggli
> > Sent: Thursday, October 14, 2010 10:35 PM
> > To: Fred Baker
> > Cc: IPv6 Operations; [e-mail]
> > Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-
> > security-15.txt
> > 
> > On 10/14/10 1:09 PM, Fred Baker wrote:
> > >
> > > On Oct 14, 2010, at 12:46 PM, james woodyatt wrote:
> > >
> > >> It seems like Mr. Smith and Mr. Arkko are in disagreement about
> > >> whether software updates should be downloaded and applied
> > >> automatically, and I don't know how to proceed from here.
> > >
> > > Jari, being on the IESG, is copied in this. I would suggest that he,
> > > Mark, and Barbara argue their relative cases. At the end of the day,
> > > the reason that I asked for a final discussion is that there have
> > > been several changes, and the document has to satisfy not only it's
> > > last reviewer, but the operational community that is recommending
> > > it.
> > >
> > > the status as I see it is:
> > >
> > > - Jari wants the patches applied automatically, which assures patch
> > > updates but removes a level of control from the owner/operator of the
> > > device
> > >
> > > - Mark wants the patches pushed out but applied with the
> > > owner/operator's consent
> > >
> > > - Barbara wants the owner/operator to have an interface that can
> > > apply a patch, but leave anything else undefined; this basically
> > > preserves the status quo, which means that residential gateways are
> > > likely to generally *not* track patches and as a result have security
> > > vulnerabilities, which is also the status quo.
> > >
> > > A middle ground, perhaps, would be to recommend that the manufacturer
> > > provide an option that the user can select; the present language's
> > > "by default" suggests this as well. The options would be for the
> > > device to periodically access a manufacturer web site and download
> > > updated firmware or for the manufacturer to somehow (blast email?)
> > > advise the registered owner to do so at their convenience. The issue
> > > for this draft would be "what is the default", as that will be the
> > > most common actual behavior.
> > 
> > This seems a lot alike an implementation detail, if a device does not
> > update itself automatically then the acceptance of updates by end users
> > is going to be terribly low, if it does, they might approach 100%. I
> > can
> > observe in another business that voluntary software updates on mobile
> > phones (speaking my own employer) have a rather low uptake rate (like
> > under 10%) ota updates for carrier supported devices on the the other
> > hand may approach 100%.
> > 
> > so if you actually want the devices to be up-datable in order to
> > address
> > problems in the field they really do need to do so autonomously, there
> > no way around that.
> > 
> > Still for a device procured by a consumer it should be between them and
> > their vendor as to whether this happens.
> > 
> > For the record I think the text for rec-13 is sufficiently strong that
> > people with a good reason to do so will ignore it and as a general case
> > recommendation it is fine.
> > 
> > > _______________________________________________ v6ops mailing list
> > > [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > 
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops