Avoiding the Obsolete-Thing Event Horizon
slides-iotsuws-avoiding-the-obsolete-thing-event-horizon-00

Position Paper for the IoT Software Update Workshop

Avoiding the Obsolete-Thing Event Horizon

Robert Sparks <rjsparks@nostrum.com>
Ben Campbell <ben@nostrum.com>

Abstract:

The design considerations for providing software update capability
to the next generation of IoT Things need to include several edge
cases focusing on endings, particularly end-of-service, end-of-feature,
and end-of-device-support. The mechanisms to invoke at those times
may be significantly different from those used for a service, feature,
or device update. The effect of the Things on the Internet at times
beyond these endings also needs careful consideration.

Discussion:

The need for the ability to update the software on deployed Things is
becoming clear. Very large existing deployments have documented
vulnerabilities, and it has been demonstrated that updating them is
difficult, if not completely infeasible. The Things that are made next
need to be better positioned to be safely modified in the field.

At the same time, secure update mechanisms will, by necessity, limit
who can modify the software in a Thing. Recent history shows that
Thing vendors and service providers tend to lock down device software,
and place both technical and legal barriers to prevent Thing end-users
(nominally the owners) from modifying the Thing software or
configuration.

As the community discusses what tools and structures will best
facilitate this kind of update, it will be important to remember
a set of edge cases, where the answers to questions like "who should
be able to initiate an update" may have different answers than the
normal case of a vendor releasing an updated version of their product.

These edge cases center on endings. What should happen when a company
that provides a Thing goes away? Is that different than when the
company continues to exist, but the Thing has hardware limitations that
make continued support unreasonable? Is it different when it's only a
service that leverages the Things is being decommissioned?

What should happen when a Thing service provider pushes an update that
removes a feature [HUE]? Should a Thing owner that cares about that
feature be able to veto the update? What happens when a Thing owner
decides to stop using one service, and wishes to move to another?

We have already seen deployments abandon the devices in the field,
rendering them non-functional (at least their original intended
function is no longer available). At [Revolv], the founders note that
"As of May 15, 2016, Revolv service will no longer be available. The
Revolv app won't open and the hub won't work".

If this becomes a common pattern, it will be important to consider
what happens to the abandoned devices. Having a service go away
does not necessarily render the device useless to the end user.
A smart bulb, for instance, will still often work as a regular
lightbulb connected to an on/off switch even without connectivity
to whatever Internet services might control it. Such devices are
likely to continue working for years. If they remain connected
to the Internet, the opportunity for compromising any software
exposed to the network steadily increases as those years pass.

Further, a large population of old Things that are not net
quiescent will increase the portion of the traffic on the Internet,
and resulting state in other Internet hosts, that is useless for 
anyone. For example, they might still generate DHCP traffic, 
perhaps maintaining leases, and generate periodic DHCP, STUN,
or HTTP requests. Identifying and managing this "ghost traffic"
is not trivial. (For example, the University of New Hampshire
Interoperability Laboratory hosted a well-known STUN server
from 2009 to 2014. The service has been down, DNS no longer
points to it, and traffic has been dropped at a firewall since 
late 2014, but there are still approximately 200 STUN requests
per second from over 5000 unique addresses appearing at the
firewall for the address previously providing the service.
Contact James Swan at jmswan@iol.unh.edu for additional
information.)

What can be done to prevent a large number of old Things becoming an
attractive working surface for malicious purposes? The European
Commission opinion [EC] referenced by the call for papers for this
workshop recommends "When a device becomes deprecated and is no longer
updated, the device manufacturer should notify the user and make sure
that he is aware that the device will no longer be updated." Is
notification enough? Should the vendor abandoning a Thing deploy a last
software update that removes any open network services on the device
('bricking' it as far as the network is concerned)? Should IoT devices
adopt a common "Update by" policy, becoming net-dead if they are not
updated with a given frequency?

If a Thing has utility beyond the closing of a given service, what
mechanisms should be created to facilitate allowing the Thing to be
updated by a third party? Would these make it easier to transition
Things from a deprecated service to a new service? Perhaps third-party
update services could be created, leveraging concepts similar to those
being discussed in [LURK], allowing a provider to authorize a third
party to distribute a new update (created by the provider, or
potentially created by a new party and vetted by this update service
before distribution).

There are obvious barriers to allowing a Thing to be used beyond the
intent of its original provider. Making Things captive to a given
service is often a crucial aspect of the business model for making
the Thing in the first place. Exposing what would be required
for a third party to update the Thing likely requires sharing IPR
that the provider may not have the ability to release (especially
if they are going or have gone out of existence). Standardized
update mechanisms would make building such an update path more
feasible.

Again, as the mechanics and considerations for updating deployed
Things are discussed, it is important to remember these "ending"
use-cases, and to consider that the mechanics may need to be
substantially different from the standard "new version" update
path.

References:

[HUE] http://www.cnet.com/news/philips-hue-cuts-support-for-third-party-bulbs/

[Revolv] revolv.com

[EC] Article 29 Data Protection Working Party, " Opinion 8/2014 on the
on Recent Developments on the Internet of Things ", September 2014.

[LURK] https://www.ietf.org/proceedings/95/minutes/minutes-95-lurk.html