One document matched: draft-iab-smart-object-architecture-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<rfc category="info" ipr="trust200902" docName="draft-iab-smart-object-architecture-04.txt">
<front>
<title abbrev="Smart Object Architectural Considerations">Architectural Considerations in Smart Object Networking</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>Austria</country>
</postal>
<phone></phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization/>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization/>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>dthaler@microsoft.com</email>
</address>
</author>
<author initials="D." surname="McPherson" fullname="Danny McPherson">
<organization/>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>US</country>
</postal>
<email>danny@tcb.net</email>
</address>
</author>
<date year="2014"/>
<keyword>Internet-Draft</keyword>
<keyword>IAB Statement</keyword>
<keyword>Smart Objects</keyword>
<abstract>
<t>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.</t>
<!--
<t>How can different
forms of embedded and constrained devices be interconnected to the Internet? How can
they employ and interact with the currently deployed Internet? This
memo discusses architectural design patterns for connecting smart objects to the
Internet.
</t>
-->
<t>This document offers guidance to engineers designing Internet connected smart objects.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>RFC 6574 <xref target="RFC6574"/> refers to smart objects (also called
"Things", as in Internet of Things in other publications) 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 run Internet Protocols and those
that can't.
</t>
<!-- and attempts to be more specific based on a device
classification, as done in Section 2.1 of <xref
target="I-D.ietf-lwig-guidance"/>, may not be suitable in
all cases either. Clearly. Understanding this unclear boundary
between "regular" Internet devices (like laptops, netbooks,
phones, routers, home gateways, or desktops) connected to the
Internet and other forms of devices (like sensors) is important
to understand our line of argument.-->
<!--
<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?
</t>
<t>These questions have been discussed at length. For instance, when
the Internet Architecture Board (IAB) scheduled a workshop on Smart
Objects, the community was asked to develop views on how
Internet protocols can be utilized by smart objects. A report of the
discussions and the position papers received for this workshop have
been published <xref target="RFC6574"/>.
</t>
-->
<t>Interconnecting smart objects with the Internet creates exciting new
innovative use cases and products. An increasing number of products put
the Internet Protocol suite on smaller and smaller devices and offer the
ability to process, visualize, and gain new insight from the collected
sensor data. The network effect can be increased if the data collected
from many different devices can be combined.</t>
<t>Developing embedded systems is a complex task and designing Internet
connected smart objects is even harder since it “requires expertise with
Internet protocols in addition to software programming
and hardware skills. To simply the development task, and thereby to
lower the cost of developing new products and prototypes, we believe
that re-use of prior work is essential. Therefore, we provide high-level
guidance on the use of Internet technology for the development of smart
objects.</t>
<t>
<list style="hanging">
<t hangText="Utilize Existing Design Patterns"><vspace blankLines="1"/>Design
patterns are generally reusable solutions to a commonly occurring
design problem. Existing smart object deployments show patterns
that can be re-used by engineers with the benefit of lowering the
design effort. Individual patterns also have an implication on the
required interoperability between the different entities. Depending
on the desired functionality, already existing patterns can be re-used
and adjusted. <xref target="patterns"/> talks about various
design patterns.
</t>
<t hangText="Re-Use Internet Protocols"><vspace blankLines="1"/> Most,
if not all, smart object deployments can make use of the already
standardized Internet protocol suite. The Internet protocols can be
applied to almost any environment due to their generic design, and
typically offer plenty of potential for re-configuration,
which allows the them to be tailored for the specific needs.
<xref target="reuse"/> discusses this topic.
</t>
<t hangText="The Deployed Internet matters"><vspace blankLines="1"/>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 optimistic since
the already deployed infrastructure is convenient to use. In
<xref target="deployed"/> we highlight the importance of this topic.
</t>
<t hangText="Design for Change"><vspace blankLines="1"/>The Internet
infrastructure, the applications and preferred building blocks evolve
over time. Especially long-lived smart object deployments need to take
this change into account and <xref target="change"/> is dedicated to
that topic.</t>
<!--
<t hangText="Design for Tomorrow"><vspace blankLines="1"/> Understanding
the cost and limitations of todays systems is important in the design
of embedded systems and the constrained nature of smart objects invites
to optimize protocols for special use cases. While some of these
optimizations may be necessary but they also come at a cost.
</t>
-->
</list>
</t>
<!--
<t>Leasons learned from the design of the Internet help is guide the development of smart objects and the
following observations are made.
<list style='numbers'>
<t>Connecting things to the Internet does not require a re-design of the Internet.</t.
<t>Re-use of standardized protocols is important since it lowers costs and improves
time-to-market.</t>
<t>A completely standarized protocol stack may be desirable but is not necessarily required.</t>
<t>The need for interoperability can be shifted to different parties.</t>
<t>Providing end-to-end IP connectivity removes the need for special application layer gateways.</t>
</list>
</t>
-->
<!--
<t>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. Many of
the issues discussed in this memo are common to any communications
system design or protocol development. However, given the high
interest for smart object networks, their somewhat specific
requirements, and commonly occurring requests for very different
communications tools prompted the IAB to discuss these issues in
this specific context.
</t>
-->
</section>
<!-- /////////////////////////////////////////////////////////////////////// -->
<section anchor="patterns" title="Utilize Design Patterns">
<t>This section illustrates a number of design pattern utilized in the smart object
environment. Note that some patterns can be applied at the same time in a product.
Developers re-using those patterns will benefit from the experience of others as well
as from documentation, source code, and available products.</t>
<section title="Device-to-Device Communication Pattern">
<t><xref target="d2d"/> illustrates a design pattern where two devices developed
by different manufacturers are desired to interoperate. To pick an example from
<xref target="RFC6574"/>, consider a light bulb switch that talks to a light
bulb with the requirement that each may be manufactured by a different company,
represented as manufacturer A and B. Other cases can be found with fitness
equipment, such as heart-rate monitors and cadence sensors.</t>
<t>
<figure anchor="d2d" title="Device-to-Device Communication Pattern">
<artwork>
<![CDATA[
_,,,, ,,,,
/ -'`` \
| Wireless |
\ Network |
/ \
,''''''''| / . ,''''''''|
| Light | ------|------------------\------| Light |
| Bulb | . | | Switch |
|........' `'- / |........'
\ _-...-`
Manufacturer `. ,.' Manufacturer
A ` B
]]></artwork>
</figure>
</t>
<t>In order to fulfill the promise that devices from different manufacturers
are able to communicate out-of-the-box, these vendors need to get together
and agree on the protocol stack. Such a consortium needs to make a decision
about the following protocol design aspects:</t>
<t>
<list style="symbols">
<t>Which physical layer(s) should be supported?</t>
<t>Which IP version(s) should be used? </t>
<t>Which IP address configuration mechanism(s) are integrated into the device?</t>
<t>Which communication architecture shall be supported? Which devices are constrained
and what are those constraints? Is there a classical client-server model or rather a
peer-to-peer model?</t>
<t>Is there a need for a service discovery mechanism to allow users to discover
light bulbs they have in their home or office?</t>
<t>Which transport-layer protocol is used for conveying the sensor readings/sensor
commands? (e.g., UDP)</t>
<t>Which application-layer protocol is used? (for example, CoAP)</t>
<t>How are requests and responses encoded? (e.g., JSON)</t>
<t>What information model is used for expressing the different light levels? What is the
encoding of the information (in a data model)?</t>
<t>Finally, some thoughts will have to be spent about the security architecture.
This includes questions like: what are the security 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?</t>
</list>
</t>
<t>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 takes time but there are
obvious rewards for end customers and vendors.</t>
<!--
<t>An example of a non-IP-based design pattern can be found with the Bluetooth Smart
profiles.</t> -->
</section>
<section anchor="d2c" title="Device-to-Cloud Communication Pattern">
<t><xref target="cloud"/> shows a design pattern for uploading sensor data to a cloud-based infrastructure. Often
the application service provider (example.com in our illustration) also sells smart objects as well. In that case
the entire communication happens internally to the provider and no need for interoperability arises. Still, it is useful
for example.com to re-use existing specifications to lower the design, implementation, testing and development effort.
</t>
<t>While this pattern allows using IP-based communication end-to-end it may still lead to silos. To prevent silos, example.com may allow third party device vendors to connect to their server infrastructure as well. For those cases, the protocol interface used to communicate with the server infrastructure needs to be made available, and various standards are available, such as CoAP, DTLS, UDP, IP, etc as shown in <xref target="cloud"/>.
</t>
<t>Since the access networks to which various smart objects are connected are typically not under the control of the application service provider, commonly used radio technologies (such as WLAN, wired Ethernet, and cellular radio) together with the network access authentication technology have to be re-used. The same applies to standards used for IP address configuration.
</t>
<t>
<figure anchor="cloud" title="Device-to-Cloud Communication Pattern">
<artwork>
<![CDATA[
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' `. DTLS
TCP ,' `._ UDP
IP-' - IP
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
]]></artwork>
</figure>
</t>
</section>
<section title="Device-to-Gateway Communication Pattern">
<t>The device-to-cloud communication pattern, described in <xref target="d2c"/>, is convenient for vendors of smart objects and works well if they use choose a radio technology that is widely deployed in the targeted market, such as IEEE 802.11-based Wifi for smart home use cases. Sometimes less widely available radio technologies are needed (such as IEEE 802.15.4) or special application layer functionality (e.g., local authentication and authorization) has to be provided. In those cases a gateway has to be introduced into the communication architecture that bridges between the different physical layer/link layer technologies and performs other networking and security functionality. <xref target="gateway"/> shows this pattern graphically. Often, these gateways are provided by the same vendor that offers the IoT product, for example because of the use of proprietary protocols, to lower the dependency on other vendors, or to avoid potential interoperability problems. It is expected that in the future more generic gateways will be deployed to lower cost and infrastructure complexity for end consumers, enterprises, and industrial environments.</t>
<t>This design pattern can frequently be found with smart object deployments that require remote configuration capabilities and real-time interactions. The gateway is thereby assumed to be always connected to the Internet.</t>
<t>
<figure anchor="gateway" title="Device-to-Gateway Communication Pattern">
<artwork>
<![CDATA[
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
|
|
|
.................
| Local |
| Gateway |
| |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' Bluetooth Smart `. DTLS
TCP ,' IEEE 802.11 `._ UDP
IP-' IEEE 802.15.4 - IP/6lo
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
]]></artwork>
</figure>
</t>
<t>A variation of this model is the case where the gateway role is actually incorporated into the smart phone. Of course, if the smart phone is not connected to smart objects, for example because the phone moved out of range, they are not connected with the Internet anymore. This limits the applicability of such a design pattern but is nevertheless very common with wearables and other IoT devices that do not need always-on Internet or real-time Internet connectivity. From an interoperability point of view it is worth noting that smart phones with their sophisticated software update mechanism via app stores allow new functionality to be updated regularly at the smart phone and sometimes even at the IoT device. With special apps that are tailored to each specific IoT device interoperability is mainly a concern with regard to the lower layers of the protocol stack, such as the radio interface, and less so at the application layer.</t>
</section>
<section title="Back-end Data Sharing Pattern">
<t>The device-to-cloud pattern often leads to silos; IoT devices upload data only to a single application service provider. However, users often demand the ability to export and to analyze data in combination with data from other sources. Hence, the urge for granting access to the uploaded sensor data to third parties arises. This design is shown in <xref target="backend"/>. This pattern is known from the Web in case of mashups and is therefore re-applied to the smart object context. To offer familiarity for developers, typically a RESTful API design in combination with a federated authentication and authorization technology (like OAuth 2.0 <xref target="RFC6749"/>) is re-used. While this offers re-use at the level of building blocks, the entire protocol stack (including the data model and the API definition) is often not standardized.</t>
<t>
<figure anchor="backend" title="Backend Data Sharing Pattern">
<artwork>
<![CDATA[
.................
| 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 | |_______________|
|........'
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- /////////////////////////////////////////////////////////////////////// -->
<section anchor="reuse" title="Re-Use Internet Protocols">
<t>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.</t>
<t>RFC 1958 <xref target="RFC1958"/> provides lessons from the early days
of the Internet and says:</t>
<t>
<list style="empty">
<t>"The Internet and its architecture have grown in evolutionary
fashion from modest beginnings, rather than from a Grand Plan",
</t>
</list>
</t>
<t>and adds:</t>
<t>
<list style="empty">
<t>"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."</t>
</list>
</t>
<t><!-- Due to network effects, the case for using the Internet Protocol(s)
and other generic technology in smart object development is
compelling. -->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.
</t>
<t>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.</t>
<t>RFC 1263 <xref target="RFC1263"/> considers protocol design strategy
and the decision to design new protocols or to use existing protocols
in a non-backward compatible way:
</t>
<t>
<list style="empty">
<t>"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."</t>
</list>
</t>
<t>While <xref target="RFC1263"/>
was written in 1991 when the standardization process was
more lightweight than today, these thoughts remain relevant
in smart object development. <!-- <xref target="I-D.tschofenig-post-standardization"/> <xref target="I-D.tschofenig-hourglass"/>.--> </t>
<!-- We will discuss this topic in more detail later in this
document.
<cref>DT: Much of this isn't specific to smart objects and might be
better done in a generic document rather than hidden in one that's
smart object specific.
JA: See new section 1.
</cref>
<t>While RFC 1263 <xref target="RFC1263"/> certainly provides good food for
thought, it also gives recommendations that may not always be appropriate
for the 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:
</t>
<t>
<list style="empty">
<t>"... 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."
</t>
</list>
</t>
<t>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.
For example, a smart object that supports only one IP protocol (IPv4 or IPv6) may be preferred over one that
supports both, at least from a complexity and cost point of view.
</t>
<t>To deal with exactly this problem, profiles have been suggested in many cases. 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 <xref target="RFC1263"/> 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.
</t>
<t>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 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?"
</t>
<t>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.
</t>
-->
<t>Interestingly, a large range of already standardized protocols are relevant
for smart object deployments. RFC 6272 <xref target="RFC6272"/>, for example,
made the attempt to identify relevant IETF specifications for use in smart
grids.</t>
<!--
<t>Of course, there are also many protocols that are unlikely to be
needed or even suitable for the smart object environments. For
instance, it would difficult to imagine inter-domain routing being a
necessary feature in these objects; there are other devices in the
network that would normally be responsible for this
functionality. But the wide range of protocols listed in RFC 6272
illustrates the view of the IETF about how readily Internet technology can be used in these applications, and indeed Internet communications have been incorporated into various smart object deployments.</t>
-->
<t>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:
<list style="hanging">
<t hangText="Vertical Profiles"><vspace blankLines="1"/>
The discussions at the IAB
workshop (see Section 3.1.2 of <xref target="RFC6574"/>) 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. <!-- Profiles, particularly,
full-stack profiles are common, for instance, in areas where existing legacy technology is being migrated to
IP.-->
<vspace blankLines="1"/>
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.</t>
<t hangText="Industry-Specific Solutions"><vspace blankLines="1"/>
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.</t>
<t hangText="Tight Coupling"><vspace blankLines="1"/>
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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<!-- /////////////////////////////////////////////////////////////////////// -->
<section anchor="deployed" title="The Deployed Internet Matters">
<t>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.</t>
<t>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.</t>
<t>The following list illustrates a few of those constraints,
but every communication protocol comes with its own challenges.</t>
<t>In 2005, Fonseca, et al. <xref target="IPoptions"/> 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.
</t>
<t>In 2010, Honda, et al. <xref target="HomeGateway"/> 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.
</t>
<t>In 2011, <xref target="TCPextensions"/> 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."
</t>
<!--
<t>As it can be seen from the examples above the question about extensibility
and incremental deployment is not only about how well protocol developers
anticipate future use cases. In fact, the IAB publication RFC 5218 on
"What Makes For a Successful Protocol?" <xref target="RFC5218"/> defines
the ultimate goal to develop protocols that are deployed beyond their
envisioned use cases.
</t>
-->
<t>Extending protocols to fulfill new uses and to add new functionality may
range from very easy to difficult, as <xref target="RFC6709"/> 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?"
<xref target="RFC5218"/> defines wildly successful protocols as protocols
that are widely deployed beyond their envisioned use cases.
</t>
<t>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 <xref target="RFC3234"/> complicate the use of extensions
in the basic IP protocols and transport-layers.
</t>
<t>RFC 1958 <xref target="RFC1958"/> 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 <xref target="RFC3724"/> 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 <xref target="RFC4924"/>
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.
</t>
</section>
<!-- /////////////////////////////////////////////////////////////////////// -->
<section anchor="change" title="Design for Change">
<t>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 <xref target="RFC1263"/> 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.".</t>
<t>In <xref target="Tussels"/> 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.</t>
<t>In order to accomplish this, Clark, et al. suggest to
<list style="numbers">
<t>Break complex systems into modular parts, so that
one tussle does not spill over and distort unrelated
issues.</t>
<t>Design for choice to permit the different players to
express their preferences. Choice often requires open interfaces.</t>
</list>
</t>
<!-- <t>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 providing
modularity and offer choice for those who deploy. Others then put
the building blocks together in a way that suits their
needs and business goals.</t>
-->
<t>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.</t>
<t>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. </t>
<!--
re 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 different deployment strategies. Generic designs
often make it hard 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, or else they
impose constraints that weren't envisioned at the outset.
</t>
<t>To "design for varation in outcome", as postulated by <xref
target="Tussels"/>,
</t>-->
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
<!-- /////////////////////////////////////////////////////////////////////// -->
<!-- DT 7/3/12: Commented this out because it is not needed when we have
Table of Contents. Prior to my edit here, it was half-commented
out so that it only covered the latter half of the doc anyway.
<t>The rest of this document is structured as follows. <xref
target="related"/> points to related work on this topic. <xref
target="issues"/> discusses the architectural challenges. <xref
target="issue-internet"/> highlights the desire to integrate smart
object networks with Internet technology, <xref
target="issue-interop"/> discusses the different models of
interoperability, and <xref target="issue-standards"/> discusses the
varying approaches to standardization of smart object networking
technology. Finally, <xref target="recs"/> provides some
recommendations from the IAB on how to approach these challenges,
<xref target="SecurityConsiderations"/> discusses general security issues,
and privacy issues are discussed in <xref
target="PrivacyConsiderations"/>.
</t>
<t>The
document is being discussed at
https://www.ietf.org/mailman/listinfo/architecture-discuss.</t>
-->
<!--
<t>The rest of the document is organized as follows. <xref
target="gen"/> discusses the problems associated with vertically
integrated industry-specific solutions, and motivates the use of
generic technologies and a more flexible architecture as a way to
reduce these problems. <xref target="re-use"/> discusses the
problems associated with attempting to use options and communication
patterns other than those in current widespread use in the
Internet. Often middleboxes and assumptions built into existing
devices makes such usage problematic. <xref target="issue-interop"/>
discusses different levels of interoperability, and the different
level of effort required to achieve them. Finally, <xref
target="SecurityConsiderations"/> presents some of the relevant
security issues, <xref target="PrivacyConsiderations"/> discusses
privacy, and <xref target="Summary"/> summarizes the
recommendations.</t>
-->
<!-- /////////////////////////////////////////////////////////////////////// -->
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>Section 3.3 of <xref target="RFC6574"/> reminds us about the IETF
work style regarding security:
<list style="empty">
<t>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 <xref target="RFC3552"/>,
and RFC 4101 <xref target="RFC4101"/>, apply also to the smart object
space.
</t>
</list>
</t>
<t>In the IETF, security functionality is incorporated into each
<!-- DT 7/3/12: removed since it's not true that every protocol includes
security functionality.
and every -->
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, <xref target="RFC6272"/> offers a survey of IETF
security mechanisms instead of suggesting a preferred one.
</t>
<t>A more detailed security discussion can be found in the report from
the 'Smart Object Security' workshop <xref target="I-D.gilger-smart-object-security-workshop"/> that was held prior to
the IETF meeting in Paris, March 2012.
</t>
<t>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.</t>
</section>
<!-- ====================================================================== -->
<section anchor="PrivacyConsiderations" title="Privacy Considerations">
<t>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
<xref target="RFC6973"/> was written as guidance specifically for that
audience and it is also applicable to the smart object context.</t>
<t>For those looking at privacy from a deployment point of view, the following
additional guidelines are suggested:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section anchor="iana" title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>We would like to thank the participants of the IAB Smart Object
workshop for their input to the overall discussion about smart
objects.
</t>
<t>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.
</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<!-- DT: this document really has no Normative references. JA: Done.
<references title="Normative References">
</references>
-->
<references title="Informative References">
<?rfc include="reference.RFC.6574"?>
<!-- <?rfc include="reference.I-D.tschofenig-post-standardization"?> -->
<?rfc include="reference.RFC.6709"?>
<?rfc include="reference.RFC.6973"?>
<?rfc include="reference.RFC.1263"?>
<?rfc include="reference.RFC.6272"?>
<?rfc include="reference.RFC.1958"?>
<?rfc include="reference.RFC.4924"?>
<?rfc include="reference.RFC.3234"?>
<?rfc include="reference.RFC.5218"?>
<?rfc include="reference.RFC.3552"?>
<?rfc include="reference.RFC.4101"?>
<?rfc include="reference.RFC.3724"?>
<?rfc include="reference.RFC.6749"?>
<!-- <?rfc include="reference.I-D.arkko-core-sleepy-sensors"?>
<?rfc include="reference.I-D.ietf-core-coap"?>
<?rfc include="reference.I-D.ietf-lwig-guidance"?>
<?rfc include="reference.I-D.tschofenig-hourglass"?>
<?rfc include="reference.I-D.jennings-senml"?>-->
<?rfc include="reference.I-D.gilger-smart-object-security-workshop"?>
<reference anchor="IPoptions">
<front>
<title>IP options are not an option, Technical Report UCB/EECS</title>
<author initials="R." surname="Fonseca" fullname="R. Fonseca">
<organization/>
</author>
<author initials="G." surname="Porter" fullname="G. Porter">
<organization/>
</author>
<author initials="R." surname="Katz" fullname="R. Katz">
<organization/>
</author>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<author initials="I." surname="Stoica" fullname="I. Stoica">
<organization/>
</author>
<date year="2005"/>
</front>
<format type='HTML'
target='http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.4251' />
</reference>
<!--
<reference anchor="Laws">
<front>
<title>The 10 Laws of Smart Object Security Design, In Proc. of IAB Workshop on 'Interconnecting Smart Objects with the Internet', Prague, Czech Repulic</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization/>
</author>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization/>
</author>
<date month="March" year="2011"/>
</front>
<format type='PDF'
target='http://www.iab.org/wp-content/IAB-uploads/2011/03/Tschofenig.pdf' />
</reference>
-->
<reference anchor="TCPextensions">
<front>
<title>Is it Still Possible to Extend TCP? In Proc. ACM Internet Measurement Conference (IMC), Berlin, Germany</title>
<author initials="M." surname="Honda" fullname="M. Honda">
<organization/>
</author>
<author initials="Y." surname="Nishida" fullname="Y. Nishida">
<organization/>
</author>
<author initials="A." surname="Greenhalgh" fullname="A. Greenhalgh">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="H." surname="Tokuda" fullname="H. Tokuda">
<organization/>
</author>
<date month="Nov" year="2011"/>
</front>
<format type='PDF'
target='http://conferences.sigcomm.org/imc/2011/docs/p181.pdf' />
</reference>
<!--
<reference anchor="eLua">
<front>
<title>Embedded Lua Project</title>
<author>
<organization/>
</author>
<date year="2012"/>
</front>
<format type='HTML'
target='http://www.eluaproject.net/' />
</reference>
-->
<reference anchor="HomeGateway">
<front>
<title>An experimental study of home gateway characteristics, In Proceedings of the '10th annual conference on Internet measurement'</title>
<author initials="L." surname="Eggert" fullname="Lars Eggert">
<organization/>
</author>
<date year="2010"/>
</front>
<format type='PDF'
target='http://eggert.org/papers/2010-imc-hgw-study.pdf' />
</reference>
<reference anchor="Tussels">
<front>
<title>Tussle in Cyberspace: Defining Tomorrow's Internet, In
Proc. ACM SIGCOMM</title>
<author initials="D." surname="Clark" fullname="D. Clark">
<organization/>
</author>
<author initials="J." surname="Wroslawski" fullname="J. Wroslawski">
<organization/>
</author>
<author initials="K." surname="Sollins" fullname="K. Sollins">
<organization/>
</author>
<author initials="R." surname="Braden" fullname="R. Braden">
<organization/>
</author>
<date year="2002"/>
</front>
<format type='HTML'
target='http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html' />
</reference>
<!--
<reference anchor="OECD">
<front>
<title>OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data</title>
<author fullname="" initials="" surname="">
<organization>Organization for Economic Co-operation and Development</organization>
</author>
<date year="1980"/>
</front>
<seriesInfo
name="available at (September 2010)"
value=", http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html"/>
<format target="http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html" type="HTML"/>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:34:57 |