Re: Local Cloud Node

On Tue, Oct 14, 2014 at 8:26 PM, Stephen Farrell 
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
wrote:



On 14/10/14 20:57, Jim Gettys wrote:

On Tue, Oct 7, 2014 at 2:38 PM, Phillip Hallam-Baker <

phill(_at_)hallambaker(_dot_)com>

wrote:

On Tue, Oct 7, 2014 at 2:11 PM, James Woodyatt 
<jhw(_at_)nestlabs(_dot_)com>

wrote:

On Fri, Oct 3, 2014 at 11:39 AM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> 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,

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=view.php&a&id=69&type=2


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

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.

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


 â€‹