RFC 7452

Architectural Considerations in Smart Object Networking

📅 published March 2015, from ietf

RFC 7452: Architectural Considerations in Smart Object Networking 🎀

Okay bestie, the title block is giving everything 💅. This is RFC 7452, titled Architectural Considerations in Smart Object Networking, published in March 2015 with ISSN 2070-1721. It came from the Internet Architecture Board (IAB) 🌸 and was written by H. Tschofenig (ARM Ltd.), J. Arkko, D. Thaler, and D. McPherson. The category is Informational, so it's guidance and not a standard. The title block doesn't list anything it obsoletes or updates ✨.

Abstract 🌈

So "Internet of Things" (IoT) is basically the trend where a huge number of embedded devices use communication services from Internet protocols 🌐. A lot of these devices, which people call "smart objects," aren't really driven by humans. They live inside buildings or vehicles, or they're scattered around the environment. The vibe is "Everything that can be connected will be connected," and engineers building smart object networks have to figure out how to actually make that happen 🔥.

This document gives engineers designing Internet-connected smart objects some guidance 🫶.

Status of This Memo ✨

Okay so this doc is not an Internet Standards Track specification. It's published just for informational purposes 📖.

It's a product of the Internet Architecture Board (IAB), and it holds information the IAB decided was worth keeping on the permanent record. It reflects the consensus of the IAB. Anything the IAB approves for publication can't become any level of Internet Standard, and [RFC5741] Section 2 explains why 🙈.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7452 🦋.

Copyright (c) 2015 IETF Trust and the people listed as document authors. All rights reserved 🌸.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. Read those carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🧚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Smart Object Communication Patterns . . . . . . . . . . . . .   4
     2.1.  Device-to-Device Communication Pattern  . . . . . . . . .   4
     2.2.  Device-to-Cloud Communication Pattern . . . . . . . . . .   6
     2.3.  Device-to-Gateway Communication Pattern . . . . . . . . .   7
     2.4.  Back-End Data Sharing Pattern . . . . . . . . . . . . . .   9
   3.  Reuse Internet Protocols  . . . . . . . . . . . . . . . . . .  10
   4.  The Deployed Internet Matters . . . . . . . . . . . . . . . .  13
   5.  Design for Change . . . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  19
   Appendix A.  IAB Members at the Time of Approval  . . . . . . . .  23
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction ✨

RFC 6574 [RFC6574] describes smart objects as devices that have limits on energy, bandwidth, memory, size, cost, and so on. Honestly it's a pretty fuzzy definition 🥺, because device capabilities form a continuum and there's no clean line between devices that can run Internet protocols and devices that can't.

Connecting smart objects to the Internet unlocks so many new use cases and products 🍓. More and more products run the Internet Protocol Suite on smaller and smaller hardware, and they can process, visualize, and pull insight out of the sensor data they collect 📊. The network effect gets even stronger when data from many different devices can be combined 💅.

Building embedded systems is a whole project, and designers have to make a bunch of decisions, like:

  • How long is the device designed to operate?
  • How does it interact with the physical world? Is it a sensor, an actuator, or both?
  • How many "owners" does it have? One? Many? Will the owner probably change during the device's lifetime?
  • Is it powered continuously or intermittently? Does it sleep?
  • Is it connected to a network, and if so, how?
  • Will someone be able to physically reach it for direct maintenance after it's deployed? How does that change the security model?

Developing embedded systems is already hard, but designing Internet-connected smart objects is even harder 😭. You need Internet protocol expertise on top of software programming and hardware skills. To make the job easier and bring down the cost of new products and prototypes, we think reusing prior work is essential 🫶. So we give high-level guidance on using Internet technology to build smart objects, and connected systems more generally 🧚.

Utilize Existing Design Patterns 🌸

Design patterns are reusable solutions to design problems that keep popping up (see [Gamma] for more discussion). Existing smart object deployments show communication patterns that engineers can reuse, which cuts down on design effort. As the sections below explain, each pattern also affects the interoperability required between the different entities. Depending on what functionality you want, existing patterns can be reused and adjusted. Section 2 covers the various communication patterns ✨.

Reuse Internet Protocols 🦋

Most smart object deployments can use the Internet Protocol Suite, which is already standardized 👑. Internet protocols work in almost any environment because of their generic design, and they usually have plenty of room for reconfiguration, so they can be tailored to specific needs 🔥. Section 3 talks about this.

The Deployed Internet Matters 🌈

When you connect smart objects to the Internet, take the existing deployment into account so you don't get nasty surprises 😬. Assuming a perfect, clean-slate deployment is, in many cases, way too optimistic, because the infrastructure that's already out there is convenient to use. Section 4 highlights why this matters.

Design for Change 💜

The Internet's infrastructure, applications, and preferred building blocks keep evolving 🔄. Long-lived smart object deployments especially have to account for that change, and Section 5 is all about it 💅.

2. Smart Object Communication Patterns 🎀

This section walks through a bunch of communication patterns used in the smart object world 🌸. More than one pattern can show up in the same product at the same time. Developers who reuse these patterns get to learn from other people's experience, documentation, source code, and products that already exist 🧚.

2.1. Device-to-Device Communication Pattern 🦋

Figure 1 shows two devices, made by different manufacturers, that need to interoperate and talk to each other directly ✨. Here's an example from [RFC6574]: a light switch talks to a light bulb, and each one may come from a different company, labeled Manufacturer A and Manufacturer B 💡. Fitness gear works the same way, like heart rate monitors and cadence sensors 🏃‍♀️.

                        _,,,,    ,,,,
                       /     -'``    \
                      |  Wireless    |
                      \  Network     |
                      /               \
    ,''''''''|       /                 .       ,''''''''|
    | Light  | ------|------------------\------| Light  |
    | Bulb   |        .                 |      | Switch |
    |........'         `'-              /      |........'
                          \      _-...-`
    Manufacturer           `. ,.'              Manufacturer
        A                    `                      B

             Figure 1: Device-to-Device Communication Pattern

To make good on the promise that devices from different manufacturers can talk to each other right out of the box, the vendors have to agree on a protocol stack 🤝. They need to make decisions about these protocol-design questions:

  • Which physical layer(s) should be supported? Does it use low-power radio technologies (e.g., Bluetooth Smart, IEEE 802.15.4)?
  • Can devices be IPv6-only, or must they also support IPv4 for backward-compatibility reasons? What IPv4-IPv6 transition technologies are needed?
  • Which IP address configuration mechanism(s) is integrated into the device?
  • Which communication architectures 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?
  • Is there a need for a service-discovery mechanism to allow users to discover light bulbs they have in their home or office?
  • Which transport-layer protocol (e.g., UDP) is used for conveying the sensor readings/commands?
  • Which application-layer protocol is used (for example, the Constrained Application Protocol (CoAP) [RFC7252])?
  • What information model is used for expressing the different light levels?
  • What data model is used to encode information? (See [RFC3444] for a discussion about the difference between data models and information models.)
  • Finally, security and privacy need serious thought 🔐. That 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(s) reside? What privacy implications are caused by various design decisions?

This list isn't meant to be complete 💭. It's meant to show that every usage scenario comes with a lot of design decisions, all made to fit the constrained nature of a specific device in a specific scenario. Getting a full solution that makes two devices from different vendors fully interoperable takes time, but the payoff for end customers and vendors is huge 💖.

Part 2 is next, so don't leave me on read 💜

2.2. Device-to-Cloud Communication Pattern ✨

okay so bestie, Figure 2 shows how a smart object uploads its sensor data to an application service provider 🦋 (example.com in our little example). Often that provider also sells the smart objects 💅 In that case the whole conversation happens inside the provider, so no interoperability is needed. Still, it's giving smart move for example.com to reuse existing specs 🧠 that way it cuts down on design, implementation, testing, and development effort 💖

Here's the thing though: this pattern lets you use IP-based communication end to end 🌐 but it can still create silos 🙈 To avoid that, example.com may let third-party device vendors connect to their server infrastructure too 🫶 For that to work, the protocol interface used to talk to the server infrastructure has to be made available, and there are various standards for it, like CoAP, Datagram Transport Layer Security (DTLS) [RFC6347], UDP, IP, and so on, as shown in Figure 2 🎀 A really common worry from end users is that the business model might change (or the company goes bankrupt 😭) and the hardware becomes unusable. Companies might think about releasing their source code for the IoT device, or letting other IoT operating systems (plus application software) get installed on it 👑

Similarly, it's often desirable to switch which cloud service a device connects to, like when an application service provider changes hosting providers 🌸 Again, standard Internet protocols are needed 💜

Since the access networks that smart objects connect to are usually not under the control of the application service provider, commonly used radio technologies (like WLAN, wired Ethernet, and cellular radio) together with the network access authentication technology have to be reused ✨ The same goes for the standards used for IP address configuration 🧚

            .................
            |  Application  |
            |  Service      |
            |  Provider     |
            |  example.com  |
            |_______________|
                _,   .
     HTTP     ,'      `.        CoAP
     TLS    _,'          `.     DTLS
     TCP  ,'               `._  UDP
     IP -'                    - IP
    ,'''''''''''''|       ,'''''''''''''''''|
    | Device with |       | Device with     |
    | Temperature |       | Carbon Monoxide |
    | Sensor      |       | Sensor          |
    |.............'       |.................'

   TLS = Transport Layer Security

              Figure 2: Device-to-Cloud Communication Pattern

2.3. Device-to-Gateway Communication Pattern 🌈

The device-to-cloud pattern from Section 2.2 is super convenient for smart object vendors 💅 and works really well if they pick a radio technology that's already widely deployed in the target market, like Wi-Fi based on IEEE 802.11 for smart home stuff 🏠 Sometimes, though, less-widely-available radio technologies are needed (like IEEE 802.15.4), or special application-layer functionality (e.g., local authentication and authorization) has to be provided, or interoperability is needed with legacy, non-IP-based devices 🙃 In those cases, some form of gateway has to be added to the architecture to bridge between the different technologies and handle other networking and security functions 🔥 Figure 3 shows this pattern visually. Often these gateways come from the same vendor that sells the IoT product, for example because of proprietary protocols, to reduce dependency on other vendors, or to avoid potential interoperability problems 🫠 It's expected that more generic gateways will show up in the future to lower cost and infrastructure complexity for end consumers, enterprises, and industrial environments 🌸 Such generic gateways are more likely to exist if IoT device designs use generic Internet protocols and don't require application-layer gateways that translate one application-layer protocol into another 💖 Application-layer gateways generally lead to a more fragile deployment, as we've seen in the past with [RFC3724] and [RFC3238] 😬

This communication pattern shows up a lot with smart object deployments that need remote configuration and real-time interactions ⚡ The gateway is assumed to always be connected to the Internet 🌐

                .................
                |  Application  |
                |  Service      |
                |  Provider     |
                |  example.com  |
                |_______________|
                       |
                       |
                       | IPv4/IPv6
                .................
                |    Local      |
                |   Gateway     |
                |               |
                |_______________|
                   _,         .
     HTTP       ,'              `.         CoAP
     TLS      _,' Bluetooth Smart  `.      DTLS
     TCP    ,'     IEEE 802.11       `._   UDP
     IPv6 -'       IEEE 802.15.4         - IPv6
    ,'''''''''''''|          ,'''''''''''''''''|
    | Device with |          | Device with     |
    | Temperature |          | Carbon Monoxide |
    | Sensor      |          | Sensor          |
    |.............'          |.................'

             Figure 3: Device-to-Gateway Communication Pattern

If the gateway is mobile, like when it's a smartphone, connectivity between the devices and the Internet may be intermittent 📱 That limits where this pattern works, but it's still super common with wearables and other IoT devices that don't need always-on or real-time Internet connectivity ⌚ From an interoperability point of view, smartphones are a big deal 💜 Their software update mechanism via app stores lets new functionality get updated regularly on the smartphone and sometimes even on the IoT device 🚀 With special apps tailored to each IoT device, interoperability is mainly a concern for the lower layers of the protocol stack, like the radio interface, and much less so at the application layer (if users are willing to download a new app for each IoT device) 😅

It's also worth pointing out that a gateway lets you support both IPv6 and IPv4 externally (for compatibility with legacy application service providers), while devices themselves can be IPv6-only to reduce footprint requirements 🦋 If devices don't have the resources to support both IPv4 and IPv6 themselves, being IPv6-only (rather than IPv4-only) with a gateway gives the most flexibility 🧠 That avoids having to update devices to support IPv6 later, whereas IPv4 address exhaustion makes it ill-suited to scaling to smart object networks 💀 See [RFC6540] for further discussion 🎀

2.4. Back-End Data Sharing Pattern 🍓

The device-to-cloud pattern often leads to silos, because IoT devices upload data to only a single application service provider 🙈 But users often want to export and analyze data together with data from other sources 📊 So people start wanting third parties to get access to the uploaded sensor data 👀 This design is shown in Figure 4 💅 It's a pattern we know from the Web in the form of mashups, so it's being reused for the smart object world 🌐 To make it familiar for developers, a RESTful API design is usually combined with a federated authentication and authorization technology (like OAuth 2.0 [RFC6749]) 🫶 Reusing these building blocks helps, but the entire protocol stack (including the information/data model and RESTful Web APIs) often isn't standardized 😭

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

                  Figure 4: Back-End Data Sharing Pattern

3. Reuse Internet Protocols ✨

okay bestie, let's talk about when to reuse existing standards versus extending or redesigning protocols 🧠💅. It helps to look back at what made the Internet work in the first place 🌈.

[RFC1958] gives us lessons from the early days of the Internet, and it says:

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

And it adds:

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

Now, building tiny, battery-powered devices is genuinely hard 😭, so it can be super tempting to build solutions tailored to one specific app, or even to redesign whole networks from scratch just for that one app. I get it, but resist 🫶.

Developing consensus-based standards in an open and transparent process takes longer than building proprietary solutions 🐢. BUT the resulting solutions often stay relevant for way longer 👑. Main character energy for the long game.

[RFC1263] looks at protocol-design strategy and the decision to design new protocols or to use existing protocols in a non-backward compatible way. It says:

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.

[RFC1263] was written in 1991, when the standardization process was more lightweight than it is today 🕰️. But honestly? These thoughts are still super relevant for smart object development 💖.

Here's the lowkey wild part: a huge number of protocols that are already standardized are relevant for smart object deployments 🤯. [RFC6272], for example, tried to identify relevant IETF specifications for use in smart grids ⚡.

Still, plenty of commercial products ship with proprietary or industry-specific protocol mechanisms 🙄, and researchers have made several attempts to design new architectures for the entire Internet system. There are a few architectural concerns that deserve a spotlight:

Vertical Profiles 👗

The discussions at the IAB workshop (see Section 3.1.2 of [RFC6574]) showed that many participants prefer to develop domain-specific profiles. A profile picks a minimum subset of protocols needed for one specific operating environment 🎯. Various standardization organizations and industry fora are currently working on defining their preferred profile(s) 📝.

Ultimately though, the number of domains where smart objects can be used is basically unbounded 🌌. Plus, the set of protocols and protocol extensions is always evolving 🦋.

Merely switching the networking protocol to IP does not automatically bring the benefits that industries are hoping for with their evolving smart object deployments 😬. Profiles are rigid, and they leave little room for interoperability among slightly different or competing technology variations 🧱. For example, Layer 1 through 7 type profiles don't account for the fact that some devices may use different physical media than others. In those situations, a simple router could still let the parties communicate 🛜✨. Not everything has to be all-or-nothing!

Industry-Specific Solutions 🏭

The Internet Protocol Suite is way bigger than just IP 💅. Often, you can get major benefits from using additional, widely available, generic technologies, like the Web 🌐. Those tools come with access to a large workforce, software, and education that's already geared towards using the technology 🎓. Free help, basically 🥹.

Tight Coupling 🔗

Lots of applications are built around one specific set of servers, devices, and users. But the same data and devices could often be useful for many purposes, some of which might not be easy to spot when the devices get deployed 👀. Future-you will thank present-you for leaving the door open 🚪🌸.

Beyond the architectural concerns, developing new protocols and mechanisms is generally riskier and more expensive than reusing existing standards 💸. The costs add up in design, implementation, testing, and deployment. Secondary costs, like training technical staff and, in the worst case, training end users, can also be substantial 😵‍💫.

So, yes, there are some cases where specific solutions are needed 🙆‍♀️. But the benefits of general-purpose technology are often super compelling. That could mean choosing IP over some more specific communication mechanism 🌍, choosing a widely deployed link layer (such as wireless LAN) over a more specific one 📶, choosing web technology over application-specific protocols 🕸️, and so on.

Just be sure to embrace these technologies in their entirety, so you keep the architectural flexibility that's built into them. For example, it rarely makes sense to limit communications to on-link or to specific media 🚫. Design your applications so that the participating devices can easily interact with multiple other applications 💜.

4. The Deployed Internet Matters 🌍

Internet protocols are a great fit for smart objects, but picking the right specific protocols for a particular use case can be tricky 🧩. As the Internet has evolved, certain protocols and protocol extensions have become the norm 🏆, while others have become difficult to use in all circumstances 💀.

This matters a LOT for smart objects, because there's often a desire to use specific features to support smart object communication 🎀. For instance, from a pure protocol-specification perspective, some transport protocols may look more appealing than others 🤍. These constraints apply both to using existing protocols and to designing new ones on top of the Internet protocol stack 🧱.

The list below shows a few of those constraints, but every communication protocol comes with its own challenges 🫠.

In 2005, Fonseca, et al. [IPoptions] studied the use of IP options-enabled packets on the Internet. They found that overall, approximately half of Internet paths drop packets with options 📦🙅‍♀️. That makes extensions using IP options "less ideal" for extending IP 😬.

In 2010, Honda, et al. [HomeGateway] tested 34 different home gateways on how they handle packets: their packet dropping policy for UDP, TCP, the Datagram Congestion Control Protocol (DCCP), the Stream Control Transmission Protocol (SCTP), and ICMP, plus various timeout behavior 🏠. For example, more than half of the tested devices don't conform to the IETF-recommended timeouts for UDP 😤. For TCP, the measured timeouts were 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, [TCPextensions] tested how networks behave with regard to various TCP extensions. Their conclusion was: "From our results we conclude that 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 add new functionality can go from very easy to very difficult, as [RFC6709] explains in great detail 📚. A challenge many protocol designers face is making sure protocols are incrementally deployable and can interoperate with incumbent elements in a number of areas 🔧. In various cases, the effort it takes to design incrementally deployable protocols hasn't been taken seriously enough at the start 😩.

[RFC5218] is on "What Makes For a Successful Protocol," and it defines wildly successful protocols as protocols that are widely deployed beyond their envisioned use cases 🏅🔥. Iconic behavior, honestly.

As these examples show, protocol architects have to account for developments in the greater Internet 🌐, because not every feature can be expected to be usable in every environment 🙈. For instance, middleboxes [RFC3234] complicate the use of extensions in basic IP protocols and transport layers 🧦.

[RFC1958] considers this aspect too, and it 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 now, with the perceived need to develop intermediaries that interact with less intelligent end devices 🤖. [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 that statement may get challenged as large numbers of devices are deployed, since it might indeed turn out that changing those devices will be hard 😵. But [RFC4924] adds that a network that does not filter or transform the data it carries may be said to be "transparent" or "oblivious" to the content of packets 🫥. Networks that provide oblivious transport make it possible to deploy new services without requiring changes to the core 🧚. It's this flexibility that is perhaps both the Internet's most essential characteristic and one of the most important contributors to its success 👑💖.

5. Design for Change 🦋

okay so bestie, this section is literally about how to keep up with change without breaking everything 😭. How do you go full innovation mode and still have everyone's gadgets talking to each other? That's the big question, and it's one of the key things for winning in the marketplace 💅.

RFC 1263 [RFC1263] gets right to the point: "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 [than] keep trying to hold back the flood." Iconic energy, no notes 🔥.

In [Tussles], Clark, et al. say 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." Rigid designs get broken, flexible ones survive 🧚. Mic drop.

Quick vocab check: a "tussle" is when different parties on the Internet, who have interests that can clash, keep adjusting their mix of mechanisms to chase their own goals, and others respond by adjusting the mechanisms to push back. It's a whole ongoing back-and-forth 🌸.

To pull this off, Clark, et al. suggest two things:

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

The tricky part is predicting how conflicts between all the different players will evolve 🙈. Tussles keep evolving over time, so the architecture will change too. Picking the right building blocks and designing a communication architecture that lasts a long time is genuinely hard, and lots of smart object deployments are expected to be pretty long-lived 💜.

Here's the good news, though: the design doesn't have to be locked in during the design phase ✨. The system can adjust dynamically, since many of the protocols allow for configurability and dynamic discovery. But for the really big changes, software update mechanisms may be what gives you the flexibility you need 🎀.

A solid software update mechanism matters for a bunch of reasons. It helps with keeping up with the changing Internet communication environment, improving interoperability, adding new features, and fixing security bugs 🛠️. This might seem to clash with severely restricted devices, because on top of the software update mechanism you also need spare flash and RAM capacity. It's a trade-off worth thinking about, though, since better product support comes with a price 💅.

Technology keeps getting better, and the constraints it puts on devices shift with it 🌈. Microelectronics keep getting more capable over time, which often means new devices can be both cheaper and more capable than the ones before them. That trend can sometimes get offset by the desire to cram communications tech into even smaller, cheaper objects 🍓. So it's important to design communications technology not just for today's constraints but also for tomorrow's 👑. This matters extra because the cost of a product isn't only about hardware. It's also about the cost of not reusing already-available protocol stacks and software libraries and building custom solutions instead 😭.

Software updates are totally normal in operating systems and application programs today. Without them, most devices would be a latent risk to the Internet at large 💀. Arguably, the JavaScript-based web runs a super rapid software update mechanism, with code coming from lots of different parties (for example, websites loaded into the browser or smartphone apps) 🌸.

6. Security Considerations 🔐

Security matters even more for smart objects than for traditional computing systems, and honestly it's giving high stakes 😭. Smart objects interact directly with the physical world, which can present greater dangers, and they often run autonomously with no human interaction for long stretches. It gets worse because constrained devices often have fewer resources available to actually implement security (see the discussion of "Class 0 devices" in Section 3 of [RFC7228]). So it's critical to design for security, keeping a bunch of key considerations in mind:

  • A key part of any smart object design is figuring out how to establish trust for a smart object. Typically, bootstrapping trust means giving the device the credentials it needs to operate within a larger network of devices or services 🔑.
  • Smart objects will, in many cases, be deployed in places where extra physical security is difficult or impossible. Designers should assume that any such device can and will be compromised by an attacker with direct physical access 🚨. So trust models should distinguish between devices that are susceptible to physical compromise and devices that have some level of physical security. Physical attacks, such as timing, power analysis, and glitching, are commonly used to extract secrets [PhysicalAttacks] 😱.
  • Smart objects will, in many cases, be deployed as collections of identical or near-identical devices. Protocols should be designed so that compromising a single device doesn't lead to compromising the entire collection 🙅‍♀️. This matters because compromising a large number of devices can enable additional attacks such as a distributed denial of service. Sharing secret keys across an entire product family is also problematic, since compromising one device might leave every device from that product family vulnerable 💔.
  • Smart objects will, in many cases, be deployed in ways the designer never considered. Designers should either try to minimize the impact of misuse of their systems and devices, or implement controls to prevent such misuse where applicable 🙈.
  • It's expected that smart objects will be deployed with a long (e.g., 5-40 years) life cycle. Any security mechanism chosen at the outset may not be "good enough" for the full lifespan of the device. So long-lived devices should start with good security and provide a path to deploy new security mechanisms over their lifetime 🦋.
  • Security protocols often rely on random numbers, and providing randomness in embedded devices is challenging 🎲. For this reason, it's important to consider using hardware-based random number generators during the early stages of the design process ✨.

A more detailed security discussion can be found in the "Report from the Smart Object Security Workshop" [RFC7397], which was held prior to the IETF meeting in Paris, March 2012, and in the report from the National Science Foundation's "Cybersecurity Ideas Lab" workshop [NSF], which was held in February 2014. For example, [NSF] includes, among other recommendations, these recommendations specific to the Internet of Things:

Enhance the Security of the Internet of Things by Identifying Enclaves: The security challenges posed by the emerging Internet of Things should be addressed now, to prepare before it is fully upon us. By identifying specific use segments, or "enclaves", Internet of Things infrastructure stakeholders can address the security requirements and devise event remediations for that enclave.
Create a Framework for Managing Software Updates: The Internet of Things will challenge our current channels for distributing security updates. An environment must be developed for distributing security patches that scales to a world where almost everything is connected to the Internet and many "things" are largely unattended.

Finally, we reiterate that use of standards that have gotten wide review can often avoid a number of security issues that could otherwise arise. Section 3.3 of [RFC6574] reminds us about the IETF work style regarding security:

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

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

7. Privacy Considerations 🕵️‍♀️

This document mainly focuses on an engineering audience, meaning people designing smart object protocols and architectures 👩‍💻. Since there's no value-free design, privacy-related decisions have to be made too, even if they're just implicit in the reuse of certain technologies 💭. RFC 6973 [RFC6973] and the threat model in [CONFIDENTIALITY] were written as guidance specifically for that audience, and they also apply to the smart object context 🎀.

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

  • Transparency: Transparency of data collection and processing is key to avoiding unpleasant surprises for owners and users of smart objects. Users and impacted parties must be in a position to understand what items of personal data concerning them are collected and stored, and for what purposes they are sought 👀.
  • Data Collection / Use Limitation: Smart objects should only store personal data that is adequate, relevant, and not excessive in relation to the purpose(s) for which it's processed. Using anonymized data should be preferred wherever possible 🧼.
  • Data Access: Before deployment starts, it's necessary to consider who can access personal data collected by smart objects and under which conditions. Appropriate and clear procedures should be established so data subjects can properly exercise their rights 🗝️.
  • Data Security: Standardized data security measures to prevent unlawful access, alteration, or loss of smart object data need to be defined and deployed. Robust cryptographic techniques and proper authentication frameworks have to be used to limit the risk of unintended data transfers or unauthorized access 🔒.

A more detailed treatment of privacy considerations that go beyond engineering can be found in a publication from the Article 29 Working Party [WP223] 📖✨.

8. Informative References ✨

okay bestie, this is the reading list 📚 these are the informative references, so they're background for the ideas in the doc, and the citations stay exactly as written 💅

Appendix A. IAB Members at the Time of Approval 🎀

the IAB squad who were around when this got approved 👑

  • Jari Arkko
  • Mary Barnes
  • Marc Blanchet
  • Joel Halpern
  • Ted Hardie
  • Joe Hildebrand
  • Russ Housley
  • Eliot Lear
  • Xing Li
  • Erik Nordmark
  • Andrew Sullivan
  • Dave Thaler
  • Brian Trammell

Acknowledgements 🫶

we owe a huge thank you to everyone who came to the IAB Smart Object workshop and shared their input on smart objects in the overall discussion ✨

and a massive shoutout to Mike St. Johns, Jan Holler, Patrick Wetterwald, Atte Lansisalmi, Hannu Flinck, Bernard Aboba, Markku Tuohino, Wes George, Robert Sparks, S. Moonsesamy, Dave Crocker, and Steve Crocker, who gave especially helpful review comments 💜

Authors' Addresses 🦋

Hannes Tschofenig
ARM Ltd.
6060 Hall in Tirol
Austria

EMail: Hannes.Tschofenig@gmx.net
URI:   http://www.tschofenig.priv.at


Jari Arkko
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Dave Thaler
One Microsoft Way
Redmond, WA  98052
United States

EMail: dthaler@microsoft.com


Danny McPherson
12061 Bluemont Way
Reston, VA  20190
United States

EMail: dmcpherson@verisign.com
📦 where this page comes from