idnits 2.17.1 draft-tschofenig-smart-object-architecture-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 : ---------------------------------------------------------------------------- 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 (December 28, 2012) is 4131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '21' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1018, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-iab-extension-recs-13 == Outdated reference: A later version (-10) exists of draft-jennings-senml-05 == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-02 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft J. Arkko 4 Intended status: Informational D. Thaler 5 Expires: July 1, 2013 D. McPherson 6 December 28, 2012 8 Architectural Considerations in Smart Object Networking 9 draft-tschofenig-smart-object-architecture-03.txt 11 Abstract 13 Following the theme "Everything that can be connected will be 14 connected", engineers and researchers designing smart object networks 15 need to decide how to achieve this in practice. How can different 16 forms of embedded and constrained devices be interconnected? How can 17 they employ and interact with the currently deployed Internet? This 18 memo discusses smart objects and some of the architectural choices 19 involved in designing smart object networks and protocols that they 20 use. 22 The document is being discussed at 23 https://www.ietf.org/mailman/listinfo/architecture-discuss 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 1, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Specific and General Purpose Solutions . . . . . . . . . . . . 5 61 3. Deployment Constraints in the Internet . . . . . . . . . . . . 7 62 4. The Need for Standards . . . . . . . . . . . . . . . . . . . . 9 63 4.1. Managing Complexity . . . . . . . . . . . . . . . . . . . 9 64 4.2. Interoperability Architecture . . . . . . . . . . . . . . 10 65 4.3. Internet Protocols for Proprietary Protocol 66 Developments . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 14 68 4.5. Design for Change . . . . . . . . . . . . . . . . . . . . 16 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18 71 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 74 10. Informative References . . . . . . . . . . . . . . . . . . . . 25 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 77 1. Introduction 79 In RFC 6574 [1], we refer to smart objects as devices with 80 constraints on energy, bandwidth, memory, size, cost, etc. This is a 81 fuzzy definition, as there is clearly a continuum in device 82 capabilities and there is no hard line to draw between devices that 83 can be classified as smart objects and those that can't. 85 Following the theme "Everything that can be connected will be 86 connected", engineers and researchers designing smart object networks 87 need to address a number of questions. How can different forms of 88 embedded and constrained devices be interconnected? How can they 89 employ and interact with the currently deployed Internet? 91 These questions have been discussed at length. For instance, when 92 the Internet Architecture Board (IAB) scheduled a workshop on Smart 93 Objects, the IETF community was asked to develop views on how 94 Internet protocols can be utilized by smart objects. A report of the 95 discussions and the position papers received for this workshop have 96 been published [1]. 98 This memo discusses smart objects and some of the architectural 99 choices involved in designing smart object networks and protocols 100 that they use. The main issues that we focus on are interaction with 101 the Internet, the use of Internet protocols for these applications, 102 models of interoperability, and approach to standardization. Many of 103 the issues discussed in this memo are common to any communications 104 system design or protocol development. However, given the high 105 interest for smart object networks, their somewhat specific 106 requirements, and commonly occurring requests for very different 107 communications tools prompted the IAB to discuss these issues in this 108 specific context. 110 In drawing conclusions from the prior IETF work and from the IAB 111 workshop it is useful to look back at the criteria for success of the 112 Internet. Various publications provide insight into the history, and 113 some of it is very much applicable to the discussion on smart 114 objects. RFC 1958 [2] says: 116 "The Internet and its architecture have grown in evolutionary 117 fashion from modest beginnings, rather than from a Grand Plan." 119 It goes on to add: 121 "A good analogy for the development of the Internet is that of 122 constantly renewing the individual streets and buildings of a 123 city, rather than razing the city and rebuilding it." 125 Internet protocols are immediately relevant for any smart object 126 development and deployment. However, building very small, often 127 battery-operated devices is challenging. It is difficult to resist 128 the temptation to build specific solutions tailored to a particular 129 application, or to re-design everything from scratch. Yet, due to 130 network effects, the case for using the Internet Protocol(s) and 131 other generic technology is compelling. 133 As technology keeps advancing, the constraints that the technology 134 places on devices evolve as well. Microelectronics become more 135 capable as time goes by, sometimes making it even possible for new 136 devices to be both less expensive and more capable than their 137 predecessors. This trend can, however, be in some cases offset by 138 the desire to embed communications technology in even smaller and 139 cheaper objects. But it is important to design communications 140 technology not just for today's constraints, but also tomorrow's. 142 This writeup describes the IAB's view on these issues. The document 143 is being discussed at 144 https://www.ietf.org/mailman/listinfo/architecture-discuss. 146 The rest of the document is organized as follows. Section 2 147 discusses the problems associated with vertically integrated 148 industry-specific solutions, and suggests the use of generic 149 technologies and a more flexible architecture as a way to reduce 150 these problems. Section 3 discusses the problems associated with 151 attempting to use options and communication patterns other than those 152 in current widespread use in the Internet. Often middleboxes and 153 assumptions built into existing devices makes such usage problematic. 154 Section 4 discusses different levels of interoperability, and the 155 different level of effort required to achieve them. Finally, 156 Section 5 presents some of the relevant security issues, Section 6 157 discusses privacy, and Section 7 summarizes the recommendations. 159 2. Specific and General Purpose Solutions 161 The Internet protocols are relevant for any smart object development 162 and deployment. In the context of one use case of smart objects, the 163 smart grid and smart meters in particular, RFC 6272 "Internet 164 Protocols for the Smart Grid" [3] identifies a range of IETF 165 protocols that can be utilized. 167 Of course, there are also many protocols that are unlikely to be 168 needed or even suitable for the smart object environments. For 169 instance, it would difficult to imagine inter-domain routing being a 170 necessary feature in these objects; there are other devices in the 171 network that would normall be responsible for this functionality. 172 But the wide range of protocols listed in RFC 6272 illustrates the 173 view of the IAB about how a large fraction of the Internet technology 174 can be readily used in these new applications. Many commercial 175 products employ proprietary or industry-specific protocol mechanisms 176 that do not accommodate direct Internet connectivity. Researchers 177 have made several attempts to design new types of architectures for 178 the entire Internet system. But by and large the industry has 179 understood the value of using Internet communications for various 180 smart object deployments. 182 Nevertheless, there are several architectural concerns that deserve 183 to be highlighted. 185 Vertically Specified Profiles 187 The discussions at the IAB workshop (see Section 3.1.2 of [1]) 188 revealed the preference of many participants to develop domain 189 specific profiles that select a minimum subset of protocols needed 190 for a specific operating environment. Various standardization 191 organizations and industry fora are currently engaged in 192 activities of defining their preferred profile(s). Ultimately, 193 however, the number of domains where smart objects can be used is 194 essentially unbounded. There is also an ever-evolving set of 195 protocols and protocol extensions. Profiles, particularly, full- 196 stack profiles are common, for instance, in areas where existing 197 legacy technology is being migrated to IP. 199 However, merely changing the networking protocol to IP does not 200 necessarily bring the kinds of benefits that industries are 201 looking for in their evolving smart object deployments. In 202 particular, a profile is rigid, and leaves little room for 203 interoperability among slightly differing, or competing technology 204 variations. As an example, layer 1 through 7 type profiles do not 205 account for the possibility that some devices may use other 206 physical media than others, and that in such situations a simple 207 router could still provide an ability to communicate between the 208 parties. 210 Industry-Specific Solutions 212 The Internet Protocol suite is more extensive than merely the use 213 of IP. Often significant benefits can be gained from using 214 additional, widely available, generic technologies such as web 215 services. Benefits from using these kinds of tools include access 216 to large available workforce, software, and education already 217 geared towards employing the technology. 219 Tight Coupling 221 Many applications are built around a specific set of servers, 222 devices, and users. However, often the same data and devices 223 could be useful for many purposes, some of which may not be easily 224 identifiable at the time that the devices are deployed. 226 As a result, the following recommendations can be made. First, while 227 there are some cases where specific solutions are needed, the 228 benefits of general-purpose technology are often compelling, be it 229 about choosing IP over some more specific communication mechanism, a 230 widely deployed link layer (such as wireless LAN) over a more 231 specific one, web technology over application specific protocols, and 232 so on. 234 However, when employing these technologies it is important to embrace 235 them in their entirety, allowing for the architectural flexibility 236 that is built onto them. As an example, it rarely makes sense to 237 limit communications on-link or to specific media. We should also 238 design our applications so that the participating devices can easily 239 interact with multiple other applications. 241 3. Deployment Constraints in the Internet 243 Despite the applicability of the Internet Protocols for smart 244 objects, picking the specific protocols for a particular use case can 245 be tricky. As the Internet has evolved over time, certain protocols 246 and protocol extensions have become the norm and others have become 247 difficult to use in all circumstances. 249 Taking into account these constraints is particularly important for 250 smart objects, as there is often a desire to employ specific features 251 to support smart object communication. For instance, from a pure 252 protocol specifications perspective some transport protocols may be 253 more desirable than others. These constraints apply both to the use 254 of existing protocols as well as designing new ones on top of the 255 Internet Protocol stack. 257 The following list illustrates a few of those constraints, but every 258 communication protocol comes with its own challenges. 260 In 2005, [4] studied the usage of IP options-enabled packets in 261 the Internet and found that overall, approximately half of 262 Internet paths drop packets with options, making extensions using 263 IP options "less ideal" for extending IP. 265 In 2010, [5] tested 34 different home gateways regarding their 266 packet dropping policy of UDP, TCP, DCCP, SCTP, ICMP, and various 267 timeout behavior. For example, more than half of the tested 268 devices do not conform to the IETF recommended timeouts for UDP, 269 and for TCP the measured timeouts are highly variable, ranging 270 from less than 4 minutes to longer than 25 hours. For NAT 271 traversal of DCCP and SCTP, the situation is poor. None of the 272 tested devices, for example, allowed establishing a DCCP 273 connection. 275 In 2011, [6] tested the behavior of networks with regard to 276 various TCP extensions: "From our results we conclude the 277 middleboxes implementing layer 4 functionality are very common -- 278 at least 25% of paths interfered with TCP in some way beyond basic 279 firewalling." 281 Extending protocols to fulfill new uses and to add new functionality 282 may range from very easy to difficult, as [7] investigates in great 283 detail. A challenge many protocol designers are facing is to ensure 284 incremental deployability and interoperability with incumbent 285 elements in a number of areas. In various cases, the effort it takes 286 to design incrementally deployable protocols has not been taken 287 seriously enough at the outset. RFC 5218 on "What Makes For a 288 Successful Protocol?" [8] defines the ultimate goal to develop 289 protocols that are deployed beyond their envisioned use cases. 291 As these examples illustrate, protocol architects have to take 292 developments in the greater Internet into account, as not all 293 features can be expected to be usable in all environments. For 294 instance, middleboxes [9] complicate the use of extensions in the 295 basic IP protocols and transport layers. 297 RFC 1958 [2] considers this aspect and says "... the community 298 believes that the goal is connectivity, the tool is the Internet 299 Protocol, and the intelligence is end to end rather than hidden in 300 the network." This statement is challenged more than ever with the 301 perceived need to develop clever intermediaries interacting with dumb 302 end devices but we have to keep in mind what RFC 3724 [10] has to say 303 about this crucial aspect: "One desirable consequence of the end-to- 304 end principle is protection of innovation. Requiring modification in 305 the network in order to deploy new services is still typically more 306 difficult than modifying end nodes." RFC 4924 [11] adds that a 307 network that does not filter or transform the data that it carries 308 may be said to be "transparent" or "oblivious" to the content of 309 packets. Networks that provide oblivious transport enable the 310 deployment of new services without requiring changes to the core. It 311 is this flexibility that is perhaps both the Internet's most 312 essential characteristic as well as one of the most important 313 contributors to its success. 315 4. The Need for Standards 317 New smart object applications are developed every day; in many cases 318 they are created using standardized Internet technology. Even where 319 a common underlying technology (such as IP) is used, current smart 320 object networks often have challenges related to interoperability of 321 the entire protocol stack, including application behavior. One 322 symptom of such challenges is that various components cannot easily 323 be replaced by third party components. It is of strategic importance 324 to make a conscious decision about the desired level of 325 interoperability and where the points of interconnection are. 327 4.1. Managing Complexity 329 These decisions also relate to the required effort to complete the 330 application, and overall complexity of the system. A system may 331 appear complex for variety of reasons. First, there is legitimate 332 heterogeneity in the used networking technology and applications. 333 This variation is necessary and useful, as for instance different 334 applications and environments benefit from varying networking 335 technology. The range and other characteristics of cellular, 336 wireless local area networking, and RFID are very different from each 337 other, for instance. There are literally thousands of different 338 applications, and it is natural that they have differing requirements 339 on what parties need to communicate with each other, what kind of 340 security solutions are appropriate, and other aspects. 342 The answer to managing complexity in the face of this lies in layers 343 of communication mechanisms and keeping the layers independent, e.g., 344 in the form of the hourglass model. If there is a common waist of 345 the hourglass, then all applications can work over all physical 346 networking technology, ensuring widest possible coverage of 347 networking applications. "Everything over IP and IP over 348 everything." This model provides some guidance for thinking about 349 the Internet of Things architecture. First of all, it shows how we 350 need common internetworking infrastructure (IP) to allow 351 heterogeneous link media to work seamlessly with each other, and with 352 the rest of the system. Secondly, there are various transport and 353 middleware communications mechanisms that will likely become useful 354 in the different applications. For instance, today embedded web 355 services (HTTP, COAP, XML, and JSON) appear to be popular, regardless 356 of what specific link technology they are run over. 358 But there can also be undesirable complexity and variation. Creation 359 of alternative standards where one would have sufficed may be 360 harmful. Creating systems and communications mechanisms with 361 unnecessary dependencies between different layers and system 362 components limits our ability to migrate systems to the most economic 363 and efficient platforms, and limits our ability to connect as many 364 objects as possible. 366 To summarize, complexity and alternative technologies can be very 367 useful as a part of architecture, or can be problematic when it 368 creates unnecessary competition and deployment barriers in the market 369 place. In an optimal situation, complexity will be addressed by 370 regular technological evolution in the industry through underlying 371 layering and modular architecture. 373 4.2. Interoperability Architecture 375 It is also valuable to look back at earlier IETF publications, for 376 example, RFC 1263 [12] considers different protocol design strategies 377 and makes an interesting observation about the decision to design new 378 protocols from scratch or to design them in a non-backwards 379 compatible way based on existing protocols: 381 "We hope to be able to design and distribute protocols in less 382 time than it takes a standards committee to agree on an acceptable 383 meeting time. This is inevitable because the basic problem with 384 networking is the standardization process. Over the last several 385 years, there has been a push in the research community for 386 lightweight protocols, when in fact what is needed are lightweight 387 standards. Also note that we have not proposed to implement some 388 entirely new set of 'superior' communications protocols, we have 389 simply proposed a system for making necessary changes to the 390 existing protocol suites fast enough to keep up with the 391 underlying change in the network. In fact, the first standards 392 organization that realizes that the primary impediment to 393 standardization is poor logistical support will probably win." 395 While [12] was written in 1991 when the standardization process in 396 the Internet community was far more lightweight than today (among 397 other reasons, because fewer stakeholders were interested in 398 participating in the standards process) it is remarkable to read 399 these thoughts since they are even more relevant today. This is 400 particularly true for the smart object environment. 402 Regardless of how hard we work on optimizing the standard process, 403 designing systems in an open and transparent consensus process where 404 many parties participate takes longer than letting individual 405 stakeholders develop their own proprietary solutions. Therefore, it 406 is important to make architectural decisions that keep a good balance 407 between proprietary developments vs. standardized components. 409 While RFC 1263 [12] certainly provides good food for thought, it also 410 gives recommendations that may not always be appropriate for the 411 smart object space, such as the preference for a so-called 412 evolutionary protocol design where new versions of the protocols are 413 allowed to be non-backwards compatible and all run independently on 414 the same device. RFC 1263 adds: 416 "... the only real disadvantage of protocol evolution is the 417 amount of memory required to run several versions of the same 418 protocol. Fortunately, memory is not the scarcest resource in 419 modern workstations (it may, however, be at a premium in the BSD 420 kernel and its derivatives). Since old versions may rarely if 421 ever be executed, the old versions can be swapped out to disk with 422 little performance loss. Finally, since this cost is explicit, 423 there is a huge incentive to eliminate old protocol versions from 424 the network." 426 Even though it is common practice today to run many different 427 software applications that have similar functionality (for example, 428 multiple Instant Messaging clients) in parallel it may indeed not be 429 the most preferred approach for smart objects, which may have severe 430 limitations regarding RAM, flash memory, and also power constraints. 432 To deal with exactly this problem, profiles have been suggested in 433 many cases. Saying "no" to a new protocol stack that only differs in 434 minor ways may be appropriate but could be interpreted as blocking 435 innovation and, as RFC 1263 [12] describes it nicely "In the long 436 term, we envision protocols being designed on an application by 437 application basis, without the need for central approval.". "Central 438 approval" here refers to the approval process that happens in a 439 respective standards developing organization. 441 So, how can we embrace rapid innovation with distributed developments 442 and at the same time accomplish a high level of interoperability? 444 Clearly, standardization of every domain-specific profile will not be 445 the solution. Many domain-specific profiles are optimizations that 446 will be already obsoleted by technological developments (e.g., new 447 protocol developments), new security threats, new stakeholders 448 entering the system or changing needs of existing stakeholders, new 449 business models, changed usage patterns, etc. RFC 1263 [12] states 450 the problem succinctly: "The most important conclusion of this RFC is 451 that protocol change happens and is currently happening at a very 452 respectable clip. We simply propose to explicitly deal with the 453 changes rather keep trying to hold back the flood." 455 Even worse, different stakeholders that are part of the Internet 456 milieu have interests that may be adverse to each other, and these 457 parties each vie to favor their particular interests. In [13], 458 Clark, et al. call this process 'the tussle' and ask the important 459 question "How can we, as designers, build systems with desired 460 characteristics and improve the chances that they come out the way we 461 want?". In an attempt to answer that question, the authors of [13] 462 develop a high-level principle, which is not tailored to smart object 463 designs but to Internet protocol develop in general: 465 "Design for variation in outcome, so that the outcome can be 466 different in different places, and the tussle takes place within 467 the design, not by distorting or violating it. Do not design so 468 as to dictate the outcome. Rigid designs will be broken; designs 469 that permit variation will flex under pressure and survive." 471 In order to accomplish this, Clark, et al. suggest to 473 1. Break complex systems into modular parts. 475 2. Design for choice. 477 These are valid guidelines, and many protocols standardized in the 478 IETF have taken exactly this approach, namely to identify building 479 blocks that can be used in a wide variety of deployments. Others 480 then put the building blocks together in a way that suits their 481 needs. There are, however, limits to this approach. Certain 482 building blocks are only useful in a limited set of architectural 483 variants and producing generic building blocks requires a good 484 understanding of the different architectural variants and often 485 limits the ability to optimize. Sometimes the value of an individual 486 building block is hard for others to understand without providing the 487 larger context, which requires at least to illustrate one deployment 488 variant that comes with a specific architectural setup. That said, 489 it is also critical to consider systemic interdependencies between 490 the set of elements that constitute a system, lest they impose 491 constraints that weren't envisioned at the outset. 493 Since many Internet protocols are used as building blocks by other 494 organizations or in deployments that may have never been envisioned 495 by the original designs, one can argue that this approach has been 496 fairly successful. It may, however, not lead to the level of 497 interoperability many desire: they want interoperability of the 498 entire system rather than interoperability at a specific protocol 499 level. Consequently, an important architectural question arises, 500 namely "What level of interoperability should Internet protocol 501 engineers aim for?" 503 In the diagrams below, we illustrate a few interoperability scenarios 504 with different interoperability needs. Note that these are highly 505 simplified versions of what protocol architects are facing, since 506 there are often more parties involved in a sequence of required 507 protocol exchanges, and the entire protocol stack has to be 508 considered - not just a single protocol layer. As such, the required 509 coordination and agreement between the different stakeholders is 510 likely to be far more challenging than illustrated. We do, however, 511 believe that these figures illustrate that the desired level of 512 interoperability needs to be carefully chosen. 514 4.3. Internet Protocols for Proprietary Protocol Developments 516 Figure 1 shows a typical deployment of many Internet applications. 517 Here an application service provider (example.com in our 518 illustration) wants to make an HTTP-based protocol interface 519 available to its customers. Example.com allows their customers to 520 upload sensor measurements using a RESTful HTTP design. Customers 521 need to write code for their embedded systems to make use of the 522 HTTP-based protocol interface (and keying material for authentication 523 and authorization of the uploaded data). These applications work 524 with the servers operated by Example.com and with nobody else. There 525 is no interoperability with third parties (at the application layer 526 at least). For instance, Alice, a customer of Example.com, cannot 527 use their embedded system which was programmed to use the protocol 528 interface for Example.com with another service provider without re- 529 writing at least parts of her embedded software. Nevertheless, 530 Example.com use standardized protocol components to allow for 531 communication across the Internet and for speeding-up the process of 532 software development. This is certainly useful from a time-to-market 533 and cost efficiency point of view. For example, Example.com could 534 rely on HTTP, offer JSON to encode sensor data, and use IP to allow 535 various nodes to communicate with each other. 537 ................. 538 | Application | 539 | Service | 540 | Provider | 541 | Example.com | 542 |_______________| 543 _, . 544 ,' `. Proprietary 545 _,' `. Protocol offered 546 ,' `._ by Example.com 547 -' - 548 ,'''''''''''''| ,''''''''| Sensors 549 | Temperature | | Light | operated by 550 | Sensor | | Sensor | customers of 551 |.............' |........' Example.com 552 Figure 1: Proprietary Deployment 554 Clearly, the above scenario does not provide a lot of 555 interoperability even though standardized Internet protocols are 556 used. 558 Figure 2 shows another scenario. Here Example.com is focused on 559 storage of sensor data and not on the actually processing it offers 560 an HTTP-based protocol interface to others to get access to the 561 uploaded sensor data. In our example, b-example.com and 562 c-example.com are two of such companies that make use of this 563 functionality in order to provide data visualization and data mining 564 computations. Example.com again uses standardized protocols (such as 565 RESTful HTTP design combined with OAuth) for offering access but 566 overall the entire protocol stack is not standardized. 568 ................. 569 | Application | 570 .| Service | 571 ,-` | Provider | 572 .` | b-example.com | 573 ,-` |_______________| 574 .` 575 ................. ,-` 576 | Application |-` Proprietary 577 | Service | Protocol 578 | Provider | 579 | example.com |-, 580 |_______________| '. 581 _, `', 582 Proprietary ,' '. ... 583 Protocol _,' `', ................. 584 ,' '. | Application | 585 -' `'| Service | 586 ,''''''''| | Provider | 587 | Light | | c-example.com | 588 | Sensor | |_______________| 589 |........' 591 Figure 2: Backend Interworking 593 4.4. Interoperability 595 In contrast to the scenario described in Section 4.3, Figure 3 596 illustrates a sensor where two devices developed by independent 597 manufacturers are desired to interwork. This is shown in Figure 3. 599 To pick an example from [1], consider a light bulb that talks to a 600 light switch with the requirement that each may be manufactured by a 601 different company, represented as company A and B. 603 _,,,, ,,,, 604 / -'`` \ 605 | | 606 \ | 607 / \ 608 ,''''''''| / Standardized . ,''''''''| 609 | Light | ------|---Protocol-------\------| Light | 610 | Bulb | . | | Switch | 611 |........' `'- / |........' 612 \ _-...-` 613 Manufacturer `. ,.' Manufacturer 614 A ` B 616 Figure 3: Interoperability between two independent devices 618 In order for this scenario to work manufacturer A, B, and probably 619 many other manufacturers f lightbulbs and light switches need to get 620 together and agree on the protocol stack they would like to use. Let 621 us assume that they do not want any manual configuration by the user 622 to happen and that these devices should work in a typical home 623 network this consortium needs to make a decision about the following 624 protocol design aspects: 626 o Which physical layer should be supported? 628 o Which IP version should be used? 630 o Which IP address configuration mechanism(s) are integrated into 631 the device? 633 o Which communication architecture shall be supported? (see [14]; 634 Arkko, et al. explain how the complexity of an application heavily 635 depends on the chosen communication architecture and discusses an 636 application with limited communication capabilities, which also 637 translates into low energy consumption. ) 639 o Whether there is a need for a service discovery mechanism to allow 640 users to discover light bulbs they have in their home or office. 642 o Which transport layer protocol is used for conveying the sensor 643 readings/sensor commands? (e.g., UDP) 645 o Which application layer protocol is used? (for example, CoAP) 647 o How are requests encoded? (e.g., as URIs) How is the return data 648 encoded? (e.g., JSON) 650 o What data model is used for expressing the different light levels? 651 (e.g., [15]) 653 o Finally, some thoughts will have to be spent about the security 654 architecture. This includes questions like: what are the 655 ssecurity threats? What security services need to be provided to 656 deal with the identified threats? Where do the security 657 credentials come from? At what layer(s) in the protocol stack 658 should the security mechanism reside? 660 This list is not meant to be exhaustive but aims to illustrate that 661 for every usage scenario many design decisions will have to be made 662 in order to accommodate the constrained nature of a specific device 663 in a certain usage scenario. Standardizing such a complete solution 664 to accomplish a full level of interoperability between two devices 665 manufactured by different vendors will take time. 667 4.5. Design for Change 669 With the description in Section 4.3 and in Section 4.4 we present two 670 extreme cases of interoperability. To "design for varation in 671 outcome", as postulated by [13], the design of the system does not 672 need to be cast in stone during the standardization process but may 673 be changed during run-time using software updates. 675 For many reasons, not only for adding new functionality, it can be 676 said that many smart objects will need a solid software update 677 mechanism. Note that adding new functionality to smart objects may 678 not be possible for certain classes of constrained devices, namely 679 those with severe memory limitations. As such, a certain level of 680 sophistication from the embedded device is assumed in this section. 682 Software updates are common in operating systems and application 683 programs today. Arguably, the Web today employs a very successful 684 software update mechanism with code being provided by many different 685 parties (i.e., by websites loaded into the browser or by the Web 686 application). While JavaScript (or the proposed successor, Dart) may 687 not be the right choice of software distribution for smart objects, 688 and other languages such as embedded eLua [16] may be more 689 appropriate, the basic idea of offering software distribution 690 mechanisms may present a middleground between the two extreme 691 interoperability scenario presented in this section. 693 5. Security Considerations 695 Section 3.3 of [1] reminds us about the IETF workstyle regarding 696 security: 698 In the development of smart object applications, as with any other 699 protocol application solution, security must be considered early 700 in the design process. As such, the recommendations currently 701 provided to IETF protocol architects, such as RFC 3552 [17], and 702 RFC 4101 [18], apply also to the smart object space. 704 In the IETF, security functionality is incorporated into each 705 protocol as appropriate, to deal with threats that are specific to 706 them. It is extremely unlikely that there is a one-size-fits-all 707 security solution given the large number of choices for the 'right' 708 protocol architecture (particularly at the application layer). For 709 this purpose, [3] offers a survey of IETF security mechanisms instead 710 of suggesting a preferred one. 712 A more detailed security discussion can be found in the report from 713 the 'Smart Object Security' workshop. that was held prior to the IETF 714 meeting in Paris, March 2012. [[Comment.1: The workshop report has 715 not been published yet. It will happen soon.]] 717 6. Privacy Considerations 719 In 1980, the Organization for Economic Co-operation and Development 720 (OECD) published eight Guidelines on the Protection of Privacy and 721 Trans-Border Flows of Personal Data [19], which are often referred to 722 as Fair Information Practices (FIPs). The FIPs, like other privacy 723 principles, are abstract in their nature and have to be applied to a 724 specific context. 726 From a technical point of view, many smart object designs are not 727 radically different from other application design. Often, however, 728 the lack of a classical user interface, such as is used on a PC or a 729 phone, that allows users to interact with the devices in a convenient 730 and familiar way creates problems to provide users with information 731 about the data collection, and to offer them the ability to express 732 consent. Furthermore, in some verticals (e.g., smart meter 733 deployments) users are not presented with the choice of voluntarily 734 signing up for the service but deployments are instead mandated 735 through regulation. Therefore, these users have no right to consent; 736 a right that is core to many privacy principles including the FIPs. 737 In other cases, the design is more focused on dealing with privacy at 738 the level of a privacy notice rather than by building privacy into 739 the design of the system, which [20] asks engineers to do. 741 Similarly, in many applications smart objects technology is deployed 742 by someone other than the potentially impacted parties. For 743 instance, manufacturers and shops deploy RFID tags in products or 744 governments deploy roadside sensors. In these applications the 745 impacted parties, such as a shopper or car-owner may not even be 746 aware that such technology is used, and information about about the 747 impacted party may be collected. 749 The interoperability models described in this document highlight that 750 standardized interfaces are not needed in all cases, nor that this is 751 even desirable. Depending on the choice of certain underlying 752 technologies, various privacy problems may be inherited by the upper- 753 layer protocols and therefore difficult to resolve as an 754 afterthought. Many smart objects leave users little ability for 755 enabling privacy-improving configuration changes. Technologies exist 756 that can be applied also to smart objects to involve users in 757 authorization decisions before data sharing takes place. 759 As a summary, for an Internet protocol architect, the guidelines 760 described in [20] are applicable. For those looking at privacy from 761 a deployment point of view, the following additional guidelines are 762 suggested: 764 Transparency: The data processing should be completely transparent 765 to the smart object owner, users, and possibly impacted parties. 766 Users and impacted parties must, except in rare exceptional cases, 767 be put in a position to easily understand what items of personal 768 information concerning them are collected and stored, as well for 769 what purposes they are sought. 771 Data Quality: Smart objects should only store personal data which 772 are adequate, relevant and not excessive in relation to the 773 purpose(s) for which they are processed. The use of anonymised 774 data should be preferred wherever possible. 776 Data Access: Before deployment starts, it is necessary to consider 777 who can access the personal data recorded in smart objects and 778 under which conditions, particularly with regard to data subjects, 779 to whom (in principle) full and free access to his/her own data 780 should be recognised. Appropriate and clear procedures should be 781 established in order to allow data subjects to properly exercise 782 their rights. A privacy and data protection impact assessment is 783 considered a useful tool for this analysis. 785 Data Security: Standardized data security measures to prevent 786 unlawful access, alteration or loss of smart object data need to 787 be defined and universally adopted. Robust cryptographic 788 techniques and proper authentication frameworks should be used to 789 limit the risk of unintended data transfers or harmful attacks. 790 The end-user and impacted parties should be able to verify, in a 791 straight-forward manner, that smart objects are in full compliance 792 with these standards. 794 7. Summary 796 Interconnecting smart objects with the Internet creates exciting new 797 use cases and engineers are eager to play with small and constrained 798 devices. With various standardization efforts ongoing and the 799 impression that smart objects require a new Internet Protocol and 800 many new extensions, we would like to provide a cautious warning. We 801 believe that protocol architects are best served by the following 802 high level guidance: 804 Use Internet protocols 806 Most, if not all, smart object deployments should employ the 807 Internet protocol suite. The Internet protocols can be applied to 808 almost any environment, and the rest of the suite can be tailored 809 for the specific needs. 811 The deployed Internet matters 813 When connecting smart objects to the Internet, take existing 814 deployment into consideration to avoid unpleasant surprises. 815 Assuming an ideal, clean-slate deployments is, in many cases, far 816 too opimistic since already available deployed infrastructure is 817 sticky. 819 Decide about the level of interoperability 821 Offering interoperability between every entity in an architecture 822 may be an ideal situation for a standards person but comes with a 823 certain cost. As such, starting with a less ambigious 824 standardization goal may be appropriate, particularly for early 825 deployments. 827 Don't optimize too early 829 The constrained nature of smart objects invites engineers to 830 invent each and every technique to optimize protocols for special 831 use cases. While some of these optimizations may be necessary, 832 many of them make the overal design complex and the outcome less 833 usable for the generic use case. 835 This memo provides also some additional, more detailed suggestions 836 for different audiences. The following recommendations are for the 837 designers of smart object systems: 839 o Even in the smart object space, try to aim for a generic design 840 instead of optimizing too early. Note that some optimizations 841 will only be possible in an architectural context, rather than at 842 the level of an individual protocol. 844 o We encourage engineers to take existing deployment constraints 845 into consideration to allow for a smooth transition path. This 846 requires a clear understanding of the deployment status and also 847 an analysis of the incentives of the different stakeholders. 849 Over time, a wide range of middleboxes have been introduced to 850 the Internet protocol suite. Introducing middleboxes in smart 851 object deployments has been proposed many times but their usage 852 may turn out to be dangerous. We recommend carefully 853 investigaing whether new features introduced can be supported 854 without any change to middleboxes. This investigation will 855 likely have to go beyond pure specification work, and may 856 require extensive interoperability testing and a clearly 857 articulated extensiblity story. The guidance in [7] is 858 relevant to this discussion. The added architectural 859 complexity, including security and privacy challenges, has to 860 be a subject of design considerations. Middleboxes are often 861 operated by parties other than the communication endpoints. As 862 such, they introduce additional stakeholders into the 863 architecture that often want to be involved when new features 864 are introduced and as such may slow down the ability to 865 innovate at a high speed. 867 o The application space has historically seen faster innovation 868 cycles, and separating network-layer from application-layer 869 functionality is therefore recommended. In general, we suggest 870 avoiding standardizing complete protocol stacks. The likelihood 871 that those will be outdated by the time standardization is 872 finished is far too high, particularly with application-layer 873 standards. 875 o Consider what type of interoperability model is appropriate for 876 the task at hand. An architecture that requires fewer 877 interoperability components often has a faster time to market. 878 Selecting what interfaces are open for interworking between 879 components from different operators and vendors is very important. 881 These recommendations are for the designers of new protocols or 882 protocol extensions in IETF or elsewhere: 884 o The Internet Protocol stack has a number of building blocks that 885 have proven useful for many applications. We encourage continuing 886 the development of building blocks that are usable in a number of 887 deployment scenarios. 889 For the development of new components, the recommendations in [1] 890 provide a good starting point. We do, however, encourage protocol 891 engineers to document the interworking of various protocols in at 892 least one architectural variant to ensure that the individual 893 parts indeed fit together without creating gaps or conflicts. 895 For researchers we offer the following suggestions: 897 o We believe that the area of mobile code distribution provides a 898 promising way to solve a range of security problems and the 899 ability to deliver new functionality. The rich experience from 900 the Web environment can be taken into consideration as a starting 901 point. 903 o We encourage funding of software projects that produce libraries 904 and open source code for operating systems, basic IP protocol 905 stacks, and web tools suitable for small, autonomously operating 906 devices. The success of many IETF protocols can be attributed to 907 the availability of running code. 909 o We also propose to conduct ongoing research of the deployment 910 status of various Internet protocols. These investigations 911 provide a snapshot for further interactions with the operator 912 community to ensure that IETF protocols can indeed be deployed in 913 today's Internet and may stimulate discussions on how to deal with 914 unpleasant deployment artifacts. 916 8. IANA Considerations 918 This document does not require actions by IANA. 920 9. Acknowledgements 922 We would like to thank the participants of the IAB Smart Object 923 workshop for their input to the overall discussion about smart 924 objects. 926 Furthermore, we would like to thank Jan Holler, Patrick Wetterwald, 927 Atte Lansisalmi, Hannu Flinck, Joel Halpern, Markku Tuohino, and the 928 IAB for their review comments. 930 10. Informative References 932 [1] Tschofenig, H. and J. Arkko, "Report from the Smart Object 933 Workshop", RFC 6574, April 2012. 935 [2] Carpenter, B., "Architectural Principles of the Internet", 936 RFC 1958, June 1996. 938 [3] Baker, F. and D. Meyer, "Internet Protocols for the Smart 939 Grid", RFC 6272, June 2011. 941 [4] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica, 942 "IP options are not an option, Technical Report UCB/EECS", 943 2005. 945 [5] Eggert, L., "An experimental study of home gateway 946 characteristics, In Proceedings of the '10th annual conference 947 on Internet measurement'", 2010. 949 [6] Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and H. 950 Tokuda, "Is it Still Possible to Extend TCP? In Proc. ACM 951 Internet Measurement Conference (IMC), Berlin, Germany", 952 Nov 2011. 954 [7] Carpenter, B., Aboba, B., and S. Cheshire, "Design 955 Considerations for Protocol Extensions", 956 draft-iab-extension-recs-13 (work in progress), June 2012. 958 [8] Thaler, D. and B. Aboba, "What Makes For a Successful 959 Protocol?", RFC 5218, July 2008. 961 [9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 962 RFC 3234, February 2002. 964 [10] Kempf, J., Austein, R., and IAB, "The Rise of the Middle and 965 the Future of End-to-End: Reflections on the Evolution of the 966 Internet Architecture", RFC 3724, March 2004. 968 [11] Aboba, B. and E. Davies, "Reflections on Internet 969 Transparency", RFC 4924, July 2007. 971 [12] O'Malley, S. and L. Peterson, "TCP Extensions Considered 972 Harmful", RFC 1263, October 1991. 974 [13] Clark, D., Wroslawski, J., Sollins, K., and R. Braden, "Tussle 975 in Cyberspace: Defining Tomorrow's Internet, In Proc. ACM 976 SIGCOMM", 2002. 978 [14] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, 979 "Implementing Tiny COAP Sensors", 980 draft-arkko-core-sleepy-sensors-01 (work in progress), 981 July 2011. 983 [15] Jennings, C., "Media Type for Sensor Markup Language (SENML)", 984 draft-jennings-senml-05 (work in progress), March 2011. 986 [16] "Embedded Lua Project", 2012. 988 [17] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 989 Security Considerations", BCP 72, RFC 3552, July 2003. 991 [18] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 992 June 2005. 994 [19] Organization for Economic Co-operation and Development, "OECD 995 Guidelines on the Protection of Privacy and Transborder Flows 996 of Personal Data", available at (September 2010) , http:// 997 www.oecd.org/EN/document/ 998 0,,EN-document-0-nodirectorate-no-24-10255-0,00.html, 1980. 1000 [20] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and J. 1001 Morris, "Privacy Considerations for Internet Protocols", 1002 draft-iab-privacy-considerations-02 (work in progress), 1003 March 2012. 1005 [21] Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 1006 "Trends in Web Applications and the Implications on 1007 Standardization", draft-tschofenig-post-standardization-02 1008 (work in progress), May 2012. 1010 [22] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained 1011 Application Protocol (CoAP)", draft-ietf-core-coap-09 (work in 1012 progress), March 2012. 1014 [23] Bormann, C., "Guidance for Light-Weight Implementations of the 1015 Internet Protocol Suite", draft-bormann-lwig-guidance-01 (work 1016 in progress), January 2012. 1018 [24] Rosenberg, J., "UDP and TCP as the New Waist of the Internet 1019 Hourglass", draft-rosenberg-internet-waist-hourglass-00 (work 1020 in progress), February 2008. 1022 Authors' Addresses 1024 Hannes Tschofenig 1025 Linnoitustie 6 1026 Espoo 02600 1027 Finland 1029 Phone: +358 (50) 4871445 1030 Email: Hannes.Tschofenig@gmx.net 1031 URI: http://www.tschofenig.priv.at 1033 Jari Arkko 1034 Jorvas 02420 1035 Finland 1037 Email: jari.arkko@piuha.net 1039 Dave Thaler 1040 US 1042 Email: dthaler@microsoft.com 1044 Danny McPherson 1045 US 1047 Email: danny@tcb.net