Title: Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things --- Author: Robert Bisewski #405 - 860 Homer Street Vancouver, British Columbia, Canada - V6B 2W5 robertb@linuxmagic.com --- Abstract: As a consequence of recent advances in computational power, much of the world relies heavily on electronic devices designed improve our efficiency during working hours and expand the quality of our life in other areas; otherwise known as the Internet of Things. However, these device are expected to retain a level of utility for an extended number of years, possibly 10 or more. As a result, hardware manufacturers are attempting to develop methodologies to keep these devices in a functional and secure state for the entirety of their life cycle. This page explores a number of proposed techniques that attempt to manage one of the core aspects of this, software updates, from a popular example of an existing technique, as well as presenting an idea of utilizing CoAP to allow for reduced straining on existing networks. --- Categories and Subject Descriptors: D.2.9 [Software Engineering]: Management - software process models, life cycle, maintenance. --- General Terms: Management, software maintenance, life cycle. --- Keywords: CoAP, CoRE, Software Updates, Software Development, Software Development Maintenance, Agile Software Development, Software Process, the Internet of Things. --- 1) Introduction: From the management of large networked systems [1] to the developmental ecosystems used by IT employees [2] to a electronicly augmented defense turrent [3][4], a concept that is on the verge of re-emerging is the idea of a maintenace life cycle. How this differs from past attempts of planning out software life cycles with the internet in mind, is a subject of some interest to the industry. Notably, how flaws in current development models might accidentally result in wide-ranging exploits in the software of existing consumer and business devices. In order to deal with possibilities of migitating this, the goals of this paper are twofold; first an exploration of a commonly used technique to allow devices to receive updates via a distributed repository model, as well as the purposal of a theoretical device-to-device interactive model of updates via the Constrained Application Protocal, otherwise known as CoAP. --- 2) Common Technique - Distributed Repository Model: One of the more popular methods for the publishing of updates, is the idea of a utilizing a wide network of remote proxies that could be used as a sort of distributed connective interface to a repository containing the latest version of a given piece of software for a device. This repository would, of course, be certificate-signed and verified to prevent forging from potentially malicious agents, such hackers harnessing cloud-based botnets. One such variant is mentioned in a patent filed by Felipe Albertao [5] on behalf of Google, in which he outline the basic overview of the technique, which can be summarized as follows: Client devices utilize the pre-existing networks at their disposal from their intranet to then remotely connect to a distribution services machine (e.g. an online server that stores the latest version of a piece of software). The distribution services machine, in turn, stays up-to-date by retrieving data from the original author of the software in question (not unlike the concept of a mirror). Thus a complete retrieval ecosystem is put in place in order to accommodate the expectation that end users are able to receive updates from the known repositories, while at the same time, the repositories are retained and routinely sent the latest version of the software needed by devices that constitute the Internet of Things. For a brief overview of how a retrieval ecosystem could work, please refer to Figures 1, 2, and 3 on the patent itself [5]. Regarding the devices themselves, they are naturally required to have a process for dealing with any files that are received. First, the client will need to determine the designated update policy and check if the intention of the designers to continue to provide updates as per the so-called "subscription" model. If the device detects an updated package that is currently "selected" it will received the updated package as per the update policy and then check if the package can be validated. If it cannot be validated, then the process ends. Otherwise it can be validated, and so will then proceed to check if the system accepts the change as functional. If an error occurs that this stage, the system will rollback the bad changes to the previous version stored on its system. If instead the package was a success, then the software of our device is now up to date. A breakdown of how such a subscription model could be handled is detailed in flowchart of Figure 6 in the patent itself [5]. With both of these systems in place, a repository is able to stay up to date, while the client device is able to be certain that an update is both secure and will not accidently cause the device to malfunction. In the event of a potentially bad update, the ability to rollback any hazardous changes is of utmost importance. So the goal of the "distributed repository" method is to address this concern as per the above process. --- 3) Suggested Theoretical Idea - Device-to-Device Interactive Model: While the centralized mirror-like model of updating devices in the Internet of Things remain the mainstay of established companies, alternative implementations for handling software updates on smaller devices are growing in popularity due to the reduce strain on system resources that often plagues any IT department. The device-to-device model attempts to resolve this strain by depending less on event triggers or lookups to large centralized reposities, and instead rely from other similar devices inquiring about their current state. A famous example is the MAGIC Broker system [6], but other decentralized models exist, although admittedly they are rare in that most providers wish to relay from a more centralized, and thus earlier to control, location. In the absence of a good and reliable decentralized system, other developers attempt to fill the gap in interesting ways. One of the more popular recent attempts is to focus on node-to-node communication. This page will explore CoAP [7], which uses UDP packets for the purpose of implementing the CoRE standard (Constrained RESTful Environments), and how in theory it could be used to reduce possible network strain. More information about the standard can be found here[8]. CoRE is a framework for handling the input from multiple types of sensors, or managing simple devices, such as nodes or consumer devices that need occasional changes or adjustments or need to return output to some other device in the network topology. For specific details of a basic HTTP mapping for CoAP, refer to RFC 7252 [9]. By inheritantly incorporating machine-to-machine and multicasting, much of the overhead of using large HTTP requests is eliminated. As a result, the strain placed on the Internet and existing protocols can be overcome; this assumes the next generation of industry manufacturers will be able to integrate support for this protocol into their future devices. In theory, CoAP could be used to allow connected nodes to check and verify with each other. Developers have currently created a number of implementations in the prevalent programming languages: examples include aiocoap[10], cantcoap[11], and node-coap[12]. What this author proposes is that future implementations of CoAP could be designed to offer machine-to-machine updating within an intranet or possibly even a local subnet via HTTP. CoAP currently allows for easy multicast of device setting changes, and can be easily translated to HTTP, which means one could potentially send updated files via such requests as well. Also worth mentioning, the end points of CoAP could be used as both server and client side, unlike HTTP, and so could be used for collections of smaller interspersed networks[13]. As opposed to relying on direct communication with repository servers, sending CoAP packets could potentially allow for "waves" of devices that would verify, download, and then update themselves. All of this could be conducted independently of the original repository. An example of this could be as follows: [Device] [Device] [Device] \ | / \ | / LAN / WAN \ | / \/ \/ \/ [Device] [Device] [Device] /\ /\ /\ \ | / ----------------------------------------------------------------------------- \ | / Internet \ | / \ | / [Originating Update Server] As a default fallback mechanism, the devices would attempt to retrieve from the originating update server. However, if the individual devices were in contact with each other during their attempt to gather the update, they could grab the updated packages from their immediate peer without a need for contacting the main server. At this time, using CoAP in this manner is purely theoretical, but the possibility of utilizing given updates from nearby peers in order to save bandwidth could help reduce strain to existing Internet architecture. A study done with regards to mobility network management[14] suggests that it is easily possible to extend CoAP for more specialized purposes. Again the goal of this paper is not to devise an implementation, but merely to note that the author believes this, or something like this, is the future of system updates for devices that comprise the Internet of Things. --- 4) Conclusion: The use and development of the internet means that the our increasingly connected will likely demand a great deal of maintenance in order to remain functional at a level that end users are accustomed to. This will mean that both centralized and decentralized techniques will be needed to keep the growth of the Internet on its current pace. Software developers are currently weighing the benefits and tradeoffs of utilizing existing protocols. It is expected that over time a certain method or combinations of methods will emerge as the ideal system for handling this constraints of the modern Internet of Things, even if only for specific type of device and reliability requirement. As stated earlier, the concept of a distributed repository could fit very well with the development cycle of device with a device that is being constantly interacted with on the side of the end user. One such system could be the the operating system of a mobile consumer product; a Android or iOS tablet or phone is expected to receive updates in a manner that is electronically authorized on a secure level and will continue to function even if a number of the updated packages are broken and a rollback becomes required. The technique of device-to-device maintenance via constrained protocols like CoAP could be of assistance to smaller devices, such as sensors, video cameras, set-top boxes, fridges, or other smart home devices. Possibly with some research, this technique could be extended to mobile devices with small size requirements. Alternately, it could be utilized to allow developers to offer daily updates of complex software, instead of larger whole package downloads at given intervals. This might be a way to reduce the strain on existing Internet channels, as well as providing more reliable updates as fewer files of a system are changed at any given time. On another note, existing devices are likely cause some strain and be potentially serious security risks[15], so perhaps there is a need to also address this aspect of the Internet of Things in the interm until a good decentralized technique can be developed. However, that is likely a complex and separate topic unto itself, but security risk do further complicate the situation of Internet strain. Ergo, it is the opinion of this author that with the existing strain of networks of the Internet and the devices using it[16] means that decentralized or simplified or concurrent methods, such as the possible extension of CoAP, will be the prefered style of delivering software updates to future smart devices in the Internet of Things. --- 5) Acknowledgements: I would personally like to thank all of the staff at LinuxMagic for assistence in this endeavour; their knowledge of the inner workings of systems helped make study into this field possible, especially with regards to higher level concepts in the software industry. A notable mention is Shaun Johnson, who explained to me value of patience and cautionary measures when dealing with complex networking systems. As well, it is only fair to give a mention of my mentor, Dr. Pradeep K. Atrey, professor at the University of Albany, who demostrated to me critical thinking techniques for exploring the future of the field of Computer Science. I thank him for the faith he has placed in me in the past, it will not be forgotten. --- 6) References: [1] Z. Qin, G. Denker, C. Giannelli, P. Bellavista and N. Venkatasubramanian, "A Software Defined Networking architecture for the Internet-of-Things," 2014 IEEE Network Operations and Management Symposium (NOMS), Krakow, 2014, pp. 1-9. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6838365 &isnumber=6838210 [2] A. Fuggetta, E. Di Nitto. "Software Process," ACM - FOSE 2014, Proceedings of the on Future of Software Engineering, pp. 1-12. http://dl.acm.org/citation.cfm?id=2593883 [3] R. Bisewski and P. K. Atrey, "Toward a Remote-Controlled Weapon-Equipped Camera Surveillance System," 2011 IEEE 23rd International Conference on Tools with Artificial Intelligence, Boca Raton, FL, 2011, pp. 1087-1092. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6103476 &isnumber=6103298 [4] R. Bisewski and P. K. Atrey, "Modeling, Simulation and Analysis of a Weaponry-equipped Camera Surveillance System," Journal of Modelling & Simulation of Systems. 2012, Vol. 3 Issue 1, p4-13. 10p. [5] F. Albertao, "System and method for distributing software updates to a network appliance," US Patent - US 10/725,617 - https://www.google.com/patents/US20050120106 [6] M. Blackstock, N. Kaviani, R. Lea and A. Friday, "MAGIC Broker 2: An open and extensible platform for the Internet of Things," Internet of Things (IOT), 2010, Tokyo, 2010, pp. 1-8. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5678443&isnumber=5677827 [7] Bormann, Carsten; Castellani, Angelo P; Shelby, Zach. "CoAP: An Application Protocol for Billions of Tiny Internet Nodes," IEEE Internet Computing 16.2 (Mar 2012): 62-67. [8] A. Melnikov, B. Leiba, "Constrained RESTful Environments," April 2016. https://datatracker.ietf.org/doc/charter-ietf-core/ [9] Z. Shelby, ARM, K. Hartke, C. Bormann, Universitaet Bremen TZI, "The Constrained Application Protocol (CoAP)," June 2014. RFC 7252 via the IETF. https://tools.ietf.org/html/rfc7252 [10] M. Wasilak, C. Amsuss, "The Python CoAP library," Nov 2015. https://pypi.python.org/pypi/aiocoap [11] A. Mills (staropram), Noisy Atom Limited, UK. October 2015. https://github.com/staropram/cantcoap [12] M. Collina (mcollina). "CoAP - Node.js Style," May 2016. https://github.com/mcollina/node-coap [13] Alessandro, L.; Pol, M.; Anna, C. "TinyCoAP: A novel constrained application protocol (CoAP) implementation for embededding restful web services in wireless sensor networks based on TinyOS," J. Sens. Actuator Network 2013, 2, 288–315. http://www.mdpi.com/2224-2708/2/2/288/htm [14] Seung-Man Chun, Hyun-Su Kim and Jong-Tae Park. "CoAP-Based Mobility Management for the Internet of Things," School of Electronics Engineering, College of IT Engineering, Kyungpook National University, Daegu 702-701, Korea. http://www.mdpi.com/1424-8220/15/7/16060/htm [15] B. Schneier, "There's No Real Difference Between Online Espionage and an Online Attack", March 2014. https://www.schneier.com/essays/archives/2014/03/theres_no_real_diffe.html [16] B. Schneier, "The Internet of Things Is Wildly Insecure And Often Unpatchable", January 2014. https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html