Re: Local Cloud Node

[Harald Alvestrand <harald@xxxxxxxxxxxxx>]

On 10/15/2014 02:49 PM, Jim Gettys wrote:

On Tue, Oct 14, 2014 at 8:26 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:

On 14/10/14 20:57, Jim Gettys wrote:
> On Tue, Oct 7, 2014 at 2:38 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx>
> wrote:
>
>> On Tue, Oct 7, 2014 at 2:11 PM, James Woodyatt <jhw@xxxxxxxxxxxx> wrote:
>>> On Fri, Oct 3, 2014 at 11:39 AM, Phillip Hallam-Baker
>>> <phill@xxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Yes, I agree with the replies so far, more or less. [...]
>>>
>>>
>>> As general principle, my preference is for networked home devices to
>>> *request* access to its maker's online service, with the owner having the
>>> option to decline and to still have a functional device with the basic
>>> features all working as a normal person would naturally expect.  When I
>>> think about arguments for *demanding* access to Internet service, I can
>>> think of precisely one for which I am forced to admit there are
>> personally
>>> convincing reasons for doing it: emergency firmware update.  Even there,
>> I
>>> still squirm, and I can sympathize with people who disagree.
>>>
>>> Really, if my personal preferences are to rule the day, then everything
>> else
>>> ought to be in the category of "you bought a $DEVICE, and it does
>> $FUNCTION
>>> just fine, but if you let it call it's mother periodically, then it will
>>> also do $OPTION as well, and won't that be nice.  Okay? [y/N]" (FWIW, I'm
>>> reasonably sure my current employers hold a compatible view on this
>> topic,

>>> but— you know— I can't speak for them, of course.)  Enabling more local
>>> autonomy would make me happier, and my hunch is that this may actually
>> be a
>>> minority view in the Internet engineering community, but I'm happy to
>>> represent yo.  For reals.
>>
>> I think the starting point would be for the device to tell my system
>> what it is and what version of firmware it is running.
>>
>> Automatic firmware updates have already become a source of nuisance
>> rather than sanity in the house. When I turn something on I want it to
>> work NOW! NOW! NOW! About one time in ten a given device will turn on
>> and then start downloading stuff for ten minutes.
>>
>> What really irritates is the approach typified by my DVR set top box
>> which is on 24/7 and connected to the net. When an update notification
>> is sent it posts a note on the splash screen then waits for someone to
>> attempt to use it. At that point and only at that point does it begin
>> the mandatory update. There is no option to cancel, the machine just
>> waits until it can inconvenience someone.
>>
>>
>> Right now I have a house with three Internet thermostats and six smoke
>> alarms, all of which have temperature sensors and occupancy sensors.
>> It would seem like a no brainer to connect these up in an intelligent
>> way so that lights get switched off when there is nobody in a room and
>> using the temperature in the rooms that are occupied to set the
>> furnace temperature rather than the ones that are not.
>>
>>
> ​There is a serious issue lurking here: it is *not* safe for devices to be
> without software updates. And it isn't safe to presume the upstream
> manufacturer is being diligent in providing those updates.  And nagging end
> users to do something that they don't understand is also not a solution.
>
> Those of you unaware of the "Honeymoon effect" should read the following
> paper:
>
> http://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action="">
>
> Both heartbleed and shellshock are good examples of this phenomena
> (thankfully, shellshock does not happen to be present in most of these
> devices, but in systems which are upgraded on an ongoing basis.
>
> Worse yet are the "hidden monocultures" we have: binary blobs throughout
> our systems that may make update impossible (on the scale of the lifetime
> of these devices).
>
> See:
> http://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/
>
> The other challenges (security) dwarf bufferbloat.
>
> I believe we need to rethink how we build software for these devices, in a
> pretty fundamental way.

If someone wanted to write an I-D describing a useful thing the IETF
could do in this space, I'd be very happy to see that and to try move
it along however is best done. (When I say "this space" I mean at
least s/w update for devices like sensors of various kinds and
DSL-modem like things.)

I think its possible, but not a slam-dunk, that there is good work
that the IETF could do on that topic.

​Since writable flash must be protected (and cheaply!), and software/firmware still updated in such devices

one area may be to describe such mechanisms, along with the issues of key management

best practices which are far from the minds of most vendors who have never given thought to long lived network systems.

Without such guidance, we'll live in a sea of vulnerability. 

For extra entertainment, consider that SIM cards have an independent OS and writable flash.

Looming larger is the observation that as an industry we don't think about building systems and software with long life times; that goes well beyond the IETF.

As to I-D's, I have to locate appropriate co-authors before I can commit to anything.

                                     - Jim

S.

>
> - Jim
>
>
>  ​
>