idnits 2.17.1 draft-ding-dinrg-biot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 254 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2018) is 2048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DINRG H. Ding 2 Internet-Draft Z. Jiao 3 Intended status: Informational Chaincomp 4 Expires: March 13, 2019 September 14, 2018 6 Blockchain-based IoT Infrastructure Functional Requirements 7 draft-ding-dinrg-biot-00 9 Abstract 11 This document specifies the functional requirements for a 12 Blockchain-based IoT infrastructure, including the IoT device identity 13 management, service demand and supply matching, support of smart 14 contract, etc. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 13, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction 2 49 2. Blockchain enabled IoT infrastructure requirements 3 50 2.1. Identity Management 3 51 2.2. Service Demand and Supply Matching 4 52 2.3. Decentralized Service Scheduling 4 53 2.3.1. Service Matching Policies 4 54 2.3.2. Consensus Protocols 4 55 2.4. Smart Contract 5 56 3. Different Node Types and Functions 5 57 4. Security Considerations 6 58 5. IANA Considerations 7 59 6. Acknowledgments 7 61 1. Introduction 63 With IoT devices proliferating in smart homes, smart cities, smart 64 industries, smart transport, smart health, etc., these devices often 65 lack security consideration due to constrained resources, hence 66 vulnerable to hacking which may cause serious problems in businesses, 67 environment and day-to-day lives. Besides, vendor specific IoT 68 platforms hinder data exchange among devices, create isolated value 69 island and hampers the growth of the ecosystem. The emerging Blockchain 70 technologies, with a decentralized trustless architecture and 71 incentives for sharing, may be able to resolve the trust, security and 72 interoperability challenges for IoT. 74 IoT devices play an important part in businesses growth via digital 75 transformation, while Blockchain technologies can be adopted 76 to manage the identities of those devices as the very beginning to 77 establish trust. Once registered in the immutable decentralized ledger, 78 admission control can be implemented, potential threats can be detected 79 and mitigated. 81 Autonomous coordination among devices via transactions and smart 82 contracts incentivize data and resource exchange across different 83 vendor specific IoT devices, thus enables Device-to-Device economy. 85 2. Blockchain enabled IoT infrastructure requirements 87 The Blockchain-based IoT infrastructure should support identity 88 management, service demand and supply matching, smart contract, etc. in 89 a proper way to realize the value of Internet of Things. A possible 90 large scale Blockchain-based IoT infrastructure can be a hybrid of 91 permission-less chain and permissioned chain, and applications can 92 choose different deployment that suits its business requirements. 94 2.1. Identity Management 95 The life span of an IoT device can be several years to decades. The 96 infrastructure should support identity management which is able able to 97 register the device on the immutable ledger and authenticate its 98 identity when necessary during its lifetime. 100 Once a device is produced, the manufacturer can register an 101 identifiable ID along with its manufacturing information, such as 102 warranty, to a permission-less chain so that it can provide maintenance 103 to customers after products are sold. Besides, the registration on 104 permission-less public chain allows every one accessIf necessary, such 105 identity information can also be used in shipping and inventory 106 management at retailor sites. 108 After the device is purchased, the user obtains its full ownership 109 including the data it collects and generates. The device should be able 110 to generate a pair of public key and private key. The public key is 111 used to identify a specific device among others, while the private key 112 is used as proof of identity for future validation on real-time 113 messaging and transaction. 115 The owner can register the device on a permissioned chain in order to 116 perform admission control, so that only authorized devices and 117 personnel can interact with the device and access its data. After the 118 registration is completed, the device is able to submit transactions 119 signed by its private key and the network of peer devices can verify 120 them, so the history of all data/resource exchange will be recorded and 121 kept safe for future reference and audition. 123 2.2. Service Demand and Supply Matching 124 To fully activate the capabilities of IoT ecosystem, the devices should 125 have a way to demand and supply services to each other autonomously. 127 Each device will publish its specific functionalities to the 128 peer-to-peer network, and other devices in the network can subscribe to 129 the peers of interest by reading the published functionalities. As the 130 subscription content grows, the possibility of one device finding a 131 matching demand and supply service pair would be higher. 133 When a matching pair is found, the two devices will become two parties 134 in a smart contract, trading service with associated fees without the 135 need of a third party. The system can implement a number of service 136 scheduling policies to optimize the matching process. 138 2.3 Decentralized Service Scheduling 139 There can be different service scheduling policies in the autonomous 140 coordination among IoT devices, for example, service matching policies, 141 and the consensus protocols. 143 2.3.1 Service Matching Policies 144 As introduced in Section 2.2, peer nodes should coordinate autonomously 145 in service exchange. Some service matching policies may be more 146 suitable than others in different scenarios meaning that a certain 147 policy would make a match sooner or more effective. 149 For example, a device adopting the latest publish first policy will 150 choose the latest published services on Blockchain because the service 151 will have higher availability given the dynamical change in 152 Device-to-Device networks. 154 2.3.2 Consensus Protocols 155 Given the heterogenous nature of IoT networks, each sub-network may 156 employ different consensus protocols within its Autonomous Domain (AD). 157 The Blockchain-based IoT infrastructure should support coordination 158 among different consensus protocols so that devices across ADs can 159 exchange data and resources. 161 2.4. Smart Contract 162 Smart contract is an agreement between two or more parties that is 163 defined and executed automatically, once certain pre-defined conditions 164 are met. For a Blockchain-based IoT network, smart contract enables 165 more complex device-to-device interaction than transaction. 167 A crucial part in execution of a smart contract is to check and 168 validate whether the pre-defined conditions are met. There can be two 169 sources where such data come from, on-chain and off-chain. On-chain 170 data are stored in the decentralized immutable ledger which can be 171 traced back to once it is packaged in the block. In some cases, the 172 chain is designed to only carry important information under resource 173 constraints, hence leave some information stored off-chain, which can 174 be useful in the decision making process of smart contract. Special 175 mechanism should be implemented to check and validate the correctness 176 and truthfulness of off-chain data while still keep the decentralized 177 nature of blockchain system. 179 Once the condition for transactions are met, associated fees can be 180 transferred from the service demander to the service supplier safely 181 without a trusted third party. A smart contract can call a series of 182 smart contracts, which makes it a powerful tool for automatic value 183 exchange in IoT network. 185 3. Different Node Types and Functions 186 IoT devices have various computing power, storage space and networking 187 capability. It is practically impossible to install a full stack of 188 functions on every node. 190 The devices, given their varied capabilities, can be divided into light 191 node and full node. 193 full node 194 +------------------------+ 195 | smart contract | 196 +------------------------+ 197 | transaction | 198 |submission & validation | 199 +------------------------+ 200 | edge analytics | 201 +------------------------+ 202 light node | Data Storage | 203 +---------------------+------------------------+ 204 | real-time messaging | 205 +----------------------------------------------+ 206 | light wallet | 207 +----------------------------------------------+ 209 A light node often has low memory space, weak computing power and/or 210 unstable connectivity to the network, such as sensors. This type of 211 node only perform minimal message exchange with peer nodes, keeps a 212 wallet with their address/name and a balance. Any heavier tasks, such 213 as transaction validation will be off-loading to trusted full node. The 214 trusted node can be one from the permissioned chain. A light node is a 215 client of the blockchain, but not a blockchain node. 217 A full node will support all the functions a light node has with higher 218 performance, including real-time messaging, transaction, block and file 219 storage, local computing, etc. The full node is a complete blockchain 220 node, which can submit and validate transactions, execute smart 221 contract. It also helps trusted light nodes with heavy tasks when 222 needed. 224 4. Security Considerations 225 The security of a Blockchain-based system relies on its consensus 226 protocol. 228 For IoT, the possibility of being hacked poses security challenges to 229 the system. 231 5. References 232 TBD. 234 Authors' Addresses 235 Hui Ding 236 Chaincomp Technologies Co., Ltd. 237 Shixia New Times, 238 Shenzhen, Guangdong 518034 239 China 241 Email: hui.ding@chaincomp.net 243 Zhenzhen Jiao 244 Chaincomp Technologies Co., Ltd. 245 Shixia New Times, 246 Shenzhen, Guangdong 518034 247 China 249 Email: z.jiao@chaincomp.net