idnits 2.17.1 draft-baba-iot-interconnection-04.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2020) is 1325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Pattern 1' on line 334 -- Looks like a reference, but probably isn't: 'Pattern 2' on line 357 -- Looks like a reference, but probably isn't: 'Pattern 3' on line 364 -- Looks like a reference, but probably isn't: 'Pattern 4' on line 330 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force H. Baba 3 Internet-Draft The University of Tokyo 4 Intended status: Informational I. Miyake 5 Expires: March 13, 2021 IoT Square Inc. 6 J. Matsumura 7 BizMobile Inc. 8 Y. Ishida 9 Japan Network Enabler Corporation 10 September 9, 2020 12 Study Report on a Framework for Cloud Inter-connection toward the 13 Realization of IoT 14 draft-baba-iot-interconnection-04 16 Abstract 18 This paper describes issues for solutions through cloud inter- 19 connection to structural problems, which are called as "silo effects" 20 found in cloud-connected electric home appliances, housing equipment 21 and sensors in the face of increasingly accelerated connection of 22 them. Specifically, this paper explains an inter-connection 23 agreement considered to be required for enhancement of cloud inter- 24 connection, what performance guarantee as well as IoT supervising and 25 management should be, necessity of inter-connection HUB which is able 26 to provide inter-connection amongst the preponderance of private 27 cloud groups, and the necessity of a mechanism to avoid threats that 28 cause danger to users when we make the inter-connection. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 13, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Draft Framework for Cloud Inter-connection . . . . . . . . . 3 66 3. Interconnection Agreement . . . . . . . . . . . . . . . . . . 4 67 4. IoT Device Operation Confirmation and Monitoring . . . . . . 6 68 5. Interconnection HUB . . . . . . . . . . . . . . . . . . . . . 7 69 6. Flexibility of this method . . . . . . . . . . . . . . . . . 9 70 7. Mechanisms to avoid threats when we make the inter-connection 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 75 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 To date, based on the results of interviews with "Things" companies, 81 the authors of this paper, the Autors, issued a Problem Statement on 82 IoT [1], and reported on an experiment of WebAPI [2]. With further 83 interviewing and experiments, various requirements specification on a 84 base for securing cloud inter-connection in the anticipated IoT 85 society become clearer. 87 Currently, the use of various connected devices, hereinafter "IoT 88 Devices" is largely expected to become a using scene of IoT, and such 89 IoT Device manufacturers operates their private cloud groups, the 90 "Cloud", where IoT Devices are connected one after another. It 91 depends on the manufactures whether API of one cloud is open to a 92 third party or whether the cloud remains closed just for itself just 93 like a "silo". However, it is expected that API be open by 94 manufacturers in charge to third parties in the near future and a 95 large variety of values shall be created through cloud inter- 96 connection of IoT Devices that are connected to the other cloud 97 groups with a similar structure. Several cloud inter-connection 98 services, enabling one cloud with aforementioned IoT Devices to 99 connect with another cloud with IoT Devices, have already been 100 provided. 102 Thus, by combining cloud-connected IoT Devices, or "connected 103 Things", just like toy blocks being built freely through cloud inter- 104 connection, the era for creating a variety of benefits for users 105 seems to approach us. 107 As far as users select and handle connected Things on their own 108 response, there are not any significant issues. However, those whom 109 you cannot expect IT literacy like elder people should be able to get 110 access to benefits from IoT. If we stand on such an assumption, 111 there seem to be many open issues. 113 Furthermore, there is a concern of threats that cause danger to the 114 user's body, property, etc. when we make the inter-connection, and 115 the mechanism to avoid these threats are necessary. 117 The Authors conducted interviews with 9 market players including IoT 118 service providers and those who were preparing to provide IoT 119 services and undertook research and summarized issues that those 120 players felt with regard to cloud inter-connection. In parallel with 121 other researching experience, we discussed on what framework would be 122 required for doing IoT service provider businesses at smart houses. 123 In addition, we organized the basic concept of the mechanism for 124 avoiding threats when we make the inter-connection. This paper 125 outlines the findings from such discussions. 127 2. Draft Framework for Cloud Inter-connection 129 Not assuming the style where users enjoy combination of the use of 130 IoT Devices like DIY but assuming the one where so called service 131 providers offer IoT services to users on a "do-it-for-me (DIFM)" 132 manner, issues different from DIY style become more patent in the 133 light of responsibility for customers and business continuity. Those 134 issues are well diversified but may be summarized into three core 135 categories as follows: 137 (1) Inter-connection Agreement 139 Commercial cloud inter-connection requires some kind of contracts 140 without any doubt. Such contracting procedures are very common in 141 the Internet market. However, manufacturers of home appliances 142 and housing equipment have no experience and they feel worried. 144 (2) Operation Confirmation and Operation Monitoring of IoT Devices 146 Once being cloud-connected, it is necessary that not products of 147 one manufacture but also ones made by others are operated with 148 commands sent out of one's cloud server. At the development stage 149 of services and during operation of the services, the operation 150 monitoring of one's IoT Devices being connected with other's cloud 151 group just with commands of one's. 153 (3) Inter-connection Infrastructure 155 Currently a large number of manufacturers proceed with activities 156 in getting appliances and equipment that used to operate on a 157 standalone basis connected to the Internet. Those pieces of 158 appliances and equipment are independent of each other, namely 159 "silos". Therefore, in case of connecting all those pieces with 160 one another, the number of ways to connect needs to be N(N-1)/2. 161 To do this, much resources shall be required. As was seen in 162 telephone and the Internet, if HUBs connecting with one another 163 are put in place, this issue would be less cumbersome to some 164 extent. 166 The framework, comprising of above three points, shall be explained 167 in details in the following chapter. 169 3. Interconnection Agreement 171 In the era of IoT, it is desirable to facilitate contracting between 172 businesses smoothly by preparing a boilerplate format for an 173 interconnection agreement in advance. As described in the previous 174 chapter, because of the lack of experience in home appliances and 175 housing equipment manufacturers, needless to say, any guidelines or 176 formats would give great comfort to them. The benefits from an 177 interconnection agreement are to define responsibility of each 178 contracting party and clarify consent of the parties. 180 For example, manufacturers of gas cookers have been working on 181 operational linkage between a gas cooker and air conditioner in order 182 to harness the increase of room temperature. Possibly a universal 183 remote controller may be linked with a gas cooker and then the user 184 can of course operate an air conditioner with the gas cooker 185 controller. However, unless there is consent from the manufacturer 186 of the air conditioner on this link operation, the gas cooker 187 manufacturer seems to hesitate to pursue this due to his feeling that 188 this is not a fair business behavior. 190 Following precedents in the Internet, the contents of the 191 interconnection agreement include demarcation of responsibility, 192 procedures in operation and maintenance, cost allocation, technical 193 specifications, and general prohibitions. In addition to such 194 contents, however, the interconnection agreement becomes 195 significantly valuable by proving that participating parties formally 196 agree upon commercial terms of cloud inter-connection. 198 Of course, the agreement stipulates terms on malfunctioning of IoT 199 Devices. For example, there is a structure where an energy 200 management application located in a cloud group of lighting equipment 201 of Manufacturer A gives a command to a cloud group of air 202 conditioning equipment of Manufacturer B. By chance, one air 203 conditioner starts malfunctioning and the user may call a customer 204 service of Manufacturer A that provides DIFM energy management 205 services to the user. In this case, problems are 1) how the fault 206 can be isolated and 2) how this user's report can be transferred to 207 Manufacturer B if the fault is identified to come from the other 208 service provider, namely Manufacturer B. 210 In case of one manufacture Authors interviewed with, regarding 1) 211 above, the provider asks the user confirm the lighting operation by 212 its universal remote controller. If operates, the manufacturer 213 process the user's report for the moment as a problem of Manufacturer 214 A. If not operates, the user report could be handled as a problem of 215 Manufacturer B. Manufacture A does not escalate the user's report to 216 Manufacture B in case of 2) above. At a glance, this behavior of 217 Manufacture A may not be sincere, but this is related with the 218 treatment of personal information. Nowadays, manufacturers collect 219 personal information of the user only in case they really need such 220 information. Following this information policy, if a lighting remote 221 controller does not operate the air conditioner, problem of 222 Manufacture B is suspected. However, Manufacturer A does not ask the 223 user for his/her personal information. Instead, they ask the user to 224 call Manufacturer B once again. 226 Because there are very extraordinary restrictions on transfer of 227 personal information among service providers in many countries, 228 aforementioned treatment of users has to prevail. Contrarily this 229 treatment is totally opposite to a direction of the one-stop services 230 that users generally look for. 232 Regarding cloud inter-connection, several opinions on issues in 233 business continuity were heard. Namely, in case of formulating DIFM 234 services containing services provided by others, the DIFM service 235 providers are concerned with adverse impacts of the suspension or 236 cancellation of other providers' services on his/her DIFM services. 237 The interconnection agreement does not make other providers promise 238 to continue the provision of the services to the DIFM providers. 239 However, the agreement possibly defines responsibility of advance 240 notification and a certain lead time for countermeasure formulation. 241 Therefore, the interconnection agreement is meaningful in this 242 regard. 244 4. IoT Device Operation Confirmation and Monitoring 246 As was mentioned before, it is prerequisite to secure function of 247 operation confirmation of related IoT Devices in DIFM business in its 248 services development and in processing claims of users during service 249 provision. Even in the experimental service development stage, it is 250 often necessary to identify where a fault occurs and how to isolate 251 the fault in case that IoT Device does not perform as it is expected. 252 This articulates an issue related to inter-operability which is the 253 purpose of inter-connection. Especially, fault identification and 254 capacity to recover the identified faults are very significant 255 issues. 257 In interviewing with IoT service providers, their capacity to process 258 users' claims involves the following three functions. 260 1) Monitoring fault incidents; 262 2) Fault isolation; and 264 3) On-site fault recovery capability 266 As of now, generally operational confirmation and monitoring 267 functions comprise the following items. 269 1) Alive monitoring of IoT Devices through confirmation on ping 270 signal communications; 272 2) Understanding of fault situations and history by remote reading 273 of equipment log; and 275 3) Alarm monitoring beyond pre-set threshold levels such as data 276 traffic volume 278 However, if the number of IoT Devices increases rapidly from now on, 279 a set of aforementioned simple monitoring functions may not be 280 efficient in terms of recovery capacity and cost competitiveness. It 281 is necessary to re-examine the scalability of current operation and 282 monitoring systems carefully and introduce required new technologies 283 for effective operational monitoring of widely proliferated IoT 284 Devices from now on. 286 5. Interconnection HUB 288 When a large number of manufacturers start the operation of 289 independent cloud groups, their mutual interconnection becomes more 290 and more complex as is mentioned before. Telephone and the Internet 291 are supported with so called interconnection gateway switch and IX 292 structures, achieving inter-connection among service providers. 294 Of course, in the IoT world, similar arrangements to connect among 295 cloud groups are possible. There is one difference from the era of 296 telephone and the Internet. This is no existence of inter-connection 297 communication protocols such as SS#7 and BGP4 here. 299 During the interviews with the providers, no one mentioned the 300 necessity of standardization of inter-cloud interconnection 301 communication protocols. Contrarily, many providers told that they 302 would utilize whatever they can use in an extremely businesslike 303 manner. Actually already existing inter-cloud interconnection 304 services do not specially focus on this issue. So it is considered 305 that interconnection HUBs would necessarily be structured in way HUBs 306 accommodate various different kinds of protocols. In order to 307 connect different protocols that respective cloud group utilize with 308 one another, the HUB side needs to be equipped with a driver module 309 matching each of the cloud groups to be connected. Authors call this 310 as a "printer driver model." 312 And according to a research of Authors, interconnection services 313 already put in place tend to take similar patterns such as inter- 314 cloud interconnection and application-cloud connection. Therefore it 315 is necessary to proceed with interconnections with different patterns 316 in order to make it more universal. 318 Service providers as a bussiness that Authors are considering are at 319 least the following four patterns. The University of Tokyo has 320 proceeded a research, recognizing requirements for infrastructures 321 for interconnection of those items. 323 [Pattern 1] Service providers with their private cloud connecting 324 with IoT devices, 326 [Pattern 2] preparing device drivers to IoT devices, 328 [Pattern 3] supplying gateways which connect IoT devices, and 330 [Pattern 4] application and service providers with with others IoT 331 devices. 333 +-------------------+ 334 [Pattern 1] | IoT HUB | 335 +------+ +--------------+ | | 336 | IoT +----+ Private |App|+----+| Cloud | | 337 |Device| | Cloud | || Driver| | 338 +------+ +--------------+ | + | 339 <----------------+ | | | 340 Inter-Cloud| | Interface-R | 341 Interconnection| | | 342 <----------------+ | | 343 +------+ +--------------+ | | 344 | IoT +----+ Private |App|+----+| Cloud | | 345 |Device| | Cloud | || Driver| | 346 +------+ +--------------+ | + | 347 | | | 348 | Interface-R | 349 Application-Cloud Interconnection 350 <------------------------------------->[Pattern 4] 351 | | +-------------+ 352 <---------------+ | | Web |+-+Application | 353 Device-Cloud| | | API || |(B2C/Service)| 354 Interconnection| | + | +-------------+ 355 <---------------+ | | | 356 | Interface-R | 357 [Pattern 2] | | 358 +------+ | | 359 | IoT +------------------------+| Thing | | 360 |Device| || Driver| | 361 +------+ | + | 362 | | | 363 | Interface-R | 364 [Pattern 3] | | 365 +------+ +-------------+ | | 366 | IoT | | Gateway | | | 367 |Device+-----+| Thing | +----+ | 368 | | || Driver| | | | 369 +------+ +-------------+ | | 370 | Database | 371 | Directory | 372 | Description | 373 +-------++----------+ 374 || 375 +-------++------+ 376 | Sekisyo | 377 | Service[1] | 378 +---------------+ 380 Figure 1: Structure of IoT HUB. 382 As a result, we verified the effectivness and flexibility of a new 383 architecture. The architecture has a common interface named 384 Interface-R within IoT-HUB, and all devices are connected to the HUB 385 by defining the drivers for R-interface. 387 6. Flexibility of this method 389 This method is designed to interconnect IoT Devices, the connectable 390 system is not limited to IoT Device. It can be connected with almost 391 no limitations, such as a block chain engine or a system for data 392 storage. As a result, it can be expected to contribute to the 393 development of new economy such as utilization of data. For example, 394 by setting the unit price for each operation of the IoT Device, costs 395 for deployment of IoT devices are reocovable. Or by using this HUB 396 as a branch point on the data transmission path, new business player 397 such as a data storage provider can be involved in the connection 398 between the IoT Device business companies. 400 7. Mechanisms to avoid threats when we make the inter-connection 402 As an example, let us consider a cooperative operation of "If the 403 outside air is fresh, turn off the air conditioner and open the 404 window". In case of humans operate, this behavior does not occur if 405 no one is in the house, however, this behavior can occur in IoT 406 whether the user is in the house or not. And your house can be 407 entered by a thief if you are absence and unlucky. 409 In this example, the threat of being entered by a thief can occur by 410 competing for the action of "opening the window" and the situation of 411 "absence". 413 For this reason, a mechanism for avoiding the occurrence of such 414 threats is required when we make inter-connection. 416 This can be realized by not permitting the target operation when the 417 combination causing the threat as described above. This mechanism 418 checks the movement of operations. In Japan, about 400 years ago, 419 the Shogunate (government) had set up the checkpoints of human 420 traffic, called the "sekisho." So, we are calling tentatively this 421 mechanism SEKISHO after this fact. 423 8. Security Considerations 425 Regarding security, pattern 2 of service providers specified in 426 Chapter 5 may contain some vulnerability and thus precaution is 427 required. 429 9. Privacy Considerations 431 Regarding privacy, Chapter 2 touches upon concerns on privacy among 432 inter-connected service providers in case of fault isolation after 433 IoT Device malfunctioning. 435 10. IANA Considerations 437 This document has no actions for IANA. 439 11. Acknowledgement 441 This paper contains findings of the study funded by the Ministry of 442 Internal Affairs and Communications of Japan as well as research 443 activities of IoT Committee of Internet Association Japan. We hereby 444 touch upon such facts and show our gratitude to those who relate to 445 the study and committee activities. 447 12. Normative References 449 [1] Baba, H., Ishida, Y., Amatsu, T., Kunitake, K., and K. 450 Maeda, "Problems in and among industries for the prompt 451 realization of IoT and safety considerations", 2020, 452 . 454 [2] Baba, H., Ishida, Y., Amatsu, T., Masuda, H., Ogura, S., 455 and K. Kunitake, "Report on Problem Solving Experiment for 456 Realization of Web-API-based IoT", 2020, . 459 Authors' Addresses 461 Hiroyuki Baba 462 The University of Tokyo 463 Institute of Industrial Science 464 4-6-1 Komaba 465 Meguro-ku, Tokyo 153-8505 466 Japan 468 Email: hbaba@iis.u-tokyo.ac.jp 469 Izaya Miyake 470 IoT Square Inc. 471 Hibiya Parkfront. 472 2-1-6, Uchisaiwai-cho 473 Chiyoda-ku, Tokyo 100-0011 474 Japan 476 Email: izmiyake@iot-sq.com 478 Jun Matsumura 479 BizMobile Inc. 480 Kanda Business Cube 3F 481 5-1, Kandatomiyama-cho 482 Chiyoda-ku, Tokyo 101-0043 483 Japan 485 Email: jumatsum@bizmobile.co.jp 487 Yoshiki Ishida 488 Japan Network Enabler Corporation 489 7F S-GATE Akasaka-Sanno. 490 1-8-1 Akasaka 491 Minato-ku, Tokyo 107-0052 492 Japan 494 Email: ishida@jpne.co.jp