A new Request for Comment (RFC), which provides guidance to network engineers designing Internet-connected smart objects, was the main topic at the Technical Plenary session of IETF 92 in Dallas.
RFC 7452, entitled “Architectural Considerations for Smart-Object Networking,” explains how and when IP-based protocols can be used for embedded devices that have constrained energy, bandwidth, size, memory, and other factors.
RFC 7452 was written as a follow-up to the Internet Architecture Board’s (IAB’s) Smart Object Workshop, which was held in March 2011. During that workshop, the IAB noted that many smart objects used protocols other than IP because developers felt that IP was too heavyweight. The goal of RFC 7452 is to demonstrate the benefits of interconnecting smart objects with the Internet.
“Companies make decisions based on what’s cheapest and most financially beneficial for them,” explained Dave Thaler, an IAB member and coauthor of RFC 7452. “We want to show smart-object developers that IP will be a cheaper Layer 2 because of the large ecosystem of personnel, experience, and tools that we in the IETF have developed.”
Thaler and another coauthor, Hannes Tschofenig, presented RFC 7452 to the Technical Plenary audience.
Thaler noted that the IETF has seven working groups making progress in various areas related to smart objects, as well as a new Internet Research Task Force group. Other standardization organizations are also active in smart objects: the ZigBee Alliance adopted a standard for IPv6-based wireless mesh networks called ZigBee IP, and Bluetooth version 4.2 enables low-power IP connectivity.
“Meanwhile, hackers themselves have also been working overtime,” Thaler said. “We’ve had attacks against televisions, hacks against thermostats, hacks against lightbulbs. We’ve had hacks against front-door locks and power outlets and even certain toilets.”
Given the threats associated with these Internet-connected devices, Thaler said it is important for the IETF community to understand smart-object architecture.
Thaler said smart objects differ from PCs in four main ways. First, these devices are constrained in such areas as memory or bandwidth. Second, they interact directly with the physical world even when a human isn’t present, as in thermostats and security systems. Third, they may be physically accessible by untrusted parties, or inaccessible by trusted parties, making them hard to secure. Further, they have a long lifespan, up to 40 years.
If smart-object developers use IP, they must devote resources such as memory and power to it, and they have to worry about securing the device from Internet-based attacks. Alternatively, developers who don’t put IP in a smart object will need an application-layer gateway and may end up reinventing work that the IETF has already done like congestion control and security mechanisms.
RFC 7452 examines four common communication patterns for smart objects:
1. Device-to-device within the same network, which rarely uses IP today and instead uses such protocols as Bluetooth, Z-Wave or ZigBee. Given that these devices often have a direct relationship, they usually have built-in security and trust, but they also use device-specific data models that require redundant development efforts.
2. Device-to-cloud, in which a device connects to a cloud service through a widely deployed communications mechanism such as WiFi. Typically, the device and cloud service are from the same vendor. One risk is that the device might become unusable if the vendor goes away, a scenario that standard protocols would mitigate. In addition, standards in such areas as configuring smart objects with cryptographic keys could slash development time and eliminate silos.
3. Device-to-application-layer gateway, which uses a nonubiquitous networking layer, as well as local authentication and authorization. These types of smart objects require interoperability with non-IP devices. Sometimes this approach is taken for integrating IPv6-only devices, which means a gateway is necessary for legacy IPv4-only devices and services. Often the smart object and the gateway are from the same vendor, and the gateway is a smartphone app. While the application-layer gateway approach supports IPv6, it adds complexity and cost to the development process.
4. Back-end data sharing, which creates data silos from proprietary schemas. The result is federated cloud services or cloud application programming interfaces. Standard protocols can help but are not sufficient to eliminate data silos because common information models are needed between the vendors.
“A plethora of data models is being defined right now, but most are out of the scope of the IETF, which focuses on data models for routers and bridges but not thermostats and light bulbs,” Thaler said.
Smart-object developers have indicated some desire for common mechanisms, such as an application-layer mechanism to configure WiFi settings, but it isn’t clear whether the IETF has a role in developing these mechanisms. Another worry for the IETF is that the lack of standardization will affect the Internet’s end-to-end capabilities, Thaler added.
“When we talk about cost with smart objects, we have to think about total cost of ownership, which is the sum of at least three things: hardware, energy, and deployment costs and maybe some other things,” Thaler said. “This notion of ‘it’s too expensive to put IP in’ is focusing just on hardware.”
RFC 7452 acknowledges that the Internet-of-Things (IoT) model creates many new security threats, but the IETF has security recommendations that are applicable. For example, the IETF recommends using random numbers for authentication, key generation, key transport, and other capabilities. In PCs and servers, that’s easy to accomplish. But embedded systems don’t usually have access to random numbers due to the size and power of their processors. Without randomness, embedded systems are more vulnerable to attack.
‘In the wild, you actually see many systems basically having no sources of randomness, generating the same keys over and over again, which is obviously fatal for security,” Tschofenig said.
Key length is another important consideration with smart objects.
“Because many IoT devices have constraints in processing power and memory, the temptation is huge to reduce key size to increase performance. But if you go below a certain threshold, the security isn’t worth anything anymore,” Tschofenig added. “IETF recommends 112-bit symmetric keys to be used as a standard. If you look at many IoT products, you will see that those do not meet the recommended key size.”
Previous attacks on smart objects illustrate common problems such as limited software update mechanisms, missing key management, missing access control, lack of encryption, and vulnerability to physical attacks.
“It was reported that hackers used lightbulbs missing configuration settings to turn on and off the lights, which is pretty annoying,” Tschofenig said. “Other products have the very same vulnerabilities, like surveillance cameras, baby cameras and cameras at gas stations… If you switch to industrial control systems, you can very easily see the potential for harm.”
IoT also enables physical attacks. Special hardware is available to bypass access control mechanisms or extract keys. These tools are getting cheaper and more accessible, so the IAB expects a rise in physical attacks.
“I think it’s fair to say that Internet-of-Things security we see today is very much like PC security was 20 years ago,’’ Tschofenig said. ‘If you look outside the consumer space to the industrial environment, you already see the potential or direction of where this is headed. One example is an attack last year at a German steel factory where attackers managed to change the process and damage the steel factory.”
Privacy challenges with the deployment of IoT technologies also arise, such as the quality of user consent and data gathering about user behavior. For example, a smart watch sending out radio signals would enable the person wearing it to be physically tracked. Tschofenig added that these privacy problems associated with smart objects do not yet have a satisfactory solution.
“Without a user interface in the device, it is very difficult to ask the user for consent in a real-time fashion,” Tschofenig says. “Also, there is a desire on the part of companies to collect lots of data from different devices and correlate those to find lots of interesting insight. Doing that obviously raises privacy concerns for the end users.”
RFC 7452 concludes that developers should always use state-of-the-art key length, encryption, and automatic key management in smart objects. The guidelines also say developers should integrate a software update mechanism and a hardware-based random number generator while taking physical attacks into account.
“We believe that using IETF and Internet protocols for Internet of Things is definitely do-able and important and prevents a lot of problems,” Tschofenig summed up.
One point of contention during the question and answer period was the issue of whether Internet of Things devices need a predetermined end-of-life date. Tschofenig pointed out that the idea of having an expiration date for IoT devices was mentioned in a recent US Federal Trade Commission report and was inspired by Microsoft discontinuing Windows XP. However, several audience members argued that a secure update protocol that is small enough for devices to run without a buffer needs to be developed so that devices don’t have an expiration date.
After the technical topic, the IAB highlighted its Stack Evolution in a Middlebox Internet (SEMI) workshop held in January. Brian Trammell outlined the findings of the workshop, which focused on the evolution of interfaces to transport and network-layer services beyond UNIX domain sockets, as well as a strategy for improving path transparency in the presence of firewalls and middleboxes.
Trammel said the goal of the workshop was to discuss ossification of the transport player and how to fix it for emerging applications such as Real Time Communications in Web browsers (RTCWEB). He said the IAB is looking into this now because there is new energy in the IETF to create more flexible interfaces through such working groups as Transport Services (TAPS). In addition, the transport layer is under pressure due to increasing deployment of encryption, with everything being sent over Transport Layer Security (TLS).
“There is also pressure created by increasing deployment of encryption,” Trammel said. “If we do everything over TLS, which is the easiest way to do it, then we are going to break a lot of deployed middleboxes. There is an opportunity between breaking everything and having no privacy.”
The SEMI workshop featured 20 researchers, who were invited to present papers on deeper understanding of transport architectures, broadening transport interfaces, and defining approaches to middlebox cooperation. The presenters were split on TCP, with some wanting to continue supporting it and others wanting to replace it.
The workshop concluded that future work on middlebox cooperation was necessary, including mechanisms for detection of path characteristics, path impairment, and troubleshooting. Other goals are a better understanding of how transport should evolve and interface improvements that will expose more information to applications about transport. One hard problem is identifying trust issues and deployment incentives for middlebox cooperation and evolution approaches.
The workshop concluded with a commitment to measurement. Participants said service providers and platform developers have access to data which, in aggregate, could better inform decisions about transport protocols. This issue is being discussed under the IETF mailing list called HOPS, for How Ossified is the Protocol Stack?
“We’re making decisions on how to move forward, and we need data to do it. And we need to get the people who have the data together with the people who have the questions to ask of the data,” Trammel said.
In addition, the IETF’s Session Protocol for User Datagrams (SPUD) group is looking at methods of encapsulation for path exposure in user-space transports. SPUD is considering such issues as what information should be exposed and what incentives will exist to expose information and only accurate information.
Next steps include writing the initial workshop report, cooperating with ETSI’s NFV Forum on middlebox issues, UDP encapsulation guidelines, and a statement on architectural assumptions in transport evolution.
Finally, Andrew Sullivan, the new IAB chair, explained the IAB’s statement on Identifiers and Unicode 7.0.0. The issue occurs when a script contains both a precomposed form of a character and decomposed form of a character and these two forms are not canonically equivalent. While humans can’t tell the characters apart, machines treat them differently. This problem occurs in both Arabic-script and non-Arabic script characters.
The IAB has called for further work on this problem, which was discussed in the Locale-free UniCode Identifiers (LUCID) Birds of a Feather held during the Dallas meeting.