The following post is based on the recent ION Hangzhou key note presented on Thursday, July 14 in China.

Defining standards, privacy, security, and privacy components, and identifying their respective pain points.

The Internet is undergoing an evolutionary transformation resulting from the explosive growth of things that are interconnected. From single purpose sensors through wearable technologies to sophisticated computing devices, we are creating, exchanging, and consuming more data at rates that would have been inconceivable just a decade ago. The market suggests the average consumer believes this is the best world possible. As technologists, we have a responsibility to consider if we are building an Internet that is in the best interest of the user.

* * *

Part 1: Defining the Internet of Things

The Internet is undergoing an evolutionary transformation resulting from the explosive growth of things that are interconnected. From humble beginnings connecting single institutions, and then multiple institutions, to the first major computer-networking explosion in the 90’s, we are now in a period of many connected things, not just a traditional server or computing device. From single purpose sensors through wearable technologies to sophisticated computing devices, we are creating, exchanging, and consuming data at rates that would have been inconceivable just a decade ago. The market suggests that the average consumer believes this is the best world possible. As technologists, we have a responsibility to consider if we are building an Internet that is in the best interest of the average consumer.

The Internet of Things is here, but there is no universally accepted definition, no single defined set of protocols. And this step—nomenclature—is an important step. Establishing the key terms and parameters now will help us proceed in a manner that focuses on what is important: secure, stable and reliable solutions from anywhere in the world.

The Internet Society tackled this last October. They define the Internet of Things (“IoT”) as “the extension of network connectivity and computing capability to objects, devices, sensors, and items not ordinarily considered being computers.” We at Afilias endorse this definition and framework. It recognizes that IoT is a broad landscape that covers several foundational communications technologies, protocols and user applications across various markets.

We are in a period of rapid growth with no sign of slowing down anytime soon. These are most evident in three ways:

1. There are more connected devices per person than ever before. All of us have multiple personal devices—smartphones, tablets, fitness devices—and often multiple connected professional devices as well. And we see this across many age demographics.
2. Data growth is exploding. Though many devices may have a single user, the devices themselves have unique profiles. An individuals’ device profile—what data to share, when, where and how—is device-specific and their specific data broadcasting may vary from work phone to personal phone to personal tablet. Thus each of these devices and their profiles creates more and more data.
3. We are connecting things to the Internet that would have once been unthinkable. Refrigerators, cars, watches, golf clubs, lighting, agricultural equipment are now all connected—and now all provide ways for companies to automate, track and monitor data from each of these newly connected things.

It is not surprising we see estimates of connected devices growing rapidly in a short time:

2015: 4.9 billion
2016: 6.3 billion
2020: 20.8 billion

Though vast, the IoT ecosystem can be easily described by four areas of service delivery: Applications, Infrastructure, Protocol and Communication. Each of these plays a critical role in executing IoT services and has unique challenges around security and stability. The next step is defining open standards and protocols for the Protocol and Infrastructure layers that prioritize security and privacy controls that carry throughout the ecosystem.

Part 2: IoT Architectural Models

Now that we’ve defined the IoT, we can turn to a discussion of designing the architectural models and device interactions as well as their respective pain points.

The Internet Architecture Board has defined four models for describing IoT interactions (RFC 7452, “Architectural Considerations in Smart Object Networking” March 2015).

1. Device to device – often have a direct relationship with built-in security and trust using device specific data models Examples: Home automation systems like light bulbs, light switches, thermostats and door locks
2. Device to cloud – often connects to an application service provider using existing communication (e.g., Wi-Fi) to extend the capabilities of the device Examples: Enabling home energy consumption analysis and interactive voice recognition features
3. Device to gateway—connects via application software operating on a local gateway device providing security and other functionality such as data or protocol translation Popular with consumer items using an app on a smartphone to relay data like for fitness trackers; Useful for integration of legacy devices
4. Back-end data sharing - a communication architecture that enables users to export and analyze smart object data from a cloud service in combination with data from other sources Extension of the device-to-cloud model that facilitates back-end data sharing, data portability and generally helps to break down traditional data silo barriers (still need common information models across vendors)

Each of these models comes with respective pain points:

• Device to device:
  • Vendors duplicate effort designing data formats
  • Users must compare device operational requirements to confirm interoperability (devices may not work together)

• Device to cloud:

  • Vendors duplicate effort designing data protocols
  • Users must select a single vendor for all components
  • Devices may work together, at least in part, but not with the cloud and thus enhanced functionality is lost

• Device to gateway:

  • May bridge much of the interoperability gap of device-to-device/cloud issues, including supporting legacy devices
  • Adds increased complexity and cost of infrastructure (users may need a “hub” in the home)

• Back-end data sharing:

  • Data aggregation among application service providers
  • Offers advanced analysis opportunities, especially for large enterprise
  • Without interoperability throughout the stack the result is closed systems with incompatible information models

Thinking about the pain points, we have to consider if they all need to be resolved. First, in order for everything to interact with everything else, there needs to be a shared information model and a shared communication architecture. Even similar devices may have specialized purposes or features. Related devices should have a shared common core of information, with extensibility being a requirement to allow for specialized information to be included when available.

Secondly, IPv6 needs to be an absolute requirement—there is no other solution to ensure addressability of devices.

Next, a suite of information models is probably needed and devices need to be indexed to be included with related devices. And, specialized purposes and features will help to drive the distinction between proprietary versus commodity, which the market will have a role in helping to define.

Updates may also contribute to commodity versus proprietary. Updates today are a problem for all software and hardware vendors. There is an extremely long tail of old devices that are problematic to update, and every vendor has their own method. This might be a good place for more standardization, which could create new markets for helping to maintain older devices or even innovating new tools to manage devices that are more offline than online.

Finally, more standardization and interoperability in updates could also create new opportunities and innovations for addressing orphaned technologies or repurposing obsolete technologies.

In short, there is quite a lot of work for us, but utilizing well-vetted standards developed by industry, e.g., DNSSEC, IPv6, provides a spring-board for dealing with other details and edge case protocols required.

Part 3: IoT Privacy and Security Considerations

Privacy and security are paramount considerations as we launch the Internet of Things. In a survey conducted by TRUSTe last year, they found there is a marked increase in consumer concern about privacy, and many of these specific issues are directly relevant to IoT.

With so many different types of devices connected, it is easy to see the reason for concern. Take a few simple examples:

Think about gaming devices and how they are connected to allow multi-user gaming. Are you certain your 13 year old is not broadcasting too much location-based detail?

How many of us could program our smartphone to manage IoT data like how to tell it when to allow your data to be broadcasted or how to stop it—is it GPS, is it an on-command control? We are social beings, but we don’t always want every moment, even fun and social ones, logged. Yet, most users lack the ability to customize these settings.

The conveniences of a smart home abound, but are our points of ingress and egress controlled by us? Who else can gain access to my garage door?

While we can’t solve all of these things here today, we can focus on a few core principles that enable the building blocks of security and privacy in IoT.

The fundamental privacy problem facing the IoT is that devices will move in and out of various policy domains and there are no rules for how to combine the preferred privacy policy of the device with the current surrounding administrative policy domain.

A person may have various wearable technologies that share information with their home environment. However, as they move through different network connections, how is that data protected from eavesdropping? How is the user protected from their presence even being logged? What about environments that automatically log and collect details about the immediate surroundings? Is opt-out even an option? What this demonstrates is that technical work is required to facilitate individual or enterprise-level controls and policy work is necessary around data aggregation.

When it comes to security, while we still have some work to do, we also have proven, existing technologies to leverage. While we need to have systems that manage and support updates, we also need a model for identifying planned obsceneness. Additionally, collaboration is essential to mitigate silos with zero-day vulnerabilities:

Collective responsibility towards the system as a whole
Preserve the fundamental properties of the Internet
Effective agile evolutionary steps

The area we have the greatest experience and tools to leverage is in DNSSEC, a critical technology that should be a part of IoT, for numerous reasons, including:

Need names because IPv6 is not human compatible
Need accountability as to the source of data
Need assurance regarding the quality of the data to build trust

The benefits of using DNSSEC include addressing known vulnerabilities:

DNSSEC protects a user by ensuring the user knows exactly where to find whatever it is the user is looking for.
DNS is a critical infrastructure system. Virtually everything depends on it.
DNSSEC is the next step in the evolution of the Internet, similar to the web back in 1993.

Deploying a safe and secure DNS is not just the right thing to do, it is the cornerstone of building the next generation Internet, a safe and secure Internet.

TLS and DNSSEC are complementary technologies. DNSSEC ensures you know where the web site you want is located and TLS/SSL ensure your communication with that web site is confidential. Each plays an important role in securing services throughout the IoT ecosystem.

Part 4: Next Steps

There are three important areas of collaboration and work to be done in the near term: technical definition, policy development and outreach efforts.

Our technology priorities must focus on collaboration and our existing building blocks:

1. Consider best practices articulating use of essential infrastructure protocols, e.g., DNSSEC.
2. Identify pain points within each service layer and create solutions Promote collaboration and a shared commitment to security and privacy that benefits the user first
3. Standardize data models and communication protocols to enhance innovation

From a policy perspective, we must accept the reality that the Internet advances at a rate that far exceeds any government’s ability to keep up. Policy makers and regulators should focus on creating a framework that promotes security, privacy and accountability without setting limitations on innovation and growth. It is vital that industry and policy makers work in tandem to create a set of best practices based on a few core principles:

Provide the greatest benefit to the user. The end user should be able to control the way they want to use a device—either for a single device or across numerous devices—and how they hide or share data. The user must be empowered to control all aspects.

Focus on smart innovation—not creating boundaries or limits. Regulation that seeks to narrowly define, by definition will create boundaries on limitations and take the openness and out of the Internet.

Make security a responsibility throughout the ecosystem: consider liability provisions that influence vendors to account for external third party costs created by insecure products or devices that create security or stability issues.

Finally, all of this tells us one very important thing: we need to continue communicating and educating. It is our responsibility to develop these protocols in an open and transparent manner, to educate the end users on the tools available to them today and to introduce tools that simplify their ability to take control in the future.

If we work together, we can create a base of protocols that enable the burgeoning Internet of Things ecosystem in a way that maximizes security and stability.