Architectural Considerations in Smart Object Networking
draft-tschofenig-smart-object-architecture-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Hannes Tschofenig , Jari Arkko , Dave Thaler , Danny R. McPherson | ||
| Last updated | 2012-07-09 | ||
| Replaced by | draft-iab-smart-object-architecture, RFC 7452 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tschofenig-smart-object-architecture-00
Network Working Group H. Tschofenig
Internet-Draft J. Arkko
Intended status: Informational D. Thaler
Expires: January 10, 2013 D. McPherson
July 9, 2012
Architectural Considerations in Smart Object Networking
draft-tschofenig-smart-object-architecture-00.txt
Abstract
Following the theme "Everything that can be connected will be
connected", engineers and researchers designing smart object networks
need to decide how to achieve this in practice. How can different
forms of embedded and constrained devices be interconnected? How can
they employ and interact with the currently deployed Internet? This
memo discusses smart objects and some of the architectural choices
involved in designing smart object networks and protocols that they
use.
The document is being discussed at
https://www.ietf.org/mailman/listinfo/architecture-discuss
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Tschofenig, et al. Expires January 10, 2013 [Page 1]
Internet-Draft Smart Object Architectural Considerations July 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Re-Use and Deployment Reality . . . . . . . . . . . . 5
3. The Need for Standards . . . . . . . . . . . . . . . . . . . . 7
3.1. Internet Protocols for Proprietary Protocol
Developments . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Interoperability . . . . . . . . . . . . . . . . . . . . . 12
3.3. Design for Change . . . . . . . . . . . . . . . . . . . . 14
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Tschofenig, et al. Expires January 10, 2013 [Page 2]
Internet-Draft Smart Object Architectural Considerations July 2012
1. Introduction
In RFC 6574 [1], we refer to smart objects as devices with
constraints on energy, bandwidth, memory, size, cost, etc. This is a
fuzzy definition, as there is clearly a continuum in device
capabilities and there is no hard line to draw between devices that
can be classified as smart objects and those that can't.
Following the theme "Everything that can be connected will be
connected", engineers and researchers designing smart object networks
need to address a number of questions. How can different forms of
embedded and constrained devices be interconnected? How can they
employ and interact with the currently deployed Internet?
These questions have been discussed at length. For instance, when
the Internet Architecture Board (IAB) scheduled a workshop on Smart
Objects, the IETF community was asked to develop views on how
Internet protocols can be utilized by smart objects. The workshop
participants contributed their views on the topic and a report was
published [1].
This memo discusses smart objects and some of the architectural
choices involved in designing smart object networks and protocols
that they use. The main issues that we focus on are interaction with
the Internet, the use of Internet protocols for these applications,
models of interoperability, and approach to standardization.
In drawing conclusions from the prior IETF work and from the IAB
workshop it is useful to look back at the criteria for success of the
Internet. Luckily, various publications provide valuable insight
into the history. Many of the statements are very much applicable to
the discussion on smart objects. RFC 1958 [2] says:
"The Internet and its architecture have grown in evolutionary
fashion from modest beginnings, rather than from a Grand Plan."
It goes on to add:
"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."
Internet protocols are immediately relevant for any smart object
development and deployment. However, building very small, often
battery-operated devices is challenging. It is difficult to resist
the temptation to build specific solutions tailored to a particular
application, or to re-design everything from scratch. Yet, due to
network effects, the case for using the Internet Protocol(s) and
Tschofenig, et al. Expires January 10, 2013 [Page 3]
Internet-Draft Smart Object Architectural Considerations July 2012
other generic technology is compelling.
This writeup describes the IAB's view on these issues. The document
is being discussed at
https://www.ietf.org/mailman/listinfo/architecture-discuss.
Tschofenig, et al. Expires January 10, 2013 [Page 4]
Internet-Draft Smart Object Architectural Considerations July 2012
2. Protocol Re-Use and Deployment Reality
We see the attempt for re-design in many places; sometimes only at
the marketing level but often also in ignorance of what had been
developed in the past.
The IETF has produced a number of important specifications that make
the Internet work. The Internet protocols are relevant for any smart
object development and deployment. In the context of one use case of
smart objects, the smart grids and smart meters in particular, RFC
6272 "Internet Protocols for the Smart Grid" [3] identifies a range
of IETF protocols that can be utilized by those people seeking
guidance on how to construct an appropriate Internet Protocol Suite
profile for Smart Grids. The wide range of protocols listed in that
document illustrates the view of the authors about how much can be
re-used.
Picking the right protocols for a specific use case can be tricky.
As the Internet has evolved over time, certain protocols and protocol
extensions cannot be utilized in all circumstances. The following
list illustrates a few of those challenges, and every communication
protocol comes with its own challenges. Protocol designers need to
be aware of the deployment challenges; it is not enough to just look
at the specifications.
In 2005, [4] 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, [5] 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, [6] 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 [7] investigates in great
Tschofenig, et al. Expires January 10, 2013 [Page 5]
Internet-Draft Smart Object Architectural Considerations July 2012
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.
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 [2] 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 but we have to keep in mind what RFC 3724 [9] has 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." RFC 4924 [10] 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.
Tschofenig, et al. Expires January 10, 2013 [Page 6]
Internet-Draft Smart Object Architectural Considerations July 2012
3. The Need for Standards
New smart object applications are developed every day; in many cases
they are created using standardized Internet technology even though
various components cannot easily be replaced by third party
components. Even where a common underlying technology (such as IP)
is used, current smart object networks often have challenges related
to interoperability of the entire protocol stack, including
application behavior. It is of strategic importance to make a
conscious decision about the desired level of interoperability and
where the points of interconnection are.
It is valuable to look back at earlier IETF publications, for
example, RFC 1263 [11] considers different protocol design strategies
and makes an interesting observation about the decision to design new
protocols from scratch or to design them in a non-backwards
compatible way based on existing protocols:
"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 [11] was written in 1991 when the standardization process in
the Internet community was far more lightweight than today (among
other reasons, because fewer stakeholders were interested in
participating in the standards process) it is remarkable to read
these thoughts since they are even more relevant today. This is
particularly true for the smart object environment.
Regardless of how hard we work on optimizing the standard process,
designing systems in an open and transparent consensus process where
many parties participate takes longer than letting individual
stakeholders develop their own proprietary solutions. Therefore, it
is important to make architectural decisions that keep a good balance
between proprietary developments vs. standardized components.
While RFC 1263 [11] certainly provides good food for thought, it also
gives recommendations that may not always be appropriate for the
Tschofenig, et al. Expires January 10, 2013 [Page 7]
Internet-Draft Smart Object Architectural Considerations July 2012
smart object space, such as the preference for a so-called
evolutionary protocol design where new versions of the protocols are
allowed to be non-backwards compatible and all run independently on
the same device. RFC 1263 adds:
"... the only real disadvantage of protocol evolution is the
amount of memory required to run several versions of the same
protocol. Fortunately, memory is not the scarcest resource in
modern workstations (it may, however, be at a premium in the BSD
kernel and its derivatives). Since old versions may rarely if
ever be executed, the old versions can be swapped out to disk with
little performance loss. Finally, since this cost is explicit,
there is a huge incentive to eliminate old protocol versions from
the network."
Even though it is common practice today to run many different
software applications that have similar functionality (for example,
multiple Instant Messaging clients) in parallel it may indeed not be
the most preferred approach for smart objects, which may have severe
limitations regarding RAM, flash memory, and also power constraints.
To deal with exactly this problem, 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). In [12] Arkko, et al. explain how the complexity of such
a profile heavily depends on the chosen communication architecture
and discusses one such profile with limited communication
capabilities, which also translates into a small code size.
Ultimately, however, the number of domains where smart objects can be
used is essentially unbounded and so too are the ever-evolving
protocols and protocol extensions. Saying "no" to a new protocol
stack that only differs in minor ways may be appropriate but could be
interpreted as blocking innovation and, as RFC 1263 [11] describes it
nicely "In the long term, we envision protocols being designed on an
application by application basis, without the need for central
approval.". "Central approval" here refers to the approval process
that happens in a respective standards developing organization.
So, how can we embrace rapid innovation with distributed developments
and at the same time accomplish a high level of interoperability?
Clearly, standardization of every domain-specific profile will not be
the solution. Many domain-specific profiles are optimizations that
will be already obsoleted by technological developments (e.g., new
protocol developments), new security threats, new stakeholders
Tschofenig, et al. Expires January 10, 2013 [Page 8]
Internet-Draft Smart Object Architectural Considerations July 2012
entering the system or changing needs of existing stakeholders, new
business models, changed usage patterns, etc. RFC 1263 [11] states
the problem succinctly: "The most important conclusion of this RFC is
that protocol change happens and is currently happening at a very
respectable clip. We simply propose to explicitly deal with the
changes rather keep trying to hold back the flood."
Even worse, different stakeholders that are part of the Internet
milieu have interests that may be adverse to each other, and these
parties each vie to favor their particular interests. In [13],
Clark, et al. call this process 'the tussle' and ask the important
question "How can we, as designers, build systems with desired
characteristics and improve the chances that they come out the way we
want?". In an attempt to answer that question, the authors of [13]
develop a high-level principle, which is not tailored to smart object
designs but to Internet protocol develop in general:
"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."
In order to accomplish this, Clark, et al. suggest to
1. Break complex systems into modular parts.
2. Design for choice.
These are valid guidelines, and many protocols standardized in the
IETF have taken exactly this approach, namely to identify building
blocks that can be used in a wide variety of deployments. Others
then put the building blocks together in a way that suits their
needs. There are, however, limits to this approach. Certain
building blocks are only useful in a limited set of architectural
variants and producing generic building blocks requires a good
understanding of the different architectural variants and often
limits the ability to optimize. Sometimes the value of an individual
building block is hard for others to understand without providing the
larger context, which requires at least to illustrate one deployment
variant that comes with a specific architectural setup. That said,
it is also critical to consider systemic interdependencies between
the set of elements that constitute a system, lest they impose
constraints that weren't envisioned at the outset.
Since many Internet protocols are used as building blocks by other
organizations or in deployments that may have never been envisioned
by the original designs, one can argue that this approach has been
Tschofenig, et al. Expires January 10, 2013 [Page 9]
Internet-Draft Smart Object Architectural Considerations July 2012
fairly successful. It may, however, not lead to the level of
interoperability many desire: they want interoperability of the
entire system rather than interoperability at a specific protocol
level. Consequently, an important architectural question arises,
namely "What level of interoperability should Internet protocol
engineers aim for?"
In the diagrams below, we illustrate a few interoperability scenarios
with different interoperability needs. Note that these are highly
simplified versions of what protocol architects are facing, since
there are often more parties involved in a sequence of required
protocol exchanges, and the entire protocol stack has to be
considered - not just a single protocol layer. As such, the required
coordination and agreement between the different stakeholders is
likely to be far more challenging than illustrated. We do, however,
believe that these figures illustrate that the desired level of
interoperability needs to be carefully chosen.
3.1. Internet Protocols for Proprietary Protocol Developments
Figure 1 shows a typical deployment of many Internet applications: an
application service provider (example.com in our illustration) wants
to make an HTTP-based protocol interface available to its customers.
Example.com allows their customers to upload sensor measurements
using a RESTful HTTP design. Customers need to write code for their
embedded systems to make use of the HTTP-based protocol interface
(and keying material for authentication and authorization of the
uploaded data). These applications work with the servers operated by
Example.com and with nobody else; there is no interoperability with
third parties (at the application layer at least), i.e., Alice, a
customer of Example.com, cannot use their embedded system which was
programmed to use the protocol interface for Example.com with another
service provider without re-writing at least parts of her embedded
software. Nevertheless, Example.com re-use standardized protocol
components to speed-up the process of developing their software,
which is certainly useful from a time-to-market and cost efficiency
point of view. For example, Example.com relies on HTTP and offers
JSON to encode sensor data. Example.com will also have to rely at
least on IP to have their customers access the Internet in order to
reach their server farm.
Tschofenig, et al. Expires January 10, 2013 [Page 10]
Internet-Draft Smart Object Architectural Considerations July 2012
.................
| Application |
| Service |
| Provider |
| Example.com |
|_______________|
_, .
,' `. Proprietary
_,' `. Protocol offered
,' `._ by Example.com
-' -
,'''''''''''''| ,''''''''| Sensors
| Temperature | | Light | operated by
| Sensor | | Sensor | customers of
|.............' |........' Example.com
Figure 1: Proprietary Deployment
Clearly, the above scenario does not provide a lot of
interoperability even though standardized Internet protocols are re-
used.
Since example.com is focused on storage of sensor data and not on the
actually processing it offers an HTTP-based protocol interface to
others to get access to the uploaded sensor data. In our example,
b-example.com and c-example.com are two of such companies that make
use of this functionality in order to provide data visualization and
data mining computations. Example.com again uses standardized
protocols (such as RESTful HTTP design combined with OAuth) for
offering access but overall the entire protocol stack is not
standardized.
Tschofenig, et al. Expires January 10, 2013 [Page 11]
Internet-Draft Smart Object Architectural Considerations July 2012
.................
| Application |
.| Service |
,-` | Provider |
.` | b-example.com |
,-` |_______________|
.`
................. ,-`
| Application |-` Proprietary
| Service | Protocol
| Provider |
| example.com |-,
|_______________| '.
_, `',
Proprietary ,' '. ...
Protocol _,' `', .................
,' '. | Application |
-' `'| Service |
,''''''''| | Provider |
| Light | | c-example.com |
| Sensor | |_______________|
|........'
Figure 2: Backend Interworking
3.2. Interoperability
In contrast to the scenario described in Section 3.1 we illustrate a
sensor where two devices developed by independent manufacturers are
desired to interwork. This is shown in Figure 3. To pick an example
from [1], consider a light bulb that talks to a light switch with the
requirement that each may be manufactured by a different company,
represented as company A and B.
_,,,, ,,,,
/ -'`` \
| |
\ |
/ \
,''''''''| / Standardized . ,''''''''|
| Light | ------|---Protocol-------\------| Light |
| Bulb | . | | Switch |
|........' `'- / |........'
\ _-...-`
Manufacturer `. ,.' Manufacturer
A ` B
Tschofenig, et al. Expires January 10, 2013 [Page 12]
Internet-Draft Smart Object Architectural Considerations July 2012
Figure 3: Interoperability between two random devices
In order for this scenario to work manufacturer A, B, and probably
many other manufacturers f lightbulbs and light switches need to get
together and agree on the protocol stack they would like to use. Let
us assume that they do not want any manual configuration by the user
to happen and that these devices should work in a typical home
network this consortium needs to make a decision about the following
protocol design aspects:
o Which physical layer should be supported?
o Which IP version should be used?
o Which IP address configuration mechanism(s) are integrated into
the device?
o Which communication architecture shall be supported? (see [12])
o Whether there is a need for a service discovery mechanism to allow
users to discover light bulbs they have in their home or office.
o Which transport layer protocol is used for conveying the sensor
readings/sensor commands? (e.g., UDP)
o Which application layer protocol is used? (for example, CoAP)
o How are requests encoded? (e.g., as URIs) How is the return data
encoded? (e.g., JSON)
o What data model is used for expressing the different light levels?
(e.g., [14])
o Finally, some thoughts will have to be spent about the security
architecture. This includes questions like: what are the
ssecurity threats? What security services need to be provided to
deal with the identified threats? Where do the security
credentials come from? At what layer(s) in the protocol stack
should the security mechanism reside?
This list is not meant to be exhaustive but aims to illustrate that
for every usage scenario many design decisions will have to be made
in order to accommodate the constrained nature of a specific device
in a certain usage scenario. Standardizing such a complete solution
to accomplish a full level of interoperability between two devices
manufactured by different vendors will take time.
Tschofenig, et al. Expires January 10, 2013 [Page 13]
Internet-Draft Smart Object Architectural Considerations July 2012
3.3. Design for Change
With the description in Section 3.1 and in Section 3.2 we present two
extreme cases of interoperability. To "design for varation in
outcome", as postulated by [13], the design of the system does not
need to be cast in stone during the standardization process but may
be changed during run-time using software updates.
For many reasons, not only for adding new functionality, it can be
said that many smart objects will need a solid software update
mechanism. Note that adding new functionality to smart objects may
not be possible for certain classes of constrained devices, namely
those with severe memory limitations. As such, a certain level of
sophistication from the embedded device is assumed in this section.
Software updates are common in operating systems and application
programs today. Arguably, the Web today employs a very successful
software update mechanism with code being provided by many different
parties (i.e., by websites loaded into the browser or by the Web
application). While JavaScript (or the proposed successor, Dart) may
not be the right choice of software distribution for smart objects,
and other languages such as embedded eLua [15] may be more
appropriate, the basic idea of offering software distribution
mechanisms may present a middleground between the two extreme
interoperability scenario presented in this section.
Tschofenig, et al. Expires January 10, 2013 [Page 14]
Internet-Draft Smart Object Architectural Considerations July 2012
4. Recommendations
Based on the previous description, we developed suggestions for
different audiences.
For engineers in the IETF, we suggest the following. [[Comment.1:
DT: Some of the items below dont appear to be targeted only at the
IETF.]]
o The IETF has produced a number of building blocks as well as
architectural specifications that have provided good guidance for
implementers and the deployment community. We encourage
continuing the development of building blocks that are usable in a
number of deployment scenarios. A number of the recommendations
in [1] provide a good starting point. We do, however, encourage
protocol engineers to document the interworking of various
protocols in at least one architectural variant to ensure that the
indivual parts indeed fit together without creating gaps or
conflicts. Regarding architectural documents, we observe that
their number in the IETF has increased over the years. We are
convinced that focusing on a subset of the protocol stack will be
of increased importance for a smart object environment.
[[Comment.2: DT: I dont know what it means to focus on a subset,
so I'm not convinced.]] Therefore, we suggest to separate
profiles that describe network-layer from application-layer
protocol interaction due to the different speed of innovation,
very much in the same style of the split between RFC 1122
"Requirements for Internet Hosts - Communication Layers" [16] and
RFC 1123 "Requirements for Internet Hosts - Application and
Support" [17]. The application space has historically seen faster
innovation cycles, and separating network-layer from application-
layer functionality is therefore recommended. In general, we
suggest avoiding standardizing complete protocol stacks. The
likelihood that those will be outdated by the time standardization
is finished is far too high, particularly with application-layer
standards.
o As a starting point aim for an interoperability model that does
not require component to be offered by different vendors. An
architecture that requires fewer interoperability components has a
faster time to market.
o Even in the smart object space, try to aim for a generic design
instead of optimizing too early. Note that some optimizations
will only be possible in an architectural context, rather than at
the level of an individual protocol.
Tschofenig, et al. Expires January 10, 2013 [Page 15]
Internet-Draft Smart Object Architectural Considerations July 2012
o We encourage engineers to take existing deployment constraints
into consideration to allow for a smooth transition path. This
requires a clear understanding of the deployment status and also
an analysis of the incentives of the different stakeholders.
o Over time, a wide range of middleboxes have been introduced to the
Internet protocol suite. Introducing middleboxes in smart object
deployments has been proposed many times but their usage may turn
out to be dangerous. We recommend carefully investigaing whether
new features introduced can be supported without any change to
middleboxes. This investigation will likely have to go beyond
pure specification work, and may require extensive
interoperability testing and a clearly articulated extensiblity
story. The guidance in [7] is relevant to this discussion. The
added architectural complexity, including security and privacy
challenges, has to be a subject of design considerations.
Middleboxes are often operated by parties other than the
communication endpoints. As such, they introduce additional
stakeholders into the architecture that often want to be involved
when new features are introduced and as such may slow down the
ability to innovate at a high speed.
For researchers we offer the following suggestions:
o We believe that the area of mobile code distribution provides a
promising way to solve a range of security problems and the
ability to deliver new functionality. The rich experience from
the Web environment can be taken into consideration as a starting
point.
o We encourage funding of software projects that produce libraries
and open source code for smart object operating systems. The
success of many IETF protocols can be attributed to the
availability of running code.
o We also propose to conduct ongoing research of the deployment
status of various Internet protocols. These investigations
provide a snapshot for further interactions with the operator
community to ensure that IETF protocols can indeed be deployed in
today's Internet and may stimulate discussions on how to deal with
unpleasant deployment artifacts.
Tschofenig, et al. Expires January 10, 2013 [Page 16]
Internet-Draft Smart Object Architectural Considerations July 2012
5. Security Considerations
Section 3.3 of [1] reminds us about the IETF workstyle 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 [18], and
RFC 4101 [19], 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, [3] 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. that was held prior to the IETF
meeting in Paris, March 2012. [[Comment.3: The workshop report has
not been published yet. It will happen soon.]]
Tschofenig, et al. Expires January 10, 2013 [Page 17]
Internet-Draft Smart Object Architectural Considerations July 2012
6. Privacy Considerations
In 1980, the Organization for Economic Co-operation and Development
(OECD) published eight Guidelines on the Protection of Privacy and
Trans-Border Flows of Personal Data [20], which are often referred to
as Fair Information Practices (FIPs). The FIPs, like other privacy
principles, are abstract in their nature and have to be applied to a
specific context.
From a technical point of view, many smart object designs are not
radically different from other application design. Often, however,
the lack of a classical user interface, such as is used on a PC or a
phone, that allows users to interact with the devices in a convenient
and familiar way creates problems to provide users with information
about the data collection, and to offer them the ability to express
consent. Furthermore, in some verticals (e.g., smart meter
deployments) users are not presented with the choice of voluntarily
signing up for the service but deployments are instead mandated
through regulation. Therefore, these users have no right to consent;
a right that is core to many privacy principles including the FIPs.
In other cases, the design is more focused on dealing with privacy at
the level of a privacy notice rather than by building privacy into
the design of the system, which [21] asks engineers to do.
The interoperability models described in this document highlight that
standardized interfaces are not needed in all cases, nor that this is
even desirable. Depending on the choice of certain underlying
technologies, various privacy problems may be inherited by the upper-
layer protocols and therefore difficult to resolve as an
afterthought. Many smart objects leave users little ability for
enabling privacy-improving configuration changes. Technologies exist
that can be applied also to smart objects to involve users in
authorization decisions before data sharing takes place.
As a summary, for an Internet protocol architect, the guidelines
described in [21] are applicable. For those looking at privacy from
a deployment point of view, the following additional guidelines are
suggested:
Transparency: The data processing should be completely transparent
to the smart object owner and user(s). Users must, except in rare
exceptional cases, be put in a position to easily understand what
items of personal information concerning them are collected and
stored, as well for what purposes they are sought.
Tschofenig, et al. Expires January 10, 2013 [Page 18]
Internet-Draft Smart Object Architectural Considerations July 2012
Data Quality: Smart objects should only store personal data which
are adequate, relevant and not excessive in relation to the
purpose(s) for which they are processed. The use of anonymised
data should be preferred wherever possible.
Data Access: Before deployment starts, it is necessary to consider
who can access the personal data recorded in smart objects and
under which conditions, particularly with regard to data subjects,
to whom (in principle) full and free access to his/her own data
should be recognised. Appropriate and clear procedures should be
established in order to allow data subjects to properly exercise
their rights. A privacy and data protection impact assessment is
considered a useful tool for this analysis.
Data Security: Standardized data security measures to prevent
unlawful access, alteration or loss of smart object data need to
be defined and universally adopted. Robust cryptographic
techniques and proper authentication frameworks should be used to
limit the risk of unintended data transfers or harmful attacks.
The end-user should be able to verify, in a straight-forward
manner, that smart objects are in full compliance with these
standards.
Tschofenig, et al. Expires January 10, 2013 [Page 19]
Internet-Draft Smart Object Architectural Considerations July 2012
7. Summary
Interconnecting smart objects with the Internet creates exciting new
use cases and engineers are eager to play with small and constrained
devices. With various standardization efforts ongoing and the
impression that smart objects require a new Internet Protocol and
many new extensions, we would like to provide a cautious warning. We
believe that protocol architects are best served by the following
high level guidance:
Re-use Internet protocols. Most, if not all, smart object
deployments should employ the Internet protocol suite. The
Internet protocols can be applied to almost any environment, and
the rest of the suite can be tailored for the specific needs.
The deployed Internet matters. When connecting smart objects to the
Internet, take existing deployment into consideration to avoid
unpleasant surprises. Assuming an ideal, clean-slate deployments
is, in many cases, far too opimistic since already available
deployed infrastructure is sticky.
Decide about the level of interoperability. Offering
interoperability between every entity in an architecture may be an
ideal situation for a standards person but comes with a certain
cost. As such, starting with a less ambigious standardization
goal may be appropriate, particularly for early deployments.
Don't optimize too early. The constrained nature of smart objects
invites engineers to invent each and every technique to optimize
protocols for special use cases. While some of these
optimizations may be necessary, many of them make the overal
design complex and the outcome less usable for the generic use
case.
Tschofenig, et al. Expires January 10, 2013 [Page 20]
Internet-Draft Smart Object Architectural Considerations July 2012
8. IANA Considerations
This document does not require actions by IANA.
Tschofenig, et al. Expires January 10, 2013 [Page 21]
Internet-Draft Smart Object Architectural Considerations July 2012
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 Atte Lansisalmi, Hannu Flinck,
Joel Halpern, and Markku Tuohino for their review comments.
Tschofenig, et al. Expires January 10, 2013 [Page 22]
Internet-Draft Smart Object Architectural Considerations July 2012
10. Informative References
[1] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, April 2012.
[2] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[3] Baker, F. and D. Meyer, "Internet Protocols for the Smart
Grid", RFC 6272, June 2011.
[4] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica,
"IP options are not an option, Technical Report UCB/EECS",
2005.
[5] Eggert, L., "An experimental study of home gateway
characteristics, In Proceedings of the '10th annual conference
on Internet measurement'", 2010.
[6] 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.
[7] Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions",
draft-iab-extension-recs-17 (work in progress), June 2012.
[8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
[9] 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.
[10] Aboba, B. and E. Davies, "Reflections on Internet
Transparency", RFC 4924, July 2007.
[11] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991.
[12] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo,
"Implementing Tiny COAP Sensors",
draft-arkko-core-sleepy-sensors-01 (work in progress),
July 2011.
[13] Clark, D., Wroslawski, J., Sollins, K., and R. Braden, "Tussle
in Cyberspace: Defining Tomorrow's Internet, In Proc. ACM
Tschofenig, et al. Expires January 10, 2013 [Page 23]
Internet-Draft Smart Object Architectural Considerations July 2012
SIGCOMM", 2002.
[14] Jennings, C., Shelby, Z., and J. Arkko, "Media Types for Sensor
Markup Language (SENML)", draft-jennings-senml-08 (work in
progress), January 2012.
[15] "Embedded Lua Project", 2012.
[16] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[17] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
[18] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[19] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005.
[20] Organization for Economic Co-operation and Development, "OECD
Guidelines on the Protection of Privacy and Transborder Flows
of Personal Data", available at (September 2010) , http://
www.oecd.org/EN/document/
0,,EN-document-0-nodirectorate-no-24-10255-0,00.html, 1980.
[21] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and J.
Morris, "Privacy Considerations for Internet Protocols",
draft-iab-privacy-considerations-02 (work in progress),
March 2012.
[22] Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson,
"Trends in Web Applications and the Implications on
Standardization", draft-tschofenig-post-standardization-02
(work in progress), May 2012.
[23] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, July 2008.
[24] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-10 (work in
progress), June 2012.
[25] Bormann, C., "Guidance for Light-Weight Implementations of the
Internet Protocol Suite", draft-bormann-lwig-guidance-01 (work
in progress), January 2012.
[26] Rosenberg, J., "UDP and TCP as the New Waist of the Internet
Tschofenig, et al. Expires January 10, 2013 [Page 24]
Internet-Draft Smart Object Architectural Considerations July 2012
Hourglass", draft-rosenberg-internet-waist-hourglass-00 (work
in progress), February 2008.
Tschofenig, et al. Expires January 10, 2013 [Page 25]
Internet-Draft Smart Object Architectural Considerations July 2012
Authors' Addresses
Hannes Tschofenig
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jari Arkko
Jorvas 02420
Finland
Email: jari.arkko@piuha.net
Dave Thaler
US
Email: dthaler@microsoft.com
Danny McPherson
US
Email: danny@tcb.net
Tschofenig, et al. Expires January 10, 2013 [Page 26]