idnits 2.17.1 draft-iab-smart-object-workshop-00.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 (July 4, 2011) is 4678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2222' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 995, but no explicit reference was found in the text == Unused Reference: 'RFC5582' is defined on line 1009, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-01) exists of draft-jennings-energy-pricing-00 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational J. Arkko 5 Expires: January 5, 2012 Ericsson 6 July 4, 2011 8 Report from the 'Interconnecting Smart Objects with the Internet' 9 Workshop, 25th March 2011, Prague 10 draft-iab-smart-object-workshop-00.txt 12 Abstract 14 This document provides an overview of a workshop held by the Internet 15 Architecture Board (IAB) on 'Interconnecting Smart Objects with the 16 Internet'. The workshop took place in Prague on March, 25th. The 17 main goal of the workshop was to solicit feedback from the wider 18 community on their experience with deploying IETF protocols in 19 constrained environments. This report summarizes the discussions and 20 lists the conclusions and recommendations to the Internet Engineering 21 Task Force (IETF) community. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 5, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 6 59 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 8 62 3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 9 63 3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10 64 3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 71 8. Informative References . . . . . . . . . . . . . . . . . . . . 25 72 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29 73 Appendix B. Published Workshop Material . . . . . . . . . . . . . 30 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 76 1. Introduction 78 The Internet Architecture Board (IAB) holds occasional workshops 79 designed to consider long-term issues and strategies for the 80 Internet, and to suggest future directions for the Internet 81 architecture. This long-term planning function of the IAB is 82 complementary to the ongoing engineering efforts performed by working 83 groups of the Internet Engineering Task Force (IETF), under the 84 leadership of the Internet Engineering Steering Group (IESG) and area 85 directorates. 87 Today's Internet is experienced by users as a set of applications, 88 such as email, instant messaging, and services on the Web. While 89 these applications do not require users to be present at the time of 90 service execution in many cases they are. There are also substantial 91 differences in performance between the various end devices, but in 92 general end devices participating in the Internet are considered to 93 have high performance. 95 There are, however, a large number of deployed embedded devices and 96 there is substantial value in interconnecting them with the Internet. 97 The term "Internet of Things" denotes a trend where a large number of 98 devices employ communication services offered by the Internet 99 Protocols. Many of these devices are not directly operated by 100 humans, but exist as components in buildings, vehicles, and the 101 environment. There is a large variation in the computing power, 102 available memory, (electrical) power, and communications bandwidth 103 between different types of devices. 105 Many of these devices offer a range of new possibilities or provide 106 additional value for previously unconnected devices. Some devices 107 have been connected using proprietary communication networks in the 108 past but are now migrating to the use of the Internet Protocol suite 109 in order to share the same communication network between all 110 applications and enabling rich communications services. 112 Much of this development can simply run on existing Internet 113 protocols. For instance, home entertainment and monitoring systems 114 often offer a web interface to the end user. In many cases the new, 115 constrained environments can benefit from additional protocols and 116 protocol extensions that help optimize the communications and lower 117 the computational requirements. Examples of currently ongoing 118 standardization efforts targeted for these environments include the 119 "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN 120 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 121 the "Light-Weight Implementation Guidance (LWIG)" working groups at 122 the IETF. 124 This workshop explored the experiences of researchers and developers, 125 when considering the characteristics of constrained devices. 126 Engineers know that many design considerations need to be taken into 127 account when developing protocols and architecture. Balancing 128 between the conflicting goals of code size, economical incentives, 129 power consumption, usability and security is often difficult, as 130 illustrated by Clark, et al. in "Tussle in Cyberspace: Defining 131 Tomorrow's Internet". 133 Participants at the workshop discussed the experience and approaches 134 taken when designing protocols and architectures for interconnecting 135 smart objects to the Internet. The scope of the investigations 136 included constrained nodes as well as constrained networks. 138 The call for position paper suggested investigating the area of 139 integration with the Internet in the following categories: 141 o Scalability 143 o Power efficiency 145 o Interworking between different technologies and network domains 147 o Usability and manageability 149 o Security and Privacy 151 The goals of the workshop can be summarized as follows: 153 As many deployed smart objects demonstrate running protocols, like 154 IP, TCP, UDP, HTTP, etc. on constrained devices is clearly is 155 possible. Still, protocol designers, system architects and 156 developers have to keep various limitations in mind. The 157 organizers were interested to discuss the experience with 158 deploying IETF protocols in different constrained environments. 160 Furthermore, the organizers were seeking to identify either issues 161 where current implementers do not yet have solutions or where 162 researchers predict potential issues. 164 The workshop served as a venue to identify problems and to 165 discover common interests that may turn into new work or into 166 changes in direction of already ongoing work at the IETF and or 167 the Internet Research Task Force (IRTF). 169 Note that this document is a report on the proceedings of the 170 workshop. The views and positions documented in this report are 171 those of the workshop participants and do not necessarily reflect IAB 172 views and positions. 174 2. Constrained Nodes and Networks 176 An observation that lead to the scheduling of the workshop was the 177 presence of constrained devices that are more and more interconnected 178 to the network. So, it is quite natural to ask how these limitations 179 impact the design of the affected nodes. Note that not all nodes 180 suffer from the same set of limitations. 182 Energy constraints: 184 Since wireless communication can be a large portion of the power- 185 budget for wireless devices, reducing unnecessary communication 186 can significantly increase the battery life of a low-end device. 187 The choice of low-power radio being used also has a lot of impact 188 on the overall energy consumption. Sleeping periodically, and 189 often aggressively, when not in use. In some cases, these nodes 190 will only wake periodically to handle needed communications. This 191 constraint is quite in contrast to the "always on" paradigm found 192 in regular Internet hosts. Even in case of non-battery operated 193 devices power is a constraint with respect to energy efficiency 194 goals. 196 Bandwidth constraints: 198 Various low power radio networks offer only ~100 KBit/s or even 199 only a few KBits/s, and show high packet loss as well as high link 200 quality variability. Nodes may be used in usually highly unstable 201 radio environments. The physical layer packet size may be limited 202 (~100 bytes). 204 Memory constraints: 206 Despite the overwhelming variety of Internet-connected devices 207 that can be found in deployments it may be useful to consider a 208 number of classes of constrained memory availability. For example 209 the following classes could be used: 211 +---------+------------------+--------------------+ 212 | Class | Volatile Storage | Persistent Storage | 213 +---------+------------------+--------------------+ 214 | Class 1 | ~ 10 KByte | ~ 100 KByte | 215 | | | | 216 | Class 2 | ~ 50 KByte | ~ 250 KByte | 217 +---------+------------------+--------------------+ 219 A system designer also needs to consider CPU constraints, which often 220 relate to energy constraints: a processor with lower performance 221 consumes less energy. As described later in this document the design 222 of the mainboard may allow certain components to be put to sleep to 223 further lower energy consumption. In general, embedded systems are 224 often purpose built with only the hardware components needed for the 225 given task while general purpose personal computers are less 226 constrained with regard to their mainboard layout and typically offer 227 a huge number of optional plug-in peripherals to be connected. A 228 factor that also has to be taken into consideration is the intended 229 usage environment. For example, a humidity sensor deployed outside a 230 building may need to deal with temperatures from -50 C to +85 C even. 231 There are often physical size limitations for smart objects. While 232 traditional mainboards are rather large, such as the Advanced 233 Technology eXtended (ATX) design with a board size of 305 x 244 mm 234 available in many PCs or the mini-ITX design typically found in home 235 theater PCs with 170 x 170 mm, mainboard layouts for embedded systems 236 are typically much smaller, such as the CoreExpress layout with 58 x 237 65 mm, or even smaller. In addition to the plain mainboard 238 additional sensors, peripherals, a power adapter/battery, and a case 239 have to be taken into consideration. Finally, there are cost 240 restrictions as well. 242 The situation becomes more challenging when not only the hosts are 243 constrained but also the network nodes themselves. 245 While there are constantly improvements being made, Moore's law tends 246 to be less effective in the embedded system space than in personal 247 computing devices: Gains made available by increases in transistor 248 count and density are more likely to be invested in reductions of 249 cost and power requirements than into continual increases in 250 computing power. 252 3. Workshop Structure 254 With the ongoing work on connecting smart objects to the Internet 255 there are many challenges the workshop participants raised in more 256 than 70 accepted position papers. With a single workshop day 257 discussions had to be focused and priority was given to those topics 258 that had been raised by many authors. A summary of the identified 259 issues are captured in the subsections below. 261 3.1. Architecture 263 A number of architectural questions were brought up in the workshop. 264 This is natural, as the architectural choices affect the required 265 technical solutions and the need for standards. At this workshop 266 questions regarding the separation of traffic, the need for profiling 267 for application specific domains, the demand for data model specific 268 standardization as well as the design choices of the layer at which 269 functionality should be put were discussed and are briefly summarized 270 below. 272 3.1.1. One Internet vs. Islands 274 Devices that used to be in proprietary or application-specific 275 networks are today migrating to IP networks. There is, however, the 276 question of whether these smart objects are now on the same IP 277 network as any other application as well. Controlled applications, 278 like the fountains in front of the Bellagio hotel in Las Vegas which 279 are operated as a distributed control system [Dolin], probably are 280 not exchanging their control messages over the same network that is 281 also used by hotel guests for their Internet traffic. The same had 282 been argued for the smart grid as well. The question that was raised 283 during the workshop is therefore in what sense are we talking about 284 one Internet or about using IP technology for a separate, walled 285 garden network that is independent of the Internet? 287 Cullen Jennings compared the current state of smart object deployment 288 with the evolution of voice-over-IP: "Initially, many vendors 289 recommended to run VoIP over a separate VLAN or a separate 290 infrastructure. Nobody could imagine how to make the type of real- 291 time guarantees, how to debug it, and how to get it to work because 292 the Internet is not ideally suited for making any types of guarantees 293 for real-time systems. As time went on people got better at making 294 voice work across that type of IP network. They suddenly noticed 295 that having voice running on a separate virtual network than their 296 other applications was a disaster. They couldn't decide if a PC is 297 running a softphone and whether it went on a voice or a data network. 298 At that point people realized that they needed a converged network 299 and all moved to one. I wouldn't be surprised to see the same 300 happens here. Initially, we will see very separated networks. Then, 301 those will be running over the same hardware to take advantage of the 302 cost benefits of not having to deploy multiple sets of wires around 303 buildings. Over time there will be strong needs to directly 304 communicate with each other. We need to be designing the system for 305 the long run. Assuming everything will end up on the same network 306 even if you initially plan to run it in separate networks." 308 It is clearly possible to let sensors in a building communicate 309 through the wireless access points and through the same 310 infrastructure used for Internet access, if you want to. Those who 311 want separation at the physical layer can do so as well. What is, 312 however, important is to make sure that these different deployment 313 philosophies do not force loss of interoperability. 315 The level of interoperability that IP accomplished fostered 316 innovation at the application layer. Ralph Droms reinforced this 317 message by saying: "Bright people will take a phone, build an 318 application and connect it, with the appropriate security controls in 319 place, to the things in my house in ways we have never thought about 320 before. Otherwise we are just building another telephone network." 322 3.1.2. Domain Specific Stacks and Profiles 324 Imagine a home network scenario where a new light bulb is installed 325 that should, out of the box without further configuration, 326 interoperate with the already present light switch from a different 327 vendor in the room. For many this is the desired level of 328 interoperability in the area of smart object design. To accomplish 329 this level of interoperability it is not sufficient to provide 330 interoperability only at the network layer. Even running the same 331 transport and application layer protocols is insufficient since both 332 devices need to understand the semantics of the protocol 333 communication for "Turn the light on" as well. 335 Standardizing the entire protocol stack for this specific "light 336 switch/light bulb" scenario is possible. A possible stack would, for 337 example, use IPv6 with a specific address configuration mechanism 338 (such as stateless address autoconfiguration), a network access 339 authentication security mechanism such as PANA, a service discovery 340 mechanism (multicast DNS with DNS-SD), an application layer protocol, 341 for example, Constrained Application Protocol (CoAP) (which uses 342 UDP), and the syntax and semantic for the light on/off functionality. 344 As this list shows there is already some amount of protocol 345 functionality that has to be agreed on by various stakeholders to 346 make this scenario work seamlessly. As we approach more complex 347 protocol interactions the functionality quickly becomes more complex: 349 IPv4 and IPv6 on the network layer, various options at the transport 350 layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices 351 at the application layer with respect to communication protocols, 352 data formats and data models. Different requirements have lead to 353 the development of a variety of communication protocols: client- 354 server protocols in the style of the original HTTP, publish-subscribe 355 protocols (like SIP or XMPP), store-and-forward messaging (borrowed 356 from the delay tolerant networking community). Along with the 357 different application layer communication protocols come various 358 identity and security mechanisms. 360 With the smart object constraints it feels natural to develop these 361 stacks since each application domain (e.g., health-care, smart grids, 362 home networking) will have their unique requirements and their own 363 community involved in the design process. How likely are these 364 profiles going to be the right match for the future, specifically for 365 the new innovations that will come? How many of these stacks are we 366 going to have? Will the differences in the profiles purely be the 367 result of different requirements coming from the individual 368 application domains or will these mismatches reflect the spirit, 369 understanding and preferences of the community designing them? How 370 many stacks will multi-purpose devices have to implement? 372 Standardizing profiles independently for each application is not the 373 only option. Another option is to let many different applications 374 utilize a common foundation, i.e., a protocol stack that is 375 implemented and utilized by every device. This, however, requires 376 various application domains to be analyzed for their common 377 characteristics and to identify requirements that are common across 378 all of them. The level of difficulty for finding an agreement of how 379 such a foundation stack should look like depends on how many layers 380 it covers and how lightweight it has to be. 382 From the decisions at the workshop it was clear that the available 383 options are not ideal and further discussions are needed. 385 3.1.3. Which Layer? 387 The end-to-end principle states that functionality should be put into 388 the end points instead of into the networks. An additional 389 recommendation, which is equally important, is to put functionality 390 higher up in the protocol stack. While it is useful to make common 391 functionality available as building blocks to higher layers the wide 392 range of requirements by different applications lead to a model where 393 lower layers provide only very basic functionality and more 394 sophisticated features were made available by various applications. 395 Still, there has been the desire to put application layer 396 functionality into the lower layers of the networking stack. A 397 common belief is that performance benefits can be gained if 398 functionality is placed at the lower layers of the protocol stack. 399 This new functionality may be offered in the form of a gateway, which 400 bridges different communication technologies, acts on behalf of other 401 nodes, and offers more generic functionality (such as name-based 402 routing and caching). 404 Two examples of functionality offered at the network layer discussed 405 during the workshops were location, and name-based routing: 407 Location: 409 The notion of location gives each network node the understanding 410 of proximity (e.g., 'I am a light bulb and in the same room as the 411 light switch.'). Today, a router may provide information as to 412 whether other nodes belong to the same subnet or they may provide 413 location information (for example, in the form of GPS based 414 coordinates). However, providing a sense of the specific 415 environment (e.g., a room, building, campus, etc.) is not possible 416 without manual configuration. While it has been a desirable 417 feature for many ubiquitous computing applications to know this 418 type of information and to use it for richer application layer 419 interactions, widespread deployment has not happened yet. 421 Name-based Routing: 423 With the work on recent clean slate architecture proposals, such 424 as the named data networking, flexible naming concepts are being 425 researched to allow application developer to express their 426 application layer concepts in a way that they can be used natively 427 by the underlying networking stack without translation. For 428 example, Jeff Burke provided the example of his work in a theater 429 with a distributed control system of technical equipment (such as 430 projectors, dimmers, and light systems). Application developers 431 name their equipment with human readable identifiers, which may 432 change after the end of a rehearsal, and address them using these 433 names. These variable length based naming concepts raise 434 questions regarding scalability. 436 The workshop participants were not able to come to an agreement about 437 what functionality should be moved from the application layer to the 438 network layer. 440 3.2. Sleep Modes 442 One limitation of smart objects is the available energy. To extend 443 battery life, for example of a watch battery or single AAA battery 444 for months, these small, low power devices have to sleep from 99% to 445 99.5% of their time. For example, a light sensor may wake up to 446 check whether it is night-time to turn on light bulbs. Most parts of 447 the system are off-line most of the time and particularly 448 communication components are put into a sleeping state (e.g., WLAN 449 radio interface) and only very few components of an embedded system 450 board, such as sensors, are triggered periodically. When interesting 451 events happen then these components wake-up other parts of the 452 system, for example a radio interface to connect to the Internet. 453 Every bit is precious, so is every round trip, and every millisecond 454 of radio activity. 456 Many IETF protocols implicitly assume that nodes in a network are 457 always-on and respond to messages, i.e., to maintain a persistent 458 presence on the network in order to respond to periodic messages that 459 are required in order to maintain persistent sessions, connections, 460 security associations, or state. These protocols work well on 461 networks with sufficient network bandwidth, where there is a low cost 462 to receiving/sending messages, and nodes are persistently available 463 on the network. 465 In the early days a machine had gotten a specific IP address 466 allocated and it could use it when it wanted to send an IP packet. 467 You might need to execute an ARP exchange first before sending the 468 packet but you could keep the mapping in the cache for 15 minutes. 470 Nowadays we want to make sure that we are on the right network before 471 we send an IP packet, we run neighbor discovery, we cannot keep 472 neighbor discovery for 15 minutes and so when a node wakes up again 473 it essentially has to re-do it to refresh the cache, we want to run 474 Detecting Network Attachment (DNA) procedures to check that hosts are 475 on the same network either by re-getting an address using the Dynamic 476 Host Configuration Protocol (DHCP) or by noticing that the node is 477 using the same default gateway because of a received Router 478 Advertisement (RA). Essentially, a number of steps have to be taken 479 before sending a packet. 481 However, these protocols do not work well, at all, when the cost of 482 sending/receiving those messages are high (in terms of bandwidth or 483 battery life) or in cases where nodes sleep periodically and are not 484 persistently available to receive those messages. A number of issue 485 arise from these almost-always-off nodes. 487 Also a lot of our protocols are getting more chatty. Keeping the 488 receiver up for an additional roundtrip costs extra energy. Protocol 489 messages can also be lengthy, e.g., many protocols carry XML-based 490 payloads. 492 There are a couple of ways to think about how to make the situation 493 less worse: 495 1. The Always-On Assumption 497 When designing a protocol that assumes that the nodes will always 498 be there at least consider an alternative paradigm. For example, 499 with duplicate address detection an alternative would be not to 500 use it. There might be also the option to consider an 501 architecture with a proxy node that these nodes can poll when 502 they boot up to find out whether anyone tried to contact them or 503 whether anything they care about has happened, or the proxy 504 answers on behalf of another node. 506 2. High Cost to Rejoin the Network 508 The goal of these things is to determine whether a wireless node 509 is not moved to another network while it was asleep and that 510 might be a viable thing to do. Expecting a wirelss node to go 511 through all these steps every time it wakes up before it is 512 allowed to send an Ip packet could be considered rather 513 excessive. 515 Can we find ways to reduce the number of protocol interactions 516 that have to be executed for network attachment, including 517 determining whether a node has moved or the environment has 518 changed otherwise? 520 3. Verbose Protocols 522 Some protocols involve multiple roundtrips and/or lengthy 523 messages. As a result, low-powered nodes have to use more power 524 in sending messages and have to stay powered on for a longer 525 period of time as they wait for the protocol exchanges to 526 complete. The best way to address these problems is to ensure 527 that the simplest possible protocol exchanges are used when the 528 protocols in question are designed. However, in some cases 529 alternative encoding formats and compression may also help. 531 A number of protocol could be considered in such an investigation. 532 The main focus of past investigations has so far been on IPv6 and ND. 533 One can argue that certain features are not useful in an environment 534 where most nodes are sleeping, such as duplicate address detection. 535 Other protocols to investigate would be DNS, and DHCP. 537 During the protocol design phase certain protocols were assumed to be 538 used in a human-to-device context and therefore it was argued that 539 the verbose encoding is helpful. Examples are the Hypertext Transfer 540 Protocol (HTTP), the Session Initiation Protocol (SIP), and 541 Extensible Messaging and Presence Protocol (XMPP). Nowadays these 542 protocols are also being considered and used in device-to-device 543 communication and the verbose nature is not helpful. 545 While the principles seem to be most useful for low-power, battery 546 powered devices they would also be useful for other devices as well. 547 Energy efficiency is useful for normal devices as well, such as 548 laptops and smart phones. 550 For example, consider energy consumption in a home environment. The 551 question is whether it will save more energy than it uses and 552 therefore one has to consider the overall energy consumption of the 553 entire solution. This is not always an easy question to answer. 554 IEEE 802.11 nodes, for example, use a lot of power if they cannot be 555 made to sleep most of the time. A light bulb may use less power but 556 there is also the device that controls the bulb that may consume a 557 lot of energy all the time. In total, more energy may be consumed 558 when considering these two devices together. 560 3.3. Security 562 In the development of a smart object application security, as with 563 any other protocol application solution, has to be considered early 564 in the design process. As such, the recommendations currently 565 provided by IETF protocol architects, such as RFC 3552 [RFC3552], RFC 566 4101 [RFC4101], and other recommendations, apply also to the smart 567 object space. 569 While there are additional constraints, as described in Section 2, 570 security has to be a mandatory part of the solution. The hope is 571 that this will lead to implementations that provide security 572 features, deployments that utilize these, and finally that this leads 573 to use of better security mechanisms. It is important to point out 574 that the lack of direct user interaction will place hard requirements 575 on deployment models, configuration mechanisms, and software upgrade/ 576 crypto agility mechanisms. 578 Since many of the security mechanism allow for customization, 579 particularly with regard to the cryptographic primitives utilized, 580 many believe that IETF security solutions are usable without 581 modifications in a large part of the smart object domain. Others 582 call for new work on cryptographic primitives that make use of a 583 single primitive (such as the Advanced Encryption Standard (AES)) as 584 a building block for all cryptographic functions with the benefit of 585 a smaller footprint of the overall solution. Specifically the 586 different hardware limitations (e.g., the hardware architecture of 587 certain embedded devices prevents pipelining to be utilized). In the 588 excitement for new work on optimizations of cryptograhpic primitives 589 other factors have to be taken into consideration that influence 590 successful deployment, such as widespread ability in libraries, as 591 well as intellectual property rights (IPR). As an example of the 592 latter aspect the struggle of Elliptic Curve Cryptography (ECC)-based 593 cryptographic algorithms to find deployment can partially be 594 attributed to the IPR situation. The reuse of libraries providing 595 cryptographic functions is clearly an important way to use available 596 memory resources in a more efficient way. To deal with the 597 performance and footprint concerns investigations into offloading 598 certain resource-hungry functions to parties that possess more 599 cryptographic power have been considered. For example, the ability 600 to delegate certificate validation to servers has been standardized 601 in the IETF before (see Online Certificate Status Protocol (OCSP) in 602 the Internet Key Exchange protocol version 2 (IKEv2) and in Transport 603 Layer Security (TLS)). 605 Focusing only on the cryptographic primitives would be shortsighted; 606 many would argue that this is the easy part of a smart object 607 security solution. Key management and credential enrollment, 608 however, are considered a big challenge by many particularly when 609 usability requirements have to be taken into account. Another group 610 of challenges is seen in the privacy area where the ongoing work on 611 smart grids could be mentioned where concerns regarding the ability 612 of others to keep track of the user's energy usage consumption (and 613 the associated conclusions) even in an aggregated form have been 614 voiced. As another example, it is easy to see how a scale that is 615 connected to the Internet for uploading weight information to a 616 social network could lead to privacy concerns. While security 617 mechanisms used to offer protection of the communication between 618 different parties also provide a certain degree of privacy protection 619 they are clearly not enough to address all concerns. Even with the 620 best communication security and access control mechanisms in place 621 one still needs additional safeguards against the concerns mentioned 622 in the examples. 624 While a lot can be said about how desirable it would be to deploy 625 more security protocols on the entire Internet, practical 626 considerations regarding usability and the incentives of the 627 stakeholders involved have often lead to slower adaption. 629 3.4. Routing 631 A smart object network environment may also employ routers under 632 similar constraints as the end devices. Currently two approaches to 633 routing in these low power and lossy networks are under 634 consideration, namely mesh-under and route-over. The so-called mesh- 635 under approach places routing functions below at the link layer and 636 consequently all devices appear as immediate neighbors at the network 637 layer. With the route-over approach routing is done at the IP layer 638 and none in the link layer. Each physical hop appears as a single IP 639 hop (ignoring devices that just extend the physical range of 640 signaling, such as repeaters). Routing in this context means running 641 a routing protocol. IPv6 Routing Protocol for Low power and Lossy 642 Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the 643 route-over category. 645 From an architectural point of view there are several questions that 646 arise from where routing is provided, for example: 648 o Protocols often assume that link characteristics are deterministic 649 when communicating with any device attached to the same link. 650 Latency, throughput, and reliability may vary considerably between 651 different devices that are multiple link layer hops away. What 652 timeout should be used? What happens if a device is unreachable? 653 In case of default router selection two advertised routers may be 654 a different number of hops away. Should a device have visibility 655 into the path to make a decision and what path characteristics 656 would be useful to have? 658 o Scoped message delivery to a neighboring IP hop (via link-local 659 addressing) allows certain types of IP protocols to communicate 660 with their immediate neighbors and to therefore scope their 661 recipients. A link-local multicast message will be received by 662 all nodes in the same IP link local realm unless some special 663 optimizations are provided by the link layer. 665 o When path computations are done at the link layer as well as on 666 the network layer then what coordination needs to take place? 668 When multiple different link layer technologies are involved in a 669 network design then routing at layer 3 has to be provided in any 670 case. [I-D.routing-architecture-iot] talks about these tradeoffs 671 between route-over and mesh-under in detail. Furthermore, those who 672 decide about the deployment have to determine how to connect smart 673 objects to the Internet infrastructure and a number of wired and 674 wireless technologies may be suitable for a specific deployment. 675 Depending on the chosen technologies the above-mentioned mesh-under 676 vs. route-over approach will have to be decided and further decisions 677 will have to be made about the choice of a specific routing protocol. 679 In 2008 the IETF formed the Routing Over Low power and Lossy networks 680 (ROLL) working group to specify a routing solution for smart object 681 environments. During its first year of existence, the working group 682 studied routing requirements in details (see [RFC5867], [RFC5826], 683 [RFC5673], [RFC5548]), published a protocol survey looking at a 684 number of existing routing protocols 685 [I-D.ietf-roll-protocols-survey], including Ad hoc On-Demand Distance 686 Vector (AODV)-style of protocols. The ROLL WG concluded that a new 687 routing protocol satisfying the documented requirements has to be 688 developed and the work on the RPL was started, as the IETF routing 689 protocol for smart object networks. Nevertheless, controversial 690 discussions at the workshop about which routing protocols is best in 691 a given environment are still ongoing. Thomas Clausen, for example, 692 argued for using an AODV-like [RFC3561] routing protocol in 693 [Clausen]. 695 4. Conclusions and Next Steps 697 The workshop allowed the participants to get exposed to interesting 698 applications and their requirements (buildings, fountains, theater, 699 etc.), to have discussions about radically different architectures 700 and their issues (e.g., information centric networking), to look at 701 existing technology from a new angle (sleep nodes, energy 702 consumption), to focus on some details of the protocol stack 703 (neighbour discovery, security, routing) and to implementation 704 experience. 706 One goal of the workshop was to identify areas that require further 707 investigation. The list below reflects the thoughts of the workshop 708 participants as expressed on the day of the workshop. Note that the 709 suggested items concern potential work by the IETF and the IRTF and 710 the order does not imply a particular preference. 712 Security: 714 A discussion of security is provided in Section 3.3. In general, 715 security related protocol exchanges and the required amount of 716 computational resource requirements can contribute significantly 717 to the overall processing. Therefore, it remains a challenge how 718 to accomplish performance improvements without sacrifying the 719 overall security level taking the usability of the entire system 720 into consideration. 722 Another challenge is how to balance the security and performance 723 needs of challenged nodes with the interoperability requirements 724 of hosts on the Internet since different suites of algorithms may 725 tend to be chosen for these different environments. This involves 726 trade-offs between performance on the challenged nodes versus end- 727 to-end security. Solutions that mandate a "trusted" middlebox 728 whose only role is to terminate security associations tend to be 729 frowned upon from the security perspective, especially since end- 730 users of challenged devices (where those exist) are unlikely to 731 understand the security consequences of such middleboxes. 733 The discussion concluded with the following recommendations: 735 * Investigate usability in cryptographic protocol design with 736 regard to credential management. As an example, the Bluetooth 737 pairing mechanism was mentioned as a simple and yet reasonably 738 secure method of introducing devices into a new environment. 739 In fact, the IETF working group 'Credential and Provisioning 740 (ENROLL)' working group was established years ago to deal with 741 this topic but was terminated prematurely due to lack of 742 progress. The email archives still exists and is available 744 [enroll] and may provide useful historical information. 746 * Standardized authentication and key exchange mechanisms should 747 be surveyed for suitability in smart object environments with 748 respect to message size, computational performance, number of 749 messages, codesize, and main memory requirements. A starting 750 point of such an investigation (in case of IKEv2) was provided 751 by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a 752 suitable venue for discussion could be the recently established 753 Light-Weight Implementation Guidance (LWIG) working group 754 [LWIG]. 756 * Research has to be done in the area of lightweight 757 cryptographic primitives, namely block ciphers, stream ciphers, 758 and cryptographic hash functions. Worthwhile to mention is 759 early work with the National Institute of Standards and 760 Technology (NIST) new cryptographic hash algorithm 'SHA-3' 761 competition. A suitable forum for discussion is the IRTF 762 Crypto Forum Research Group (CFRG) [CFRG]. 764 The difficulty and impact of choosing specialised algorithms for 765 challenged nodes should not be underestimated. Issues that arise 766 include the additional specification complexity (e.g., TLS already 767 has 100's of ciphersuites defined, most of which are unused in 768 practice), the long latency in terms of roll out (many hosts are 769 still using deprecated algorithms 5-10 years after those 770 algorithms were deprecated) and the barriers that IPR-encumbered 771 schemes present to widespread deployment. While research on this 772 topic within CFRG and the cryptographic research community is a 773 very worthwhile goal, any such algorithms will likely have to 774 offer very significant benefits before they will be broadly 775 adopted. 20% less CPU is unlikely to be a winning argument no 776 matter what an algorithm inventor believes. 778 Energy Design Considerations: 780 One part of the workshop was focused on the discussion of energy 781 implications for IETF protocol design with proposals being made 782 how to extend protocols to better support nodes that are mostly 783 sleeping. Discussion are encouraged to take place may take place 784 at the RECIPE mailing list [RECIPE]. The workshop position paper 785 [Wasserman] by Margaret Wasserman provides a good starting point 786 for further investigations. 788 Information/Content Centric Networking: 790 Information/Content Centric Networking is about accessing named 791 content and a number of research projects have emerged around this 792 theme. At this point in time the work is not yet ready for 793 standardization in the IETF. Instead, the formation of an IRTF 794 research group has been proposed and more details are available on 795 the IRTF DISCUSS mailing list [irtf-discuss]. 797 Architectural Guidelines: 799 Participants suggested developing an architectural write-up about 800 what can be done with the IETF protocols we have today and how 801 these different elements may be combined to offer an explanation 802 for the broader community. This would be a task for the Internet 803 Architecture Board (IAB). An example of prior work that serves as 804 input is [I-D.baker-ietf-core]. 806 Network Management: 808 While this topic did not make it onto the workshop agenda it was 809 considered useful to start a discussion about how to implement 810 network management protocols, such as Network Configuration 811 Protocol (NETCONF), on smart objects. The following position 812 papers may be useful as a starting point for further discussions 813 [Ersue], [Schoenwaelde]. An IETF draft is also available 814 [I-D.hamid-6lowpan-snmp-optimizations]. 816 Congestion Control: 818 When smart objects transmit sensor readings to some server on the 819 Internet then these protocol interactions often carry a small 820 amount of data and happen infrequently, although regularly. With 821 the work on new application protocols, like the CoAP 822 [I-D.ietf-core-coap], the question of congestion control mechanism 823 should be used at the underlying transport protocol or by the 824 application protocol itself. [I-D.eggert-core-congestion-control] 825 is a starting point for the CoAP protocol but further work is 826 needed. 828 Data Models: 830 Standardization of application layer protocols is important but 831 does not ensure that, for example, a light switch and a light bulb 832 are able to interact with each other. One are where participants 833 saw the need for further work was in the area of data models. 834 While prior IETF standardization work on, for example, location 835 [GEOPRIV] can be re-used the question was raised where the IETF 836 should focus their standardization efforts on since domain 837 expertise in each area will be needed. As potential example 838 energy pricing was discussed, with an example provided by 839 [I-D.jennings-energy-pricing]. 841 Discovery: 843 Additional extensions to developed discovery protocols (such as 844 mDNS) may be needed for the smart object environment. 846 Home Networking: 848 Home network architectures should take into account the 849 possibility of smart objects and dedicated subnetworks focusing on 850 smart objects. A new working group, Home Networking (HOMENET) 851 [FUN], has been proposed after the workshop to look at this topic. 853 Routing: 855 Changing radio conditions and link fluctuation may lead to the 856 need for re-numbering. Workshop participants argued that work 857 should be started on the multi-link subnetworks to mitigate this 858 problem, i.e., to extend the notion of a subnet to be able to span 859 multiple links. With the publication of RFC 4903 [RFC4903] the 860 Internet Architecture Board had looked into this topic already and 861 provided pros and cons. 863 The applicability of specific routing protocols designed for smart 864 object networks needs further investigation. The ROLL working 865 group is chartered with the task of constructing an applicability 866 document for the RPL protocol, for instance. 868 5. Security Considerations 870 The workshop discussions covered a range of potential engineering 871 activities, each with its own security considerations. As the IETF 872 community begins to pursue specific avenues arising out of this 873 workshop, addressing relevant security requirements will be crucial. 875 As described in this report part of the agenda was focused on the 876 discussion of security, see Section 3.3. 878 6. Acknowledgements 880 We would like to thank all the participants for their position 881 papers. The authors of the position papers were invited to the 882 workshop. 884 Big thanks to Elwyn Davies for helping us to fix language bugs. 886 Additionally, we would like to thank Ericsson and Nokia Siemens 887 Networks for their financial support. 889 7. IANA Considerations 891 This document does not require actions by IANA. 893 8. Informative References 895 [CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group 896 (CFRG)", http://irtf.org/cfrg , June 2011. 898 [Clausen] Clausen, T. and U. Herberg, "Some Considerations on 899 Routing in Particular and Lossy Environments", IAB 900 Interconnecting Smart Objects with the Internet Workshop, 901 Prague, Czech Republic, http://www.iab.org/wp-content/ 902 IAB-uploads/2011/03/Clausen.pdf, March 2011. 904 [Dolin] Dolin, B., "Application Communications Requirements for 905 'The Internet of Things'", IAB Interconnecting Smart 906 Objects with the Internet Workshop, Prague, Czech Republic 907 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 908 Ersue.pdf, March 2011. 910 [Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object 911 Workshop Position Paper", IAB Interconnecting Smart 912 Objects with the Internet Workshop, Prague, Czech Republic 913 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 914 Ersue.pdf, March 2011. 916 [FUN] "FUture home Networking (FUN) Mailing List", 917 https://www.ietf.org/mailman/listinfo/fun , June 2011. 919 [GEOPRIV] "IETF Geographic Location/Privacy Working Group", 920 http://datatracker.ietf.org/wg/geopriv/ , June 2011. 922 [I-D.baker-ietf-core] 923 Baker, F. and D. Meyer, "Internet Protocols for the Smart 924 Grid", draft-baker-ietf-core-15 (work in progress), 925 April 2011. 927 [I-D.eggert-core-congestion-control] 928 Eggert, L., "Congestion Control for the Constrained 929 Application Protocol (CoAP)", 930 draft-eggert-core-congestion-control-01 (work in 931 progress), January 2011. 933 [I-D.hamid-6lowpan-snmp-optimizations] 934 Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP 935 Optimizations for Constrained Devices", 936 draft-hamid-6lowpan-snmp-optimizations-03 (work in 937 progress), October 2010. 939 [I-D.ietf-core-coap] 940 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 941 "Constrained Application Protocol (CoAP)", 942 draft-ietf-core-coap-06 (work in progress), May 2011. 944 [I-D.ietf-roll-protocols-survey] 945 Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview 946 of Existing Routing Protocols for Low Power and Lossy 947 Networks", draft-ietf-roll-protocols-survey-07 (work in 948 progress), April 2009. 950 [I-D.ietf-roll-rpl] 951 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 952 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 953 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 954 Lossy Networks", draft-ietf-roll-rpl-19 (work in 955 progress), March 2011. 957 [I-D.jennings-energy-pricing] 958 Jennings, C., "Communication of Energy Pricing 959 Information", draft-jennings-energy-pricing-00 (work in 960 progress), March 2011. 962 [I-D.kivinen-ipsecme-ikev2-minimal] 963 Kivinen, T., "Minimal IKEv2", 964 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 965 February 2011. 967 [I-D.routing-architecture-iot] 968 Hui, J. and J. Vasseur, "Routing Architecture in Low-Power 969 and Lossy Networks (LLNs)", 970 draft-routing-architecture-iot-00 (work in progress), 971 March 2011. 973 [LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 974 Group", http://datatracker.ietf.org/wg/lwig/charter/ , 975 June 2011. 977 [RECIPE] "Reducing Energy Consumption with Internet Protocols 978 Exploration (RECIPE) Mailing List", 979 https://www.ietf.org/mailman/listinfo/recipe , June 2011. 981 [RFC2222] Myers, J., "Simple Authentication and Security Layer 982 (SASL)", RFC 2222, October 1997. 984 [RFC2743] Linn, J., "Generic Security Service Application Program 985 Interface Version 2, Update 1", RFC 2743, January 2000. 987 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 988 Text on Security Considerations", BCP 72, RFC 3552, 989 July 2003. 991 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 992 Demand Distance Vector (AODV) Routing", RFC 3561, 993 July 2003. 995 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 996 Levkowetz, "Extensible Authentication Protocol (EAP)", 997 RFC 3748, June 2004. 999 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1000 June 2005. 1002 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1003 June 2007. 1005 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1006 "Routing Requirements for Urban Low-Power and Lossy 1007 Networks", RFC 5548, May 2009. 1009 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1010 Framework", RFC 5582, September 2009. 1012 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1013 "Industrial Routing Requirements in Low-Power and Lossy 1014 Networks", RFC 5673, October 2009. 1016 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1017 Routing Requirements in Low-Power and Lossy Networks", 1018 RFC 5826, April 2010. 1020 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1021 "Building Automation Routing Requirements in Low-Power and 1022 Lossy Networks", RFC 5867, June 2010. 1024 [Schoenwaelde] 1025 Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol 1026 Profiles for Constrained Devices", IAB Interconnecting 1027 Smart Objects with the Internet Workshop, Prague, Czech Re 1028 public, http://www.iab.org/wp-content/IAB-uploads/2011/03/ 1029 Schoenwaelder.pdf, March 2011. 1031 [Wasserman] 1032 Wasserman, M., "It's Not Easy Being "Green"", IAB 1033 Interconnecting Smart Objects with the Internet Workshop, 1034 Prague, Czech Republic, http://www.iab.org/wp-content/ 1035 IAB-uploads/2011/03/Wasserman.pdf, March 2011. 1037 [enroll] "IETF Credential and Provisioning Working Group Mailing 1038 List", http://mailman.mit.edu/pipermail/ietf-enroll/ , 1039 June 2011. 1041 [irtf-discuss] 1042 "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http: 1043 //www.ietf.org/mail-archive/web/irtf-discuss/current/ 1044 msg00041.html , May 2011. 1046 Appendix A. Program Committee 1048 The following persons are responsible for the organization of the 1049 associated workshop and are responsible also for this event: Jari 1050 Arkko, Hannes Tschofenig, Bernard Aboba,Carsten Bormann, David 1051 Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph 1052 Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo 1053 Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen 1054 Jennings, Manfred Hauswirth, and Lukas Kencl. 1056 Appendix B. Published Workshop Material 1058 Information about the workshop can be found at the IAB webpage: 1059 http://www.iab.org/about/workshops/smartobjects/ 1061 71 position papers were submitted to the workshop: 1063 1. Deployment Experience with Low Power Lossy Wireless Sensor 1064 Networks by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. 1065 Philipp, and G. Wittenburg 1067 2. CoAP improvements to meet embedded device hardware constraints 1068 by Davide Barbieri 1070 3. Unified Device Networking Protocols for Smart Objects by Daniel 1071 Barisic and Anton Pfefferseder 1073 4. Simplified neighbour cache implementation in RPL/6LoWPAN by 1074 Dominique Barthel 1076 5. Home Control in a consumer's perspective by Anders Brandt 1078 6. Authoring Place-based Experiences with an Internet of Things: 1079 Tussles of Expressive, Operational, and Participatory Goals by 1080 Jeff Burke 1082 7. A Dynamic Distributed Federated Approach for the Internet of 1083 Things by Diego Casado Mansilla, Juan Ramon Velasco Perez, and 1084 Mario Lopez-Ramos 1086 8. Quickly interoperable Internet of Things using simple 1087 transparent gateways by Angelo P. Castellani, Salvatore Loreto, 1088 Nicola Bui, and Michele Zorzi 1090 9. Position Paper of the Brno University of Technology Department 1091 of Telecommunications by Vladimir Cervenka, Lubomir Mraz, Milan 1092 Simek, Karel Pavlata 1094 10. Secure Access to IOT Network: An Application-based Group Key 1095 Approach by Samita Chakrabarti, and Wassim Haddad 1097 11. Domain-Insulated Autonomous Network Architecture (DIANA) by W. 1098 Chun 1100 12. Yet Another Definition on Name, Address, ID, and Locator 1101 (YANAIL) by W. Chun 1103 13. The Challenge of Mobility in Low Power Networks by E. Davies 1105 14. If the routing protocol is so smart, why should neighbour 1106 discovery be so dumb? by Nicolas Dejean 1108 15. Making Smart Objects IPv6 Ready: Where are we? by M. Durvy and 1109 M. Valente 1111 16. Position Paper on "Interconnecting Smart Objects with the 1112 Internet" by Mehmet Ersue, and Jouni Korhonen 1114 17. The Real-time Enterprise: IoT-enabled Business Processes by 1115 Stephan Haller, and Carsten Magerkurth 1117 18. Making Internet-Connected Objects readily useful by Manfred 1118 Hauswirth, Dennis Pfisterer, Stefan Decker 1120 19. Some Considerations on Routing in Particular and Lossy 1121 Environments by Thomas Clausen, and Ulrich Herberg 1123 20. A Security Protocol Adaptation Layer for the IP-based Internet 1124 of Things by Rene Hummen, Tobias Heer, and Klaus Wehrle 1126 21. Simplified SIP Approach for the Smart Object by Ryota Ishibashi, 1127 Takumi Ohba, Arata Koike, and Akira Kurokawa 1129 22. Mobility support for the small and smart Future Internet devices 1130 by Antonio J. Jara, and Antonio F. G. Skarmeta 1132 23. The Need for Efficient Reliable Multicast in Smart Grid Networks 1133 by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk 1135 24. Lightweight Cryptography for the Internet of Things by Masanobu 1136 Katagi, and Shiho Moriai 1138 25. Thoughts on Reliability in the Internet of Things by James 1139 Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli 1141 26. IKEv2 and Smart Objects by Tero Kivinen 1143 27. Position Paper on Thing Name Service (TNS) for the Internet of 1144 Things (IoT) by Ning Kong, and Shuo Shen 1146 28. Connecting Smart Objects to Wireless WANs by Suresh Krishnan 1148 29. Towards an Information-Centric Internet with more Things by D. 1149 Kutscher, and S. Farrell 1151 30. Application of 6LoWPAN for the Real-Time Positioning of 1152 Manufacturing Assets by Jaacan Martinez and Jose L. M. Lastra 1154 31. Lighting interface to wireless network by Jaroslav Meduna 1156 32. Social-driven Internet of Connected Objects by Paulo Mendes 1158 33. Protocols should go forward that are required by non IP based 1159 protocols by Tsuyoshi Momose 1161 34. Web services for Wireless Sensor and Actuator Networks by Guido 1162 Moritz 1164 35. Connecting BT-LE sensors to the Internet using Ipv6 by Markus 1165 Isomaeki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, 1166 Basavaraj Patil, Teemu Savolainen, and Zach Shelby 1168 36. Position Paper by Bruce Nordman by Bruce Nordman 1170 37. Issues and Challenges in Provisioning Keys to Smart Objects by 1171 Yoshihiro Ohba, and Subir Das 1173 38. Challenges and Solutions of Secure Smart Environments by Eila 1174 Ovaska and Antti Evesti 1176 39. Research Experiences about Internetworking Mechanisms to 1177 Integrate Embedded Wireless Networks into Traditional Networks 1178 by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar 1180 40. Scalable Video Coding in Networked Environment by Naeem Ramzan, 1181 Tomas Piatrik, and Ebroul Izquierdo 1183 41. Challenges in Opportunistic Networking by Mikko Pitkaenen, and 1184 Teemu Kaerkkaeinen 1186 42. Position Statement by Neeli R. Prasad, and Sateesh Addepalli 1188 43. A Gateway Architecture for Interconnecting Smart Objects to the 1189 Internet by Akbar Rahman, Dorothy Gellert, Dale Seed 1191 44. Routing Challenges and Directions for Smart Objects in Future 1192 Internet of Things by T. A. Ramrekha, E. Panaousis, and C. 1193 Politis 1195 45. 6LoWPAN Extension for IPsec by Shahid Raza, Thiemo Voigt, and 1196 Utz Roedig 1198 46. Connected Vehicle as Smart Object(s) by Ryuji Wakikawa 1200 47. Problem and possible approach of development and operation of 1201 Smart Objects by Shoichi Sakane 1203 48. Connecting Passive RFID Tags to the Internet of Things by Sandra 1204 Dominikus, and Joern-Marc Schmidt 1206 49. Protocol Profiles for Constrained Devices by Juergen 1207 Schoenwaelde, Tina Tsou, and Behcet Sarikaya 1209 50. Multihoming for Sensor Networks by J. Soininen 1211 51. Internet Objects for Building Control by Peter van der Stok, and 1212 Nicolas Riou 1214 52. Optimal information placement for Smart Objects by Shigeya 1215 Suzuki 1217 53. Multi-National Initiative for Cloud Computing in Health Care 1218 (MUNICH) by Christoph Thuemmler 1220 54. The time of the hourglass has elapsed by Laurent Toutain, 1221 Nicolas Montavont, and Dominique Barthel 1223 55. Sensor and Actuator Resource Architecture by Vlasios Tsiatsis, 1224 Jan Hoeller, and Richard Gold 1226 56. IT'S NOT EASY BEING "GREEN" by Margaret Wasserman 1228 57. Trustworthy Wireless Industrial Sensor Networks by Markus 1229 Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis 1230 Olivereau, and Oualha Nouha 1232 58. Interconnecting smart objects through an overlay networking 1233 architecture by Anastasios Zafeiropoulos, Athanassios 1234 Liakopoulos and Panagiotis Gouvas 1236 59. Building trust among Virtual Interconnecting Smart Objects in 1237 the Future Internet by Theodore Zahariadic, Helen C. Leligou, 1238 Panagiotis Trakadas, and Mischa Dohler 1240 60. Experience and Challenges of Integrating Smart Devices with the 1241 Mobile Internet by Zhen Cao, and Hui Deng 1243 61. The "mesh-under" versus "route over" debate in IP Smart Objects 1244 Networks by JP Vasseur, and Jonathan Hui 1246 62. Identification and Authentication of IoT Devices by Alper Yegin 1248 63. Security Challenges For the Internet of Things by Tim Polk, and 1249 Sean Turner 1251 64. Application Communications Requirements for 'The Internet of 1252 Things' by Bob Dolin 1254 65. Interoperability Concerns in the Internet of Things by Jari 1255 Arkko 1257 66. Privacy in Ubiquitous Computing by Ivan Gudymenko, and Katrin 1258 Borcea-Pfitzmann 1260 67. The 10 Laws of Smart Object Security Design by Hannes 1261 Tschofenig, and Bernard Aboba 1263 68. Position Paper on "In-Network Object Cloud" Architecture and 1264 Design Goals by Alex Galis, and Stuart Clayman 1266 69. Temptations and Difficulties of Protocols for Smart Objects and 1267 the Internet by Alexandru Petrescu 1269 70. The Internet of Things - Challenge for a New Architecture from 1270 Problems by Gyu Myoung Lee, and Noel Crespi 1272 71. Garrulity and Fluff by Carsten Bormann, and Klaus Hartke 1274 These papers can be retrieved from: 1275 http://www.iab.org/about/workshops/smartobjects/papers/ 1277 The slides are available for download at the following webpage: 1278 http://www.iab.org/about/workshops/smartobjects/agenda.html 1280 Detailed meeting minutes are published here: 1281 http://www.iab.org/about/workshops/smartobjects/minutes.html 1283 Authors' Addresses 1285 Hannes Tschofenig 1286 Nokia Siemens Networks 1287 Linnoitustie 6 1288 Espoo 02600 1289 Finland 1291 Phone: +358 (50) 4871445 1292 Email: Hannes.Tschofenig@gmx.net 1293 URI: http://www.tschofenig.priv.at 1295 Jari Arkko 1296 Ericsson 1297 Jorvas 02420 1298 Finland 1300 Email: jari.arkko@piuha.net