Skip to main content

19. Security Considerations

19.1. Overview

From a security perspective, RPL networks are no different from any other network. They are vulnerable to passive eavesdropping attacks and, potentially, even active tampering when physical access to a wire is not required to participate in communications. The very nature of ad hoc networks and their cost objectives impose additional security constraints, which perhaps make these networks the most difficult environments to secure. Devices are low-cost and have limited capabilities in terms of computing power, available storage, and power drain; it cannot always be assumed they have a trusted computing base or a high-quality random number generator aboard.

Communications cannot rely on the online availability of a fixed infrastructure and might involve short-term relationships between devices that may never have communicated before. These constraints might severely limit the choice of cryptographic algorithms and protocols and influence the design of the security architecture because the establishment and maintenance of trust relationships between devices need to be addressed with care. In addition, battery lifetime and cost constraints put severe limits on the security overhead these networks can tolerate, something that is of far less concern with higher bandwidth networks. Most of these security architectural elements can be implemented at higher layers and may, therefore, be considered to be out of scope for this specification. Special care, however, needs to be exercised with respect to interfaces to these higher layers.

The security mechanisms in this standard are based on symmetric-key and public-key cryptography and use keys that are to be provided by higher-layer processes. The establishment and maintenance of these keys are out of scope for this specification. The mechanisms assume a secure implementation of cryptographic operations and secure and authentic storage of keying material.

The security mechanisms specified provide particular combinations of the following security services:

Data confidentiality: : Assurance that transmitted information is only disclosed to parties for which it is intended.

Data authenticity: : Assurance of the source of transmitted information (and, hereby, that information was not modified in transit).

Replay protection: : Assurance that a duplicate of transmitted information is detected.

Timeliness (delay protection): : Assurance that transmitted information was received in a timely manner.

The actual protection provided can be adapted on a per-packet basis and allows for varying levels of data authenticity (to minimize security overhead in transmitted packets where required) and for optional data confidentiality. When nontrivial protection is required, replay protection is always provided.

Replay protection is provided via the use of a non-repeating value (CCM nonce) in the packet protection process and storage of some status information (originating device and the CCM nonce counter last received from that device), which allows detection of whether this particular CCM nonce value was used previously by the originating device. In addition, so-called delay protection is provided amongst those devices that have a loosely synchronized clock on board. The acceptable time delay can be adapted on a per-packet basis and allows for varying latencies (to facilitate longer latencies in packets transmitted over a multi-hop communication path).

Cryptographic protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and application-specific trade-offs between key storage and key maintenance costs versus the cryptographic protection provided. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key-sharing group.

Data authenticity may be provided using symmetric-key-based or public-key-based techniques. With public-key-based techniques (via signatures), one corroborates evidence as to the unique originator of transmitted information, whereas with symmetric-key-based techniques, data authenticity is only provided relative to devices in a key-sharing group. Thus, public-key-based authentication may be useful in scenarios that require a more fine-grained authentication than can be provided with symmetric-key-based authentication techniques alone, such as with group communications (broadcast, multicast) or in scenarios that require non-repudiation.