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