idnits 2.17.1 draft-iab-smart-object-architecture-06.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 (October 29, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-iab-privsec-confidentiality-threat-00 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft 4 Intended status: Informational J. Arkko 5 Expires: May 2, 2015 6 D. Thaler 8 D. McPherson 10 October 29, 2014 12 Architectural Considerations in Smart Object Networking 13 draft-iab-smart-object-architecture-06.txt 15 Abstract 17 The term "Internet of Things" (IoT) denotes a trend where a large 18 number of embedded devices employ communication services offered by 19 the Internet protocols. Many of these devices, often called "smart 20 objects" are not directly operated by humans, but exist as components 21 in buildings or vehicles, or are spread out in the environment. 22 Following the theme "Everything that can be connected will be 23 connected", engineers and researchers designing smart object networks 24 need to decide how to achieve this in practice. 26 This document offers guidance to engineers designing Internet 27 connected smart objects. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 2, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Smart Object Communication Patterns . . . . . . . . . . . . . 4 65 2.1. Device-to-Device Communication Pattern . . . . . . . . . 4 66 2.2. Device-to-Cloud Communication Pattern . . . . . . . . . . 6 67 2.3. Device-to-Gateway Communication Pattern . . . . . . . . . 7 68 2.4. Back-end Data Sharing Pattern . . . . . . . . . . . . . . 9 69 3. Re-Use Internet Protocols . . . . . . . . . . . . . . . . . . 10 70 4. The Deployed Internet Matters . . . . . . . . . . . . . . . . 13 71 5. Design for Change . . . . . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 76 10. IAB Members at the Time of This Writing . . . . . . . . . . . 19 77 11. Informative References . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 RFC 6574 [RFC6574] refers to smart objects as devices with 83 constraints on energy, bandwidth, memory, size, cost, etc. This is a 84 fuzzy definition, as there is clearly a continuum in device 85 capabilities and there is no hard line to draw between devices that 86 can run Internet Protocols and those that can't. 88 Interconnecting smart objects with the Internet enables exciting new 89 use cases and products. An increasing number of products put the 90 Internet Protocol suite on smaller and smaller devices and offer the 91 ability to process, visualize, and gain insight from the collected 92 sensor data. The network effect can be increased if the data 93 collected from many different devices can be combined. 95 Developing embedded systems is a complex task, and designers must 96 make a number of design decisions such as: 98 o How long is the device designed to operate? 100 o How does it interact with the physical world? Is it a sensor or 101 actuator or both? 103 o How many "owners" does it have? One? Many? Is the owner likely 104 to change over the lifetime of the device? 106 o Is it continuously powered? Intermittently powered? Does it 107 sleep? 109 o Is it connected to a network, and if so, how? 111 o Will it be physically accessible for direct maintenance after 112 deployment? How does that affect the security model? 114 While developing embedded systems is itself a complex task, designing 115 Internet-connected smart objects is even harder since it requires 116 expertise with Internet protocols in addition to software programming 117 and hardware skills. To simplify the development task, and thereby 118 to lower the cost of developing new products and prototypes, we 119 believe that re-use of prior work is essential. Therefore, we 120 provide high-level guidance on the use of Internet technology for the 121 development of smart objects, and connected systems in general. 123 Utilize Existing Design Patterns 125 Design patterns are generally reusable solutions to a commonly 126 occurring design problem (see [Gamma] for more discussion). 127 Existing smart object deployments show communication patterns that 128 can be re-used by engineers with the benefit of lowering the 129 design effort. As discussed in the sections below, individual 130 patterns also have an implication on the required interoperability 131 between the different entities. Depending on the desired 132 functionality, already existing patterns can be re-used and 133 adjusted. Section 2 talks about various communication patterns. 135 Re-Use Internet Protocols 137 Most smart object deployments can make use of the already 138 standardized Internet protocol suite. The Internet protocols can 139 be applied to almost any environment due to their generic design, 140 and typically offer plenty of potential for re-configuration, 141 which allows them to be tailored for the specific needs. 142 Section 3 discusses this topic. 144 The Deployed Internet matters 146 When connecting smart objects to the Internet, take existing 147 deployment into consideration to avoid unpleasant surprises. 148 Assuming an ideal, clean-slate deployments is, in many cases, far 149 too optimistic since the already deployed infrastructure is 150 convenient to use. In Section 4 we highlight the importance of 151 this topic. 153 Design for Change 155 The Internet infrastructure, the applications and preferred 156 building blocks evolve over time. Especially long-lived smart 157 object deployments need to take this change into account and 158 Section 5 is dedicated to that topic. 160 2. Smart Object Communication Patterns 162 This section illustrates a number of communication patterns utilized 163 in the smart object environment. It is possible that more than one 164 pattern can be applied at the same time in a product. Developers re- 165 using those patterns will benefit from the experience of others as 166 well as from documentation, source code, and available products. 168 2.1. Device-to-Device Communication Pattern 170 Figure 1 illustrates a communication pattern where two devices 171 developed by different manufacturers are desired to interoperate and 172 communicate directly. To pick an example from [RFC6574], consider a 173 light switch that talks to a light bulb with the requirement that 174 each may be manufactured by a different company, represented as 175 manufacturer A and B. Other cases can be found with fitness 176 equipment, such as heart-rate monitors and cadence sensors. 178 _,,,, ,,,, 179 / -'`` \ 180 | Wireless | 181 \ Network | 182 / \ 183 ,''''''''| / . ,''''''''| 184 | Light | ------|------------------\------| Light | 185 | Bulb | . | | Switch | 186 |........' `'- / |........' 187 \ _-...-` 188 Manufacturer `. ,.' Manufacturer 189 A ` B 191 Figure 1: Device-to-Device Communication Pattern 193 In order to fulfill the promise that devices from different 194 manufacturers are able to communicate out-of-the-box, these vendors 195 need to agree on the protocol stack. They need to make decisions 196 about the following protocol design aspects: 198 o Which physical layer(s) should be supported? Does it use low 199 power radio technologies (e.g., Bluetooth Smart, IEEE 802.15.4)? 201 o Can devices be IPv6-only, or must they also support IPv4 for 202 legacy/backward compatibility reasons? What IPv4-IPv6 transition 203 technologies are needed? 205 o Which IP address configuration mechanism(s) are integrated into 206 the device? 208 o Which communication architectures shall be supported? Which 209 devices are constrained and what are those constraints? Is there 210 a classical client-server model or rather a peer-to-peer model? 212 o Is there a need for a service discovery mechanism to allow users 213 to discover light bulbs they have in their home or office? 215 o Which transport-layer protocol is used for conveying the sensor 216 readings/sensor commands? (e.g., UDP) 218 o Which application-layer protocol is used? (for example, CoAP 219 [RFC7252]) 221 o What information model is used for expressing the different light 222 levels? 224 o What data model is used to encode information? (See RFC 3444 225 [RFC3444]) for a discussion about the difference between data 226 models and information models.)? 228 o Finally, security and privacy require careful thought. This 229 includes questions like: what are the security threats? What 230 security services need to be provided to deal with the identified 231 threats? Where do the security credentials come from? At what 232 layer(s) in the protocol stack should the security mechanism(s) 233 reside? What privacy implications are caused by various design 234 decisions? 236 This list is not meant to be exhaustive but aims to illustrate that 237 for every usage scenario many design decisions will have to be made 238 in order to accommodate the constrained nature of a specific device 239 in a certain usage scenario. Standardizing such a complete solution 240 to accomplish a full level of interoperability between two devices 241 manufactured by different vendors takes time but there are obvious 242 rewards for end customers and vendors. 244 2.2. Device-to-Cloud Communication Pattern 246 Figure 2 shows a communication pattern for uploading sensor data to 247 an application service provider. Often the application service 248 provider (example.com in our illustration) also sells smart objects. 249 In that case the entire communication happens internal to the 250 provider and no need for interoperability arises. Still, it is 251 useful for example.com to re-use existing specifications to lower the 252 design, implementation, testing and development effort. 254 While this pattern allows using IP-based communication end-to-end it 255 may still lead to silos. To prevent silos, example.com may allow 256 third party device vendors to connect to their server infrastructure 257 as well. For those cases, the protocol interface used to communicate 258 with the server infrastructure needs to be made available, and 259 various standards are available, such as CoAP, DTLS [RFC6347], UDP, 260 IP, etc. as shown in Figure 2. A frequent concern from end users is 261 that a change in the business model (or bankruptcy) of the IoT 262 device/service provide might make the hardware become unusable. 263 Companies might consider the possibility to release their source code 264 for the IoT device, or to allow other IoT operating systems (plus 265 application software) to be installed on the IoT device. 267 Similarly, in many situations it is desirable to change which cloud 268 service a device connects to, such as when an application service 269 provider changes its hosting provider. Again, standard Internet 270 protocols are needed. 272 Since the access networks to which various smart objects are 273 connected are typically not under the control of the application 274 service provider, commonly used radio technologies (such as WLAN, 275 wired Ethernet, and cellular radio) together with the network access 276 authentication technology have to be re-used. The same applies to 277 standards used for IP address configuration. 279 ................. 280 | Application | 281 | Service | 282 | Provider | 283 | example.com | 284 |_______________| 285 _, . 286 HTTP ,' `. CoAP 287 TLS _,' `. DTLS 288 TCP ,' `._ UDP 289 IP-' - IP 290 ,'''''''''''''| ,'''''''''''''''''| 291 | Device with | | Device with | 292 | Temperature | | Carbon Monoxide | 293 | Sensor | | Sensor | 294 |.............' |.................' 296 Figure 2: Device-to-Cloud Communication Pattern 298 2.3. Device-to-Gateway Communication Pattern 300 The device-to-cloud communication pattern, described in Section 2.2, 301 is convenient for vendors of smart objects and works well if they 302 choose a radio technology that is widely deployed in the targeted 303 market, such as IEEE 802.11-based Wifi for smart home use cases. 304 Sometimes less widely available radio technologies are needed (such 305 as IEEE 802.15.4) or special application layer functionality (e.g., 306 local authentication and authorization) has to be provided, or 307 interoperability is needed with legacy, non-IP-based devices. In 308 those cases some form of gateway has to be introduced into the 309 communication architecture that bridges between the different 310 technologies and performs other networking and security 311 functionality. Figure 3 shows this pattern graphically. Often, 312 these gateways are provided by the same vendor that offers the IoT 313 product, for example because of the use of proprietary protocols, to 314 lower the dependency on other vendors, or to avoid potential 315 interoperability problems. It is expected that in the future more 316 generic gateways will be deployed to lower cost and infrastructure 317 complexity for end consumers, enterprises, and industrial 318 environments. Such generic gateways are more likely to exist if IoT 319 device designs make use of generic Internet protocols and not require 320 application layer gateways that translate one application layer 321 protocol to another one. The use of application layer gateways will 322 in general lead to a more fragile deployment, as it had been observed 323 in the past already with RFC 3724 [RFC3724] and RFC 3238 [RFC3238]. 325 This communication pattern can frequently be found with smart object 326 deployments that require remote configuration capabilities and real- 327 time interactions. The gateway is thereby assumed to be always 328 connected to the Internet. 330 ................. 331 | Application | 332 | Service | 333 | Provider | 334 | example.com | 335 |_______________| 336 | 337 | 338 | IPv4/IPv6 339 ................. 340 | Local | 341 | Gateway | 342 | | 343 |_______________| 344 _, . 345 HTTP ,' `. CoAP 346 TLS _,' Bluetooth Smart `. DTLS 347 TCP ,' IEEE 802.11 `._ UDP 348 IPv6-' IEEE 802.15.4 - IPv6/6lo 349 ,'''''''''''''| ,'''''''''''''''''| 350 | Device with | | Device with | 351 | Temperature | | Carbon Monoxide | 352 | Sensor | | Sensor | 353 |.............' |.................' 355 Figure 3: Device-to-Gateway Communication Pattern 357 If the gateway is mobile, such as when the gateway is a smartphone, 358 connectivity between the devices and the Internet may be 359 intermittent. This limits the applicability of such a communication 360 pattern but is nevertheless very common with wearables and other IoT 361 devices that do not need always-on Internet or real-time Internet 362 connectivity. From an interoperability point of view it is worth 363 noting that smartphones with their sophisticated software update 364 mechanism via app stores allow new functionality to be updated 365 regularly at the smartphone and sometimes even at the IoT device. 367 With special apps that are tailored to each specific IoT device 368 interoperability is mainly a concern with regard to the lower layers 369 of the protocol stack, such as the radio interface, and less so at 370 the application layer (if users are willing to download a new app for 371 each IoT device). 373 It is also worth pointing out that a gateway allows supporting both 374 IPv6 and IPv4 (for compatibility with legacy application service 375 providers) externally, while allowing devices to be IPv6-only to 376 reduce footprint requirements. If devices do not have the resources 377 to support both IPv4 and IPv6 themselves, being IPv6-only (rather 378 than IPv4-only) with a gateway enables the most flexibility, avoiding 379 the need to update devices to support IPv6 later, whereas IPv4 380 address exhaustion makes it ill-suited to scale to smart object 381 networks. See [RFC6540] for further discussion. 383 2.4. Back-end Data Sharing Pattern 385 The device-to-cloud pattern often leads to silos; IoT devices upload 386 data only to a single application service provider. However, users 387 often demand the ability to export and to analyze data in combination 388 with data from other sources. Hence, the desire for granting access 389 to the uploaded sensor data to third parties arises. This design is 390 shown in Figure 4. This pattern is known from the Web in case of 391 mashups and is therefore re-applied to the smart object context. To 392 offer familiarity for developers, typically a RESTful API design in 393 combination with a federated authentication and authorization 394 technology (like OAuth 2.0 [RFC6749]) is re-used. While this offers 395 re-use at the level of building blocks, the entire protocol stack 396 (including the information/data model and RESTful Web APIs) is often 397 not standardized. 399 ................. 400 | Application | 401 .| Service | 402 ,-` | Provider | 403 .` | b-example.com | 404 ,-` |_______________| 405 .` 406 ................. ,-` 407 | Application |-` HTTPS 408 | Service | OAuth 2.0 409 | Provider | JSON 410 | example.com |-, 411 |_______________| '. 412 _, `', 413 ,' '. 414 _,' CoAP or `', ................. 415 ,' HTTP '. | Application | 416 -' `'| Service | 417 ,''''''''| | Provider | 418 | Light | | c-example.com | 419 | Sensor | |_______________| 420 |........' 422 Figure 4: Backend Data Sharing Pattern 424 3. Re-Use Internet Protocols 426 When discussing the need for re-use of available standards vs. 427 extending or re-designing protocols, it is useful to look back at the 428 criteria for success of the Internet. 430 RFC 1958 [RFC1958] provides lessons from the early days of the 431 Internet and says: 433 "The Internet and its architecture have grown in evolutionary 434 fashion from modest beginnings, rather than from a Grand Plan", 436 and adds: 438 "A good analogy for the development of the Internet is that of 439 constantly renewing the individual streets and buildings of a 440 city, rather than razing the city and rebuilding it." 442 Yet because building very small, battery-powered devices is 443 challenging, it may be difficult to resist the temptation to build 444 solutions tailored to specific applications, or even to re-design 445 networks from scratch to suit a particular application. 447 While developing consensus-based standards in an open and transparent 448 process takes longer than developing proprietary solutions, the 449 resulting solutions often remain relevant over a longer period of 450 time. 452 RFC 1263 [RFC1263] considers protocol design strategy and the 453 decision to design new protocols or to use existing protocols in a 454 non-backward compatible way: 456 "We hope to be able to design and distribute protocols in less 457 time than it takes a standards committee to agree on an acceptable 458 meeting time. This is inevitable because the basic problem with 459 networking is the standardization process. Over the last several 460 years, there has been a push in the research community for 461 lightweight protocols, when in fact what is needed are lightweight 462 standards. Also note that we have not proposed to implement some 463 entirely new set of 'superior' communications protocols, we have 464 simply proposed a system for making necessary changes to the 465 existing protocol suites fast enough to keep up with the 466 underlying change in the network. In fact, the first standards 467 organization that realizes that the primary impediment to 468 standardization is poor logistical support will probably win." 470 While [RFC1263] was written in 1991 when the standardization process 471 was more lightweight than today, these thoughts remain relevant in 472 smart object development. 474 Interestingly, a large number of already standardized protocols are 475 relevant for smart object deployments. RFC 6272 [RFC6272], for 476 example, made the attempt to identify relevant IETF specifications 477 for use in smart grids. 479 Still, many commercial products contain proprietary or industry- 480 specific protocol mechanisms and researchers have made several 481 attempts to design new architectures for the entire Internet system. 482 There are several architectural concerns that deserve to be 483 highlighted: 485 Vertical Profiles 487 The discussions at the IAB workshop (see Section 3.1.2 of 488 [RFC6574]) revealed the preference of many participants to develop 489 domain-specific profiles that select a minimum subset of protocols 490 needed for a specific operating environment. Various 491 standardization organizations and industry fora are currently 492 engaged in activities of defining their preferred profile(s). 493 Ultimately, however, the number of domains where smart objects can 494 be used is essentially unbounded. There is also an ever-evolving 495 set of protocols and protocol extensions. 497 However, merely changing the networking protocol to IP does not 498 necessarily bring the kinds of benefits that industries are 499 looking for in their evolving smart object deployments. In 500 particular, a profile is rigid, and leaves little room for 501 interoperability among slightly differing, or competing technology 502 variations. As an example, layer 1 through 7 type profiles do not 503 account for the possibility that some devices may use different 504 physical media than others, and that in such situations a simple 505 router could still provide an ability to communicate between the 506 parties. 508 Industry-Specific Solutions 510 The Internet Protocol suite is more extensive than merely the use 511 of IP. Often significant benefits can be gained from using 512 additional, widely available, generic technologies, such as the 513 Web. Benefits from using these kinds of tools include access to a 514 large available workforce, software, and education already geared 515 towards employing the technology. 517 Tight Coupling 519 Many applications are built around a specific set of servers, 520 devices, and users. However, often the same data and devices 521 could be useful for many purposes, some of which may not be easily 522 identifiable at the time the devices are deployed. 524 In addition to the architectural concerns, developing new protocols 525 and mechanisms is generally more risky and expensive than reusing 526 existing standards, due to the additional costs involved in design, 527 implementation, testing, and deployment. Secondary costs, such as 528 training of technical staff and, in the worst case, training of end 529 users, can be substantial. 531 As a result, while there are some cases where specific solutions are 532 needed, the benefits of general-purpose technology are often 533 compelling, be it choosing IP over some more specific communication 534 mechanism, a widely deployed link-layer (such as wireless LAN) over a 535 more specific one, web technology over application specific 536 protocols, and so on. 538 However, when employing these technologies, it is important to 539 embrace them in their entirety, allowing for the architectural 540 flexibility that is built into them. As an example, it rarely makes 541 sense to limit communications to on-link or to specific media. 543 Design your applications so that the participating devices can easily 544 interact with multiple other applications. 546 4. The Deployed Internet Matters 548 Despite the applicability of the Internet Protocols for smart 549 objects, picking the specific protocols for a particular use case can 550 be tricky. As the Internet has evolved, certain protocols and 551 protocol extensions have become the norm and others have become 552 difficult to use in all circumstances. 554 Taking into account these constraints is particularly important for 555 smart objects, as there is often a desire to employ specific features 556 to support smart object communication. For instance, from a pure 557 protocol specification perspective, some transport protocols may be 558 more desirable than others. These constraints apply both to the use 559 of existing protocols as well as designing new ones on top of the 560 Internet Protocol stack. 562 The following list illustrates a few of those constraints, but every 563 communication protocol comes with its own challenges. 565 In 2005, Fonseca, et al. [IPoptions] studied the usage of IP 566 options-enabled packets in the Internet and found that overall, 567 approximately half of Internet paths drop packets with options, 568 making extensions using IP options "less ideal" for extending IP. 570 In 2010, Honda, et al. [HomeGateway] tested 34 different home 571 gateways regarding their packet dropping policy of UDP, TCP, DCCP, 572 SCTP, ICMP, and various timeout behavior. For example, more than 573 half of the tested devices do not conform to the IETF recommended 574 timeouts for UDP, and for TCP the measured timeouts are highly 575 variable, ranging from less than 4 minutes to longer than 25 hours. 576 For NAT traversal of DCCP and SCTP, the situation is poor. None of 577 the tested devices, for example, allowed establishing a DCCP 578 connection. 580 In 2011, [TCPextensions] tested the behavior of networks with regard 581 to various TCP extensions: "From our results we conclude the 582 middleboxes implementing layer 4 functionality are very common -- at 583 least 25% of paths interfered with TCP in some way beyond basic 584 firewalling." 586 Extending protocols to fulfill new uses and to add new functionality 587 may range from very easy to difficult, as [RFC6709] explains in great 588 detail. A challenge many protocol designers are facing is to ensure 589 incremental deployability and interoperability with incumbent 590 elements in a number of areas. In various cases, the effort it takes 591 to design incrementally deployable protocols has not been taken 592 seriously enough at the outset. RFC 5218 on "What Makes For a 593 Successful Protocol?" [RFC5218] defines wildly successful protocols 594 as protocols that are widely deployed beyond their envisioned use 595 cases. 597 As these examples illustrate, protocol architects have to take 598 developments in the greater Internet into account, as not all 599 features can be expected to be usable in all environments. For 600 instance, middleboxes [RFC3234] complicate the use of extensions in 601 the basic IP protocols and transport-layers. 603 RFC 1958 [RFC1958] considers this aspect and says "... the community 604 believes that the goal is connectivity, the tool is the Internet 605 Protocol, and the intelligence is end to end rather than hidden in 606 the network." This statement is challenged more than ever with the 607 perceived need to develop intermediaries interacting with less 608 intelligent end devices. However, RFC 3724 [RFC3724] has this to say 609 about this crucial aspect: "One desirable consequence of the end-to- 610 end principle is protection of innovation. Requiring modification in 611 the network in order to deploy new services is still typically more 612 difficult than modifying end nodes." Even this statement will become 613 challenged, as large numbers of devices are deployed and it indeed 614 might be the case that changing those devices is hard. But RFC 4924 615 [RFC4924] adds that a network that does not filter or transform the 616 data that it carries may be said to be "transparent" or "oblivious" 617 to the content of packets. Networks that provide oblivious transport 618 enable the deployment of new services without requiring changes to 619 the core. It is this flexibility that is perhaps both the Internet's 620 most essential characteristic as well as one of the most important 621 contributors to its success. 623 5. Design for Change 625 How to embrace rapid innovation and at the same time accomplish a 626 high level of interoperability is one of the key aspects for 627 competing in the market place. RFC 1263 [RFC1263] points out that 628 "protocol change happens and is currently happening at a very 629 respectable clip. We simply propose [for engineers developing the 630 technology] to explicitly deal with the changes rather keep trying to 631 hold back the flood.". 633 In [Tussels] Clark, et al. suggest to "design for variation in 634 outcome, so that the outcome can be different in different places, 635 and the tussle takes place within the design, not by distorting or 636 violating it. Do not design so as to dictate the outcome. Rigid 637 designs will be broken; designs that permit variation will flex under 638 pressure and survive.". The term tussle refers to the process 639 whereby different parties, which are part of the Internet milieu and 640 have interests that may be adverse to each other, adapt their mix of 641 mechanisms to try to achieve their conflicting goals, and others 642 respond by adapting the mechanisms to push back. 644 In order to accomplish this, Clark, et al. suggest to 646 1. Break complex systems into modular parts, so that one tussle does 647 not spill over and distort unrelated issues. 649 2. Design for choice to permit the different players to express 650 their preferences. Choice often requires open interfaces. 652 The main challenge with the suggested approach is to predict how 653 conflicts among the different players will evolve. Since tussles 654 evolve over time, there will be changes to the architecture too. It 655 is certainly difficult to pick the right set of building blocks and 656 to develop a communication architecture that will last a long time, 657 and many smart object deployments are envisioned to be rather long- 658 lived. 660 Luckily, the design of the system does not need to be cast in stone 661 during the design phase. It may adjust dynamically since many of the 662 protocols allow for configurability and dynamic discovery. But 663 ultimately software update mechanisms may provide the flexibility 664 needed to deal with more substantial changes. 666 A solid software update mechanism is needed not only for dealing with 667 the changing Internet communication environment and for 668 interoperability improvements but also for adding new features and 669 for fixing security bugs. This approach may appear to be in conflict 670 with classes of severely restricted devices since, in addition to a 671 software update mechanism, spare flash and RAM capacity is needed. 672 It is, however, a tradeoff worth thinking about since better product 673 support comes with a price. 675 As technology keeps advancing, the constraints that the technology 676 places on devices evolve as well. Microelectronics became more 677 capable as time goes by, often making it possible for new devices to 678 be both less expensive and more capable than their predecessors. 679 This trend can, however, be in some cases offset by the desire to 680 embed communications technology in even smaller and cheaper objects. 681 But it is important to design communications technology not just for 682 today's constraints, but also tomorrow's. This is particularly 683 important since the cost of a product is not only determined by the 684 cost of hardware but also by the cost of not reusing already 685 available protocol stacks and software library by developing custom 686 solutions. 688 Software updates are common in operating systems and application 689 programs today. Without them, most devices would pose a latent risk 690 to the Internet at large. Arguably, the JavaScript-based web employs 691 a very rapid software update mechanism with code being provided by 692 many different parties (e.g., by websites loaded into the browser or 693 by smartphone apps). 695 6. Security Considerations 697 Security is often even more important for smart objects than for more 698 traditional computing systems, since interacting directly with the 699 physical world can present greater dangers and smart objects often 700 operate autonomously without any human interaction for a long time 701 period. The problem is compounded by the fact that there are often 702 fewer resources available in constrained devices to actually 703 implement security (e.g., see the discussion of "Class 0 devices" in 704 Section 3 of [RFC7228]). As such, it is critical to design for 705 security, taking into account a number of key considerations: 707 o A key part of any smart object design is the problem of how to 708 establish trust for a smart object. Typically, bootstrapping 709 trust involves giving the device the credentials it needs to 710 operate within a larger network of devices or services. 712 o Smart objects will in many cases be deployed in places where 713 additional physical security is difficult or impossible. 714 Designers should take into account that any such device can and 715 will be compromised by an attacker with direct physical access. 716 Thus, trust models should distinguish between devices susceptible 717 to physical compromise and devices with some level of physical 718 security. Physical attacks, such as timing, power analysis, and 719 glitching, are commonly applied to extract secrets 720 [PhysicalAttacks]. 722 o Smart objects will in many cases be deployed as collections of 723 identical or near identical devices. Protocols should be designed 724 so that a compromise of a single device does not result in 725 compromise of the entire collection, especially since the 726 compromise of a large number of devices can enable additional 727 attacks such as a distributed denial of service. Sharing secret 728 keys across an entire product family is therefore also problematic 729 since compromise of a single device might leave all devices from 730 that product family vulnerable. 732 o Smart objects will in many cases be deployed in ways that the 733 designer never considered. Designers should either seek to 734 minimize the impact of misuse of their systems and devices, or 735 implement controls to prevent such misuse where applicable. 737 o It is anticipated that smart objects will be deployed with a long 738 (e.g., 5-40 years) life-cycle. Any security mechanism chosen at 739 the outset may not be "good enough" for the full lifespan of the 740 device. Thus, long-lived devices should start with good security 741 and provide a path to deploy new security mechanisms over the 742 lifetime of the device. 744 o Security protocols often rely on random numbers and offering 745 randomness in embedded devices is challenging. For this reason, 746 it is important to consider the use of hardware-based random 747 number generators during early states of the design process. 749 A more detailed security discussion can be found in the report from 750 the "Smart Object Security" workshop 751 [I-D.gilger-smart-object-security-workshop] that was held prior to 752 the IETF meeting in Paris, March 2012, and in the report from the 753 National Science Foundation's "Cybersecurity Ideas Lab" workshop 754 [NSF] that was held in February 2014. For example, [NSF] includes, 755 among other recommendations, these recommendations specific to the 756 Internet of Things: 758 "Enhance the Security of the Internet of Things by Identifying 759 Enclaves: The security challenges posed by the emerging Internet 760 of Things should be addressed now, to prepare before it is fully 761 upon us. By identifying specific use segments, or enclaves, 762 Internet of Things infrastructure stakeholders can address the 763 security requirements and devise event remediations for that 764 enclave." 766 "Create a Framework for Managing Software Updates: The Internet of 767 Things will challenge our current channels for distributing 768 security updates. An environment must be developed for 769 distributing security patches that scales to a world where almost 770 everything is connected to the Internet and many things are 771 largely unattended." 773 Finally, we reiterate that use of standards that have gotten wide 774 review can often avoid a number of security issues that could 775 otherwise arise. Section 3.3 of [RFC6574] reminds us about the IETF 776 work style regarding security: 778 "In the development of smart object applications, as with any 779 other protocol application solution, security must be considered 780 early in the design process. As such, the recommendations 781 currently provided to IETF protocol architects, such as RFC 3552 782 [RFC3552], and RFC 4101 [RFC4101], apply also to the smart object 783 space." 785 In the IETF, security functionality is incorporated into each 786 protocol as appropriate, to deal with threats that are specific to 787 them. It is extremely unlikely that there is a one-size-fits-all 788 security solution given the large number of choices for the 'right' 789 protocol architecture (particularly at the application layer). For 790 this purpose, [RFC6272] offers a survey of IETF security mechanisms 791 instead of suggesting a preferred one. 793 7. Privacy Considerations 795 This document mainly focuses on an engineering audience, i.e., those 796 who are designing smart object protocols and architecture. Since 797 there is no value-free design, privacy-related decisions also have to 798 be made, even if they are just implicit in the re-use of certain 799 technologies. RFC 6973 [RFC6973] and the threat model in 800 [I-D.iab-privsec-confidentiality-threat] were written as guidance 801 specifically for that audience and are also applicable to the smart 802 object context. 804 For those looking at privacy from a deployment point of view, the 805 following additional guidelines are suggested: 807 Transparency: Transparency of data collection and processing is key 808 to avoid unpleasant surprises for owners and users of smart 809 objects. Users and impacted parties must be put in a position to 810 understand what items of personal data concerning them are 811 collected and stored, as well for what purposes they are sought. 813 Data Collection/Use Limitation: Smart objects should only store 814 personal data that is adequate, relevant and not excessive in 815 relation to the purpose(s) for which they are processed. The use 816 of anonymized data should be preferred wherever possible. 818 Data Access: Before deployment starts, it is necessary to consider 819 who can access personal data collected by smart objects and under 820 which conditions. Appropriate and clear procedures should be 821 established in order to allow data subjects to properly exercise 822 their rights. 824 Data Security: Standardized data security measures to prevent 825 unlawful access, alteration or loss of smart object data need to 826 be defined and deployed. Robust cryptographic techniques and 827 proper authentication frameworks have to be used to limit the risk 828 of unintended data transfers or unauthorized access. 830 A more detailed treatment of privacy considerations that extend 831 beyond engineering can be found in a publication from the Article 29 832 Working Party [WP223]. 834 8. IANA Considerations 836 This document does not require actions by IANA. 838 9. Acknowledgements 840 We would like to thank the participants of the IAB Smart Object 841 workshop for their input to the overall discussion about smart 842 objects. 844 Furthermore, we would like to thank Mike St. Johns, Jan Holler, 845 Patrick Wetterwald, Atte Lansisalmi, Hannu Flinck, Bernard Aboba, 846 Markku Tuohino, Wes George, Robert Sparks, S. Moonsesamy, Dave 847 Crocker, and Steve Crocker in particular for their review comments. 849 10. IAB Members at the Time of This Writing 851 Jari Arkko 852 Mary Barnes 853 Marc Blanchet 854 Joel Halpern 855 Ted Hardie 856 Joe Hildebrand 857 Russ Housley 858 Eliot Lear 859 Xing Li 860 Erik Nordmark 861 Andrew Sullivan 862 Dave Thaler 863 Brian Trammell 865 11. Informative References 867 [Gamma] Gamma, E., "Design Patterns: Elements of Reusable Object- 868 Oriented Software", 1995. 870 [HomeGateway] 871 Eggert, L., "An experimental study of home gateway 872 characteristics, In Proceedings of the '10th annual 873 conference on Internet measurement'", 2010. 875 [I-D.gilger-smart-object-security-workshop] 876 Gilger, J. and H. Tschofenig, "Report from the 'Smart 877 Object Security Workshop', March 23, 2012, Paris, France", 878 draft-gilger-smart-object-security-workshop-03 (work in 879 progress), September 2014. 881 [I-D.iab-privsec-confidentiality-threat] 882 Barnes, R., Schneier, B., Jennings, C., Hardie, T., 883 Trammell, B., Huitema, C., and D. Borkmann, 884 "Confidentiality in the Face of Pervasive Surveillance: A 885 Threat Model and Problem Statement", draft-iab-privsec- 886 confidentiality-threat-00 (work in progress), September 887 2014. 889 [IPoptions] 890 Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. 891 Stoica, "IP options are not an option, Technical Report 892 UCB/EECS", 2005. 894 [NSF] National Science Foundation, "Interdisciplinary Pathwards 895 towards a More Secure Internet: A report on the NSF- 896 sponsored Cybersecurity Ideas Lab held in Arlington, 897 Virginia on February 10-12, 2014", 2014. 899 [PhysicalAttacks] 900 Koeune, F. and F. Standaert, "A Tutorial on Physical 901 Security and Side-Channel Attacks, in Foundations of 902 Security Analysis and Design III: FOSAD 2004/2005 Tutorial 903 Lectures, Lecture Notes in Computer Science, vol 3655, pp 904 78-108", September 2005. 906 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 907 Harmful", RFC 1263, October 1991. 909 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 910 RFC 1958, June 1996. 912 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 913 Issues", RFC 3234, February 2002. 915 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 916 Considerations for Open Pluggable Edge Services", RFC 917 3238, January 2002. 919 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 920 Information Models and Data Models", RFC 3444, January 921 2003. 923 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 924 Text on Security Considerations", BCP 72, RFC 3552, July 925 2003. 927 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 928 and the Future of End-to-End: Reflections on the Evolution 929 of the Internet Architecture", RFC 3724, March 2004. 931 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 932 June 2005. 934 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 935 Transparency", RFC 4924, July 2007. 937 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 938 Protocol?", RFC 5218, July 2008. 940 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 941 Grid", RFC 6272, June 2011. 943 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 944 Security Version 1.2", RFC 6347, January 2012. 946 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 947 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 948 RFC 6540, April 2012. 950 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 951 Workshop", RFC 6574, April 2012. 953 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 954 Considerations for Protocol Extensions", RFC 6709, 955 September 2012. 957 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 958 6749, October 2012. 960 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 961 Morris, J., Hansen, M., and R. Smith, "Privacy 962 Considerations for Internet Protocols", RFC 6973, July 963 2013. 965 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 966 Constrained-Node Networks", RFC 7228, May 2014. 968 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 969 Application Protocol (CoAP)", RFC 7252, June 2014. 971 [TCPextensions] 972 Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and 973 H. Tokuda, "Is it Still Possible to Extend TCP? In Proc. 974 ACM Internet Measurement Conference (IMC), Berlin, 975 Germany", Nov 2011. 977 [Tussels] Clark, D., Wroslawski, J., Sollins, K., and R. Braden, 978 "Tussle in Cyberspace: Defining Tomorrow's Internet, In 979 Proc. ACM SIGCOMM", 2002. 981 [WP223] Article 29 Working Party, "Opinion 8/2014 on the on Recent 982 Developments on the Internet of Things", September 2014. 984 Authors' Addresses 986 Hannes Tschofenig 987 Austria 989 Email: Hannes.Tschofenig@gmx.net 990 URI: http://www.tschofenig.priv.at 992 Jari Arkko 993 Jorvas 02420 994 Finland 996 Email: jari.arkko@piuha.net 998 Dave Thaler 999 One Microsoft Way 1000 Redmond, WA 98052 1001 US 1003 Email: dthaler@microsoft.com 1005 Danny McPherson 1006 US 1008 Email: danny@tcb.net