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