ietf
[Top] [All Lists]

Re: Local Cloud Node

2014-10-15 08:50:41
On 10/15/2014 02:49 PM, Jim Gettys wrote:


On Tue, Oct 14, 2014 at 8:26 PM, Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie <mailto: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 <mailto:phill(_at_)hallambaker(_dot_)com>>
    > wrote:
    >
    >> On Tue, Oct 7, 2014 at 2:11 PM, James Woodyatt
    <jhw(_at_)nestlabs(_dot_)com <mailto:jhw(_at_)nestlabs(_dot_)com>> wrote:
    >>> On Fri, Oct 3, 2014 at 11:39 AM, Phillip Hallam-Baker
    >>> <phill(_at_)hallambaker(_dot_)com 
<mailto: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,
    >> 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=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 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
    >
    >
    >  ​
    >



<Prev in Thread] Current Thread [Next in Thread>