idnits 2.17.1 draft-baba-iot-interconnection-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2020) is 1569 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 333 -- Looks like a reference, but probably isn't: 'Pattern 2' on line 356 -- Looks like a reference, but probably isn't: 'Pattern 3' on line 363 -- Looks like a reference, but probably isn't: 'Pattern 4' on line 329 Summary: 1 error (**), 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: July 12, 2020 IoT Square Inc. 6 J. Matsumura 7 BizMobile Inc. 8 Y. Ishida 9 Japan Network Enabler Corporation 10 January 9, 2020 12 Study Report on a Framework for Cloud Inter-connection toward the 13 Realization of IoT 14 draft-baba-iot-interconnection-03 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 July 12, 2020. 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. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 To date, based on the results of interviews with "Things" companies, 80 the authors of this paper, the Autors, issued a Problem Statement on 81 IoT [1], and reported on an experiment of WebAPI [2]. With further 82 interviewing and experiments, various requirements specification on a 83 base for securing cloud inter-connection in the anticipated IoT 84 society become clearer. 86 Currently, the use of various connected devices, hereinafter "IoT 87 Devices" is largely expected to become a using scene of IoT, and such 88 IoT Device manufacturers operates their private cloud groups, the 89 "Cloud", where IoT Devices are connected one after another. It 90 depends on the manufactures whether API of one cloud is open to a 91 third party or whether the cloud remains closed just for itself just 92 like a "silo". However, it is expected that API be open by 93 manufacturers in charge to third parties in the near future and a 94 large variety of values shall be created through cloud inter- 95 connection of IoT Devices that are connected to the other cloud 96 groups with a similar structure. Several cloud inter-connection 97 services, enabling one cloud with aforementioned IoT Devices to 98 connect with another cloud with IoT Devices, have already been 99 provided. 101 Thus, by combining cloud-connected IoT Devices, or "connected 102 Things", just like toy blocks being built freely through cloud inter- 103 connection, the era for creating a variety of benefits for users 104 seems to approach us. 106 As far as users select and handle connected Things on their own 107 response, there are not any significant issues. However, those whom 108 you cannot expect IT literacy like elder people should be able to get 109 access to benefits from IoT. If we stand on such an assumption, 110 there seem to be many open issues. 112 Furthermore, there is a concern of threats that cause danger to the 113 user's body, property, etc. when we make the inter-connection, and 114 the mechanism to avoid these threats are necessary. 116 The Authors conducted interviews with 9 market players including IoT 117 service providers and those who were preparing to provide IoT 118 services and undertook research and summarized issues that those 119 players felt with regard to cloud inter-connection. In parallel with 120 other researching experience, we discussed on what framework would be 121 required for doing IoT service provider businesses at smart houses. 122 In addition, we organized the basic concept of the mechanism for 123 avoiding threats when we make the inter-connection. This paper 124 outlines the findings from such discussions. 126 2. Draft Framework for Cloud Inter-connection 128 Not assuming the style where users enjoy combination of the use of 129 IoT Devices like DIY but assuming the one where so called service 130 providers offer IoT services to users on a "do-it-for-me (DIFM)" 131 manner, issues different from DIY style become more patent in the 132 light of responsibility for customers and business continuity. Those 133 issues are well diversified but may be summarized into three core 134 categories as follows: 136 (1) Inter-connection Agreement 138 Commercial cloud inter-connection requires some kind of contracts 139 without any doubt. Such contracting procedures are very common in 140 the Internet market. However, manufacturers of home appliances 141 and housing equipment have no experience and they feel worried. 143 (2) Operation Confirmation and Operation Monitoring of IoT Devices 145 Once being cloud-connected, it is necessary that not products of 146 one manufacture but also ones made by others are operated with 147 commands sent out of one's cloud server. At the development stage 148 of services and during operation of the services, the operation 149 monitoring of one's IoT Devices being connected with other's cloud 150 group just with commands of one's. 152 (3) Inter-connection Infrastructure 154 Currently a large number of manufacturers proceed with activities 155 in getting appliances and equipment that used to operate on a 156 standalone basis connected to the Internet. Those pieces of 157 appliances and equipment are independent of each other, namely 158 "silos". Therefore, in case of connecting all those pieces with 159 one another, the number of ways to connect needs to be N(N-1)/2. 160 To do this, much resources shall be required. As was seen in 161 telephone and the Internet, if HUBs connecting with one another 162 are put in place, this issue would be less cumbersome to some 163 extent. 165 The framework, comprising of above three points, shall be explained 166 in details in the following chapter. 168 3. Interconnection Agreement 170 In the era of IoT, it is desirable to facilitate contracting between 171 businesses smoothly by preparing a boilerplate format for an 172 interconnection agreement in advance. As described in the previous 173 chapter, because of the lack of experience in home appliances and 174 housing equipment manufacturers, needless to say, any guidelines or 175 formats would give great comfort to them. The benefits from an 176 interconnection agreement are to define responsibility of each 177 contracting party and clarify consent of the parties. 179 For example, manufacturers of gas cookers have been working on 180 operational linkage between a gas cooker and air conditioner in order 181 to harness the increase of room temperature. Possibly a universal 182 remote controller may be linked with a gas cooker and then the user 183 can of course operate an air conditioner with the gas cooker 184 controller. However, unless there is consent from the manufacturer 185 of the air conditioner on this link operation, the gas cooker 186 manufacturer seems to hesitate to pursue this due to his feeling that 187 this is not a fair business behavior. 189 Following precedents in the Internet, the contents of the 190 interconnection agreement include demarcation of responsibility, 191 procedures in operation and maintenance, cost allocation, technical 192 specifications, and general prohibitions. In addition to such 193 contents, however, the interconnection agreement becomes 194 significantly valuable by proving that participating parties formally 195 agree upon commercial terms of cloud inter-connection. 197 Of course, the agreement stipulates terms on malfunctioning of IoT 198 Devices. For example, there is a structure where an energy 199 management application located in a cloud group of lighting equipment 200 of Manufacturer A gives a command to a cloud group of air 201 conditioning equipment of Manufacturer B. By chance, one air 202 conditioner starts malfunctioning and the user may call a customer 203 service of Manufacturer A that provides DIFM energy management 204 services to the user. In this case, problems are 1) how the fault 205 can be isolated and 2) how this user's report can be transferred to 206 Manufacturer B if the fault is identified to come from the other 207 service provider, namely Manufacturer B. 209 In case of one manufacture Authors interviewed with, regarding 1) 210 above, the provider asks the user confirm the lighting operation by 211 its universal remote controller. If operates, the manufacturer 212 process the user's report for the moment as a problem of Manufacturer 213 A. If not operates, the user report could be handled as a problem of 214 Manufacturer B. Manufacture A does not escalate the user's report to 215 Manufacture B in case of 2) above. At a glance, this behavior of 216 Manufacture A may not be sincere, but this is related with the 217 treatment of personal information. Nowadays, manufacturers collect 218 personal information of the user only in case they really need such 219 information. Following this information policy, if a lighting remote 220 controller does not operate the air conditioner, problem of 221 Manufacture B is suspected. However, Manufacturer A does not ask the 222 user for his/her personal information. Instead, they ask the user to 223 call Manufacturer B once again. 225 Because there are very extraordinary restrictions on transfer of 226 personal information among service providers in many countries, 227 aforementioned treatment of users has to prevail. Contrarily this 228 treatment is totally opposite to a direction of the one-stop services 229 that users generally look for. 231 Regarding cloud inter-connection, several opinions on issues in 232 business continuity were heard. Namely, in case of formulating DIFM 233 services containing services provided by others, the DIFM service 234 providers are concerned with adverse impacts of the suspension or 235 cancellation of other providers' services on his/her DIFM services. 236 The interconnection agreement does not make other providers promise 237 to continue the provision of the services to the DIFM providers. 238 However, the agreement possibly defines responsibility of advance 239 notification and a certain lead time for countermeasure formulation. 240 Therefore, the interconnection agreement is meaningful in this 241 regard. 243 4. IoT Device Operation Confirmation and Monitoring 245 As was mentioned before, it is prerequisite to secure function of 246 operation confirmation of related IoT Devices in DIFM business in its 247 services development and in processing claims of users during service 248 provision. Even in the experimental service development stage, it is 249 often necessary to identify where a fault occurs and how to isolate 250 the fault in case that IoT Device does not perform as it is expected. 251 This articulates an issue related to inter-operability which is the 252 purpose of inter-connection. Especially, fault identification and 253 capacity to recover the identified faults are very significant 254 issues. 256 In interviewing with IoT service providers, their capacity to process 257 users' claims involves the following three functions. 259 1) Monitoring fault incidents; 261 2) Fault isolation; and 263 3) On-site fault recovery capability 265 As of now, generally operational confirmation and monitoring 266 functions comprise the following items. 268 1) Alive monitoring of IoT Devices through confirmation on ping 269 signal communications; 271 2) Understanding of fault situations and history by remote reading 272 of equipment log; and 274 3) Alarm monitoring beyond pre-set threshold levels such as data 275 traffic volume 277 However, if the number of IoT Devices increases rapidly from now on, 278 a set of aforementioned simple monitoring functions may not be 279 efficient in terms of recovery capacity and cost competitiveness. It 280 is necessary to re-examine the scalability of current operation and 281 monitoring systems carefully and introduce required new technologies 282 for effective operational monitoring of widely proliferated IoT 283 Devices from now on. 285 5. Interconnection HUB 287 When a large number of manufacturers start the operation of 288 independent cloud groups, their mutual interconnection becomes more 289 and more complex as is mentioned before. Telephone and the Internet 290 are supported with so called interconnection gateway switch and IX 291 structures, achieving inter-connection among service providers. 293 Of course, in the IoT world, similar arrangements to connect among 294 cloud groups are possible. There is one difference from the era of 295 telephone and the Internet. This is no existence of inter-connection 296 communication protocols such as SS#7 and BGP4 here. 298 During the interviews with the providers, no one mentioned the 299 necessity of standardization of inter-cloud interconnection 300 communication protocols. Contrarily, many providers told that they 301 would utilize whatever they can use in an extremely businesslike 302 manner. Actually already existing inter-cloud interconnection 303 services do not specially focus on this issue. So it is considered 304 that interconnection HUBs would necessarily be structured in way HUBs 305 accommodate various different kinds of protocols. In order to 306 connect different protocols that respective cloud group utilize with 307 one another, the HUB side needs to be equipped with a driver module 308 matching each of the cloud groups to be connected. Authors call this 309 as a "printer driver model." 311 And according to a research of Authors, interconnection services 312 already put in place tend to take similar patterns such as inter- 313 cloud interconnection and application-cloud connection. Therefore it 314 is necessary to proceed with interconnections with different patterns 315 in order to make it more universal. 317 Service providers as a bussiness that Authors are considering are at 318 least the following four patterns. The University of Tokyo has 319 proceeded a research, recognizing requirements for infrastructures 320 for interconnection of those items. 322 [Pattern 1] Service providers with their private cloud connecting 323 with IoT devices, 325 [Pattern 2] preparing device drivers to IoT devices, 327 [Pattern 3] supplying gateways which connect IoT devices, and 329 [Pattern 4] application and service providers with with others IoT 330 devices. 332 +-------------------+ 333 [Pattern 1] | IoT HUB | 334 +------+ +--------------+ | | 335 | IoT +----+ Private |App|+----+| Cloud | | 336 |Device| | Cloud | || Driver| | 337 +------+ +--------------+ | + | 338 <----------------+ | | | 339 Inter-Cloud| | Interface-R | 340 Interconnection| | | 341 <----------------+ | | 342 +------+ +--------------+ | | 343 | IoT +----+ Private |App|+----+| Cloud | | 344 |Device| | Cloud | || Driver| | 345 +------+ +--------------+ | + | 346 | | | 347 | Interface-R | 348 Application-Cloud Interconnection 349 <------------------------------------->[Pattern 4] 350 | | +-------------+ 351 <---------------+ | | Web |+-+Application | 352 Device-Cloud| | | API || |(B2C/Service)| 353 Interconnection| | + | +-------------+ 354 <---------------+ | | | 355 | Interface-R | 356 [Pattern 2] | | 357 +------+ | | 358 | IoT +------------------------+| Thing | | 359 |Device| || Driver| | 360 +------+ | + | 361 | | | 362 | Interface-R | 363 [Pattern 3] | | 364 +------+ +-------------+ | | 365 | IoT | | Gateway | | | 366 |Device+-----+| Thing | +----+ | 367 | | || Driver| | | | 368 +------+ +-------------+ | | 369 | Database | 370 | Directory | 371 | Description | 372 +-------++----------+ 373 || 374 +-------++------+ 375 | Sekisyo | 376 | Service[1] | 377 +---------------+ 379 Figure 1: Structure of IoT HUB. 381 As a result, we verified the effectivness and flexibility of a new 382 architecture. The architecture has a common interface named 383 Interface-R within IoT-HUB, and all devices are connected to the HUB 384 by defining the drivers for R-interface. 386 6. Flexibility of this method 388 This method is designed to interconnect IoT Devices, the connectable 389 system is not limited to IoT Device. It can be connected with almost 390 no limitations, such as a block chain engine or a system for data 391 storage. As a result, it can be expected to contribute to the 392 development of new economy such as utilization of data. For example, 393 by setting the unit price for each operation of the IoT Device, costs 394 for deployment of IoT devices are reocovable. Or by using this HUB 395 as a branch point on the data transmission path, new business player 396 such as a data storage provider can be involved in the connection 397 between the IoT Device business companies. 399 7. Mechanisms to avoid threats when we make the inter-connection 401 As an example, let us consider a cooperative operation of "If the 402 outside air is fresh, turn off the air conditioner and open the 403 window". In case of humans operate, this behavior does not occur if 404 no one is in the house, however, this behavior can occur in IoT 405 whether the user is in the house or not. And your house can be 406 entered by a thief if you are absence and unlucky. 408 In this example, the threat of being entered by a thief can occur by 409 competing for the action of "opening the window" and the situation of 410 "absence". 412 For this reason, a mechanism for avoiding the occurrence of such 413 threats is required when we make inter-connection. 415 This can be realized by not permitting the target operation when the 416 combination causing the threat as described above. This mechanism 417 checks the movement of operations. In Japan, about 400 years ago, 418 the Shogunate (government) had set up the checkpoints of human 419 traffic, called the "sekisho." So, we are calling tentatively this 420 mechanism SEKISHO after this fact. 422 8. Security Considerations 424 Regarding security, pattern 2 of service providers specified in 425 Chapter 5 may contain some vulnerability and thus precaution is 426 required. 428 9. Privacy Considerations 430 Regarding privacy, Chapter 2 touches upon concerns on privacy among 431 inter-connected service providers in case of fault isolation after 432 IoT Device malfunctioning. 434 10. Acknowledgement 436 This paper contains findings of the study funded by the Ministry of 437 Internal Affairs and Communications of Japan as well as research 438 activities of IoT Committee of Internet Association Japan. We hereby 439 touch upon such facts and show our gratitude to those who relate to 440 the study and committee activities. 442 11. Normative References 444 [1] Baba, H., Ishida, Y., Amatsu, T., Kunitake, K., and K. 445 Maeda, "Problems in and among industries for the prompt 446 realization of IoT and safety considerations", 2020, 447 . 449 [2] Baba, H., Ishida, Y., Amatsu, T., Masuda, H., Ogura, S., 450 and K. Kunitake, "Report on Problem Solving Experiment for 451 Realization of Web-API-based IoT", 2020, . 454 Authors' Addresses 456 Hiroyuki Baba 457 The University of Tokyo 458 Institute of Industrial Science 459 4-6-1 Komaba 460 Meguro-ku, Tokyo 153-8505 461 Japan 463 Email: hbaba@iis.u-tokyo.ac.jp 465 Izaya Miyake 466 IoT Square Inc. 467 Hibiya Parkfront. 468 2-1-6, Uchisaiwai-cho 469 Chiyoda-ku, Tokyo 100-0011 470 Japan 472 Email: izmiyake@iot-sq.com 473 Jun Matsumura 474 BizMobile Inc. 475 Kanda Business Cube 3F 476 5-1, Kandatomiyama-cho 477 Chiyoda-ku, Tokyo 101-0043 478 Japan 480 Email: jumatsum@bizmobile.co.jp 482 Yoshiki Ishida 483 Japan Network Enabler Corporation 484 7F S-GATE Akasaka-Sanno. 485 1-8-1 Akasaka 486 Minato-ku, Tokyo 107-0052 487 Japan 489 Email: ishida@jpne.co.jp