.................
                                           |  Application  |
                                          .|  Service      |
                                       ,-` |  Provider     |
                                     .`    | b-example.com |
                                  ,-`      |_______________|
                                .`                          
          .................  ,-`   
          |  Application  |-` HTTPS
          |  Service      |   OAuth 2.0
          |  Provider     |   JSON
          |  example.com  |-,    
          |_______________|  '.            
               _,              `',                          
             ,'                   '.                      
          _,' CoAP or               `',    .................
        ,'   HTTP                      '.  |  Application  |
      -'                                 `'|  Service      |
   ,''''''''|                              |  Provider     |
   | Light  |                              | c-example.com |
   | Sensor |                              |_______________|
   |........'                                                                                                           
           

Figure 4: Backend Data Sharing Pattern

3. Re-Use Internet Protocols

When discussing the need for re-use of available standards vs. extending or re-designing protocols, it is useful to look back at the criteria for success of the Internet.

RFC 1958 [6] provides lessons from the early days of the Internet and says:

• "The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan",

and adds:

• "A good analogy for the development of the Internet is that of constantly renewing the individual streets and buildings of a city, rather than razing the city and rebuilding it."

Yet because building very small, battery-powered devices is challenging, it may be difficult to resist the temptation to build solutions tailored to a specific applications, or even to re-design networks from scratch to suit a particular application.

While developing consensus-based standards in an open and transparent process takes longer than developing proprietary solutions, the resulting solutions often remain relevant over a longer period of time.

RFC 1263 [4] considers protocol design strategy and the decision to design new protocols or to use existing protocols in a non-backward compatible way:

• "We hope to be able to design and distribute protocols in less time than it takes a standards committee to agree on an acceptable meeting time. This is inevitable because the basic problem with networking is the standardization process. Over the last several years, there has been a push in the research community for lightweight protocols, when in fact what is needed are lightweight standards. Also note that we have not proposed to implement some entirely new set of 'superior' communications protocols, we have simply proposed a system for making necessary changes to the existing protocol suites fast enough to keep up with the underlying change in the network. In fact, the first standards organization that realizes that the primary impediment to standardization is poor logistical support will probably win."

While [4] was written in 1991 when the standardization process was more lightweight than today, these thoughts remain relevant in smart object development.

Interestingly, a large range of already standardized protocols are relevant for smart object deployments. RFC 6272 [5], for example, made the attempt to identify relevant IETF specifications for use in smart grids.

Still, many commercial products contain proprietary or industry-specific protocol mechanisms and researchers have made several attempts to design new architectures for the entire Internet system. There are several architectural concerns that deserve to be highlighted:

Vertical Profiles

The discussions at the IAB workshop (see Section 3.1.2 of [1]) revealed the preference of many participants to develop domain-specific profiles that select a minimum subset of protocols needed for a specific operating environment. Various standardization organizations and industry fora are currently engaged in activities of defining their preferred profile(s). Ultimately, however, the number of domains where smart objects can be used is essentially unbounded. There is also an ever-evolving set of protocols and protocol extensions.

However, merely changing the networking protocol to IP does not necessarily bring the kinds of benefits that industries are looking for in their evolving smart object deployments. In particular, a profile is rigid, and leaves little room for interoperability among slightly differing, or competing technology variations. As an example, layer 1 through 7 type profiles do not account for the possibility that some devices may use different physical media than others, and that in such situations a simple router could still provide an ability to communicate between the parties.

Industry-Specific Solutions

The Internet Protocol suite is more extensive than merely the use of IP. Often significant benefits can be gained from using additional, widely available, generic technologies such as web services. Benefits from using these kinds of tools include access to a large available workforce, software, and education already geared towards employing the technology.

Tight Coupling

Many applications are built around a specific set of servers, devices, and users. However, often the same data and devices could be useful for many purposes, some of which may not be easily identifiable at the time that the devices are deployed.

As a result, the following recommendations can be made. First, while there are some cases where specific solutions are needed, the benefits of general-purpose technology are often compelling, be it choosing IP over some more specific communication mechanism, a widely deployed link-layer (such as wireless LAN) over a more specific one, web technology over application specific protocols, and so on.

However, when employing these technologies, it is important to embrace them in their entirety, allowing for the architectural flexibility that is built onto them. As an example, it rarely makes sense to limit communications to on-link or to specific media. Design your applications so that the participating devices can easily interact with multiple other applications.

4. The Deployed Internet Matters

Despite the applicability of the Internet Protocols for smart objects, picking the specific protocols for a particular use case can be tricky. As the Internet has evolved over time, certain protocols and protocol extensions have become the norm and others have become difficult to use in all circumstances.

Taking into account these constraints is particularly important for smart objects, as there is often a desire to employ specific features to support smart object communication. For instance, from a pure protocol specification perspective, some transport protocols may be more desirable than others. These constraints apply both to the use of existing protocols as well as designing new ones on top of the Internet Protocol stack.

The following list illustrates a few of those constraints, but every communication protocol comes with its own challenges.

In 2005, Fonseca, et al. [15] studied the usage of IP options-enabled packets in the Internet and found that overall, approximately half of Internet paths drop packets with options, making extensions using IP options "less ideal" for extending IP.

In 2010, Honda, et al. [17] tested 34 different home gateways regarding their packet dropping policy of UDP, TCP, DCCP, SCTP, ICMP, and various timeout behavior. For example, more than half of the tested devices do not conform to the IETF recommended timeouts for UDP, and for TCP the measured timeouts are highly variable, ranging from less than 4 minutes to longer than 25 hours. For NAT traversal of DCCP and SCTP, the situation is poor. None of the tested devices, for example, allowed establishing a DCCP connection.

In 2011, [16] tested the behavior of networks with regard to various TCP extensions: "From our results we conclude the middleboxes implementing layer 4 functionality are very common -- at least 25% of paths interfered with TCP in some way beyond basic firewalling."

Extending protocols to fulfill new uses and to add new functionality may range from very easy to difficult, as [2] explains in great detail. A challenge many protocol designers are facing is to ensure incremental deployability and interoperability with incumbent elements in a number of areas. In various cases, the effort it takes to design incrementally deployable protocols has not been taken seriously enough at the outset. RFC 5218 on "What Makes For a Successful Protocol?" [9] defines wildly successful protocols as protocols that are widely deployed beyond their envisioned use cases.

As these examples illustrate, protocol architects have to take developments in the greater Internet into account, as not all features can be expected to be usable in all environments. For instance, middleboxes [8] complicate the use of extensions in the basic IP protocols and transport-layers.

RFC 1958 [6] considers this aspect and says "... the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network." This statement is challenged more than ever with the perceived need to develop clever intermediaries interacting with dumb end devices. However, RFC 3724 [12] has this to say about this crucial aspect: "One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes." Even this statement will become challenged, as large numbers of devices are deployed and it indeed might be the case that changing those devices is hard. But RFC 4924 [7] adds that a network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.

5. Design for Change

How to embrace rapid innovation and at the same time accomplish a high level of interoperability is one of the key aspects for competing in the market place. RFC 1263 [4] points out that "protocol change happens and is currently happening at a very respectable clip. We simply propose [for engineers developing the technology] to explicitly deal with the changes rather keep trying to hold back the flood.".

In [18] Clark, et al. suggest to "design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive.". The term tussle refers to the process whereby different parties, which are part of the Internet milieu and have interests that may be adverse to each other, adapt their mix of mechanisms to try to achieve their conflicting goals, and others respond by adapting the mechanisms to push back.

In order to accomplish this, Clark, et al. suggest to

1. Break complex systems into modular parts, so that one tussle does not spill over and distort unrelated issues.
2. Design for choice to permit the different players to express their preferences. Choice often requires open interfaces.

The main challenge with the suggested approach is to predict how conflicts among the different players will evolve. Since tussles evolve over time, there will be changes to the architecture too. It is certainly difficult to pick the right set of building blocks and to develop a communication architecture that will last a long time, and many smart object deployments are envisioned to be rather long-lived.

Luckily, the design of the system does not need to be cast in stone during the design phase. It may adjust dynamically since many of the protocols allow for configurability and dynamic discovery. But ultimately software update mechanisms may provide the flexibility needed to deal with more substantial changes.

A solid software update mechanism is needed not only for dealing with the changing Internet communication environment and for interoperability improvements but also for adding new features and for fixing security bugs. This approach may appear to be in conflict with classes of severely restricted devices since, in addition to a software update mechanism, spare flash and RAM capacity is needed. It is, however, a tradeoff worth thinking about since better product support comes with a price.

As technology keeps advancing, the constraints that the technology places on devices evolve as well. Microelectronics became more capable as time goes by, sometimes making it even possible for new devices to be both less expensive and more capable than their predecessors. This trend can, however, be in some cases offset by the desire to embed communications technology in even smaller and cheaper objects. But it is important to design communications technology not just for today's constraints, but also tomorrow's. This is particularly important since the cost of a product is not only determined by the cost of hardware but also by the cost of writing custom protocol stacks and embedded system software.

Software updates are common in operating systems and application programs today. Without them, most devices would pose a latent risk to the Internet at large. Arguably, the JavaScript-based web employs a very rapid software update mechanism with code being provided by many different parties (i.e., by websites loaded into the browser or by smart phone apps).

6. Security Considerations

Section 3.3 of [1] reminds us about the IETF work style regarding security:

• In the development of smart object applications, as with any other protocol application solution, security must be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [10], and RFC 4101 [11], apply also to the smart object space.

In the IETF, security functionality is incorporated into each protocol as appropriate, to deal with threats that are specific to them. It is extremely unlikely that there is a one-size-fits-all security solution given the large number of choices for the 'right' protocol architecture (particularly at the application layer). For this purpose, [5] offers a survey of IETF security mechanisms instead of suggesting a preferred one.

A more detailed security discussion can be found in the report from the 'Smart Object Security' workshop [14] that was held prior to the IETF meeting in Paris, March 2012.

As current attacks against embedded systems demonstrate, many of the security vulnerabilities are quite basic and remind us about the lessons we should have learned in the late 90's: software has to be tested properly, it has to be shipped with a secure default configuration (which includes no default accounts, no debugging interfaces enabled, etc.), and software and processes need to be available to provide patches. While these aspects are typically outside the realm of standardization, they are nevertheless important to keep in mind.

7. Privacy Considerations

This document mainly focuses on an engineering audience, i.e., those who are designing smart object protocols and architecture. Since there is no value-free design, privacy-related decisions also have to be made, even if they are just implicit in the re-use of certain technologies. RFC 6973 [3] was written as guidance specifically for that audience and it is also applicable to the smart object context.

For those looking at privacy from a deployment point of view, the following additional guidelines are suggested:

Transparency:

Transparency of data collection and processing is key to avoid unpleasant surprises for owners and users of smart objects. Users and impacted parties must, except in rare cases, be put in a position to understand what items of personal data concerning them are collected and stored, as well for what purposes they are sought.

Data Quality:

Smart objects should only store personal data that is adequate, relevant and not excessive in relation to the purpose(s) for which they are processed. The use of anonymized data should be preferred wherever possible.

Data Access:

Before deployment starts, it is necessary to consider who can access personal data collected by smart objects and under which conditions. Appropriate and clear procedures should be established in order to allow data subjects to properly exercise their rights.

Data Security:

Standardized data security measures to prevent unlawful access, alteration or loss of smart object data need to be defined and deployed. Robust cryptographic techniques and proper authentication frameworks have to be used to limit the risk of unintended data transfers or unauthorized access.

8. IANA Considerations

This document does not require actions by IANA.

9. Acknowledgements

We would like to thank the participants of the IAB Smart Object workshop for their input to the overall discussion about smart objects.

Furthermore, we would like to thank Jan Holler, Patrick Wetterwald, Atte Lansisalmi, Hannu Flinck, Joel Halpern, Bernard Aboba, and Markku Tuohino for their review comments.

10. Informative References

[1]	Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, April 2012.
[2]	Carpenter, B., Aboba, B. and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.
[3]	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.
[4]	O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.
[5]	Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011.
[6]	Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[7]	Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[8]	Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[9]	Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[10]	Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[11]	Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[12]	Kempf, J., Austein, R. and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[13]	Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[14]	Gilger, J. and H. Tschofenig, "Report from the 'Smart Object Security Workshop', March 23, 2012, Paris, France", Internet-Draft draft-gilger-smart-object-security-workshop-02, October 2013.
[15]	Fonseca, R., Porter, G., Katz, R., Shenker, S. and I. Stoica, "IP options are not an option, Technical Report UCB/EECS", 2005.
[16]	Honda, M., Nishida, Y., Greenhalgh, A., Handley, M. and H. Tokuda, "Is it Still Possible to Extend TCP? In Proc. ACM Internet Measurement Conference (IMC), Berlin, Germany", Nov 2011.
[17]	Eggert, L., "An experimental study of home gateway characteristics, In Proceedings of the '10th annual conference on Internet measurement'", 2010.
[18]	Clark, D., Wroslawski, J., Sollins, K. and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet, In Proc. ACM SIGCOMM", 2002.

Authors' Addresses