Position Paper for the IoT Software Update Workshop Avoiding the Obsolete-Thing Event Horizon Robert Sparks Ben Campbell 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