Network Working Group M. Stenberg Internet-Draft Intended status: Experimental July 3, 2015 Expires: January 4, 2016 Simple Home Status Protocol draft-stenberg-shsp-00 Abstract This document describes yet another DNCP-based protocol, which uses HNCP-style transport, yet intentionally is incompatible with it so that TLVs of SHSP and HNCP can be handled using same transport channel and de/encoders, but individual implementations of the different protocols can ignore each other unless they support both protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Stenberg Expires January 4, 2016 [Page 1] Internet-Draft Simple Home Status Protocol July 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements language . . . . . . . . . . . . . . . . . . . . 2 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Python Agents . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Sensor Data . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 4 7.1. SHSP Version TLV . . . . . . . . . . . . . . . . . . . . 4 7.2. SHSP Key-Value State TLV . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Normative references . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 5 Appendix B. Draft source . . . . . . . . . . . . . . . . . . . . 5 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In spirit of House Arkko Toaster/Laundry/et al, House Stenberg also has needs, although they are mostly related to various sensors, control of lights and various appliances. This leads to a a number of devices that need to discover each other, and share state and code (ideally) without central authorities, in fault tolerant fashion. And obviously it is also nice to have a log of what has occurred, and maintain software state in a distributed fashion. There are also some security needs; control of appliances can be a serious hazard if security is not addressed appropriately. SHSP is an attempt to produce a solution to address these needs. TBD: The long form of the acronym is actually misleading, as it is more about independent agents rampaging in home network, sharing state as they go. Figure a better name? 2. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Stenberg Expires January 4, 2016 [Page 2] Internet-Draft Simple Home Status Protocol July 2015 3. DNCP Profile The core of how TLVs are synchronized in SHSP is DNCP [I-D.ietf-homenet-dncp]; due to laziness, DNCP profile of HNCP [I-D.ietf-homenet-hncp] is used as is. Despite the reuse of the transport and DNCP core logic, NONE of the HNCP TLVs are part of SHSP. Only difference from HNCP transport is the security methods; SHSP MUST NOT be used in insecure mode. TBD: This may change to 'lite' version, with it's own non-TLS/DTLS transport if some small devices will not live with DTLS footprint as House Stenberg can deal with simple PSKs + sha256 authentication or something, confidentiality is not a requirement here. 4. Overview At it's core, SHSP provides a distributed key-value store, with each node having consistent view of the whole database. Essentially, the database provides view of ((int) node identifier, (string) key, (json-encodable) value, (UTC second)last changed) pairs for any participant interested in viewing it. Based on the key-value store, SHSP protocol implementations can e.g. maintain a shared set of Python based agents as described in Section 5, or do more or less any other arbitrary thing they care about, within limits; as HNCP transport is reused, the total amount of node data published by a node SHOULD NOT exceed 4000 bytes, and MUST NOT (obviously) exceed ~64k limit set by UDP. 5. Python Agents Within SHSP key-value store, there are some specific keys that are reserved for specific things. One of them are Python-based agents, which compromise of a fully self-contained Python set of modules that can be run as a daemon (and also access SHSP state): o system-information: JSON dictionary with human readable content about the node. o power: An integer value which roughly expresses the computation power of the device. It is used as tie-breaker if only single instance of an agent is desired. o python-agent: JSON dictionary containing name, url and hash keys, which describe the logical name (which includes version) url where Stenberg Expires January 4, 2016 [Page 3] Internet-Draft Simple Home Status Protocol July 2015 the package can be found, and finally hash used to verify the download. o run-python-agent: JSON dictionary containing: * name: specifies a name of the python-agent to be run * node-specification: a dictionary which specifies which nodes should run the agent. A node MUST run an instance of the agent if and only if the intersection of node-specification and published system-information equals node-specification. * (optional) copies: number of copies to run at most; if more are available than required, 'power' (and then node identifier) are used as tie breakers; greater power wins, and then greater node identifier. If a node determines it is not within the top- copies of nodes that match, it MUST NOT run the agent. 6. Sensor Data TBD: Describe how sensors publish their data (format is still in flux) 7. Type-Length-Value Objects SHSP defines following TLVs for it's own use. 7.1. SHSP Version TLV TBD: Ascii art o T=100 o V=reserved for now; MUST be empty when sent, MUST accept anything This TLV is used to identify other speakers of SHSP that talk the version of the protocol that is compatible with this specification. 7.2. SHSP Key-Value State TLV TBD: Ascii art o T=101 o V= JSON-encoded string, containing a dictionary with: * timestamp: when was the value most recently changed; number, expressed in seconds, UTC since UNIX epoch Stenberg Expires January 4, 2016 [Page 4] Internet-Draft Simple Home Status Protocol July 2015 * key: name of the key * value: the value of the key (any acceptable Json) TBD: Encode using non-JSON? 8. Security Considerations As SHSP can only be used with DTLS-secured transport, same caveats apply. Even then, care should be taken with e.g. management of the PSKs as insecure access to devices that control light and power is a bad idea. 9. IANA Considerations This document has no actions for IANA. TBD: Steal chunk of HNCP option space for SHSP 10. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-homenet-dncp] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", draft-ietf-homenet-dncp-06 (work in progress), June 2015. [I-D.ietf-homenet-hncp] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", draft-ietf-homenet-hncp-06 (work in progress), June 2015. Appendix A. Changelog First version! Appendix B. Draft source As usual, this draft is available at https://github.com/fingon/ietf- drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it! Stenberg Expires January 4, 2016 [Page 5] Internet-Draft Simple Home Status Protocol July 2015 Appendix C. Acknowledgements None yet, want to be the first? Author's Address Markus Stenberg Helsinki 00930 Finland Email: markus.stenberg@iki.fi Stenberg Expires January 4, 2016 [Page 6]