Skip to main content

10. Security Mechanisms

This section describes the generation and processing of secure RPL messages. The high-order bit of the RPL message code identifies whether or not a RPL message is secure. In addition to secure versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has several messages that are relevant only in networks that are security enabled.

Implementation complexity and size is a core concern for LLNs such that it may be economically or physically impossible to include sophisticated security provisions in a RPL implementation. Furthermore, many deployments can utilize link-layer or other security mechanisms to meet their security requirements without requiring the use of security in RPL.

Therefore, the security features described in this document are OPTIONAL to implement. A given implementation MAY support a subset (including the empty set) of the described security features, for example, it could support integrity and confidentiality, but not signatures. An implementation SHOULD clearly specify which security mechanisms are supported, and it is RECOMMENDED that implementers carefully consider security requirements and the availability of security mechanisms in their network.

10.1. Security Overview​

RPL supports three security modes:

  • Unsecured: In this security mode, RPL uses basic DIS, DIO, DAO, and DAO-ACK messages, which do not have Security sections. As a network could be using other security mechanisms, such as link-layer security, unsecured mode does not imply all messages are sent without any protection.

  • Preinstalled: In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a preinstalled key. Nodes use this to provide message confidentiality, integrity, and authenticity. A node may, using this preinstalled key, join the RPL network as either a host or a router.

  • Authenticated: In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a preinstalled key. Nodes use this key to provide message confidentiality, integrity, and authenticity. Using this preinstalled key, a node may join the network as a host only. To join the network as a router, a node must obtain a second key from a key authority. This key authority can authenticate that the requester is allowed to be a router before providing it with the second key. Authenticated mode cannot be supported by symmetric algorithms. As of the writing of this specification, RPL supports only symmetric algorithms: authenticated mode is included for the benefit of potential future cryptographic primitives. See Section 10.3.

Whether or not the RPL Instance uses unsecured mode is signaled by whether it uses secure RPL messages. Whether a secured network uses the preinstalled or authenticated mode is signaled by the 'A' bit of the DAG Configuration option.

This specification specifies CCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- as the cryptographic basis for RPL security [RFC3610]. In this specification, CCM uses AES-128 as its underlying cryptographic algorithm. There are bits reserved in the Security section to specify other algorithms in the future.

All secured RPL messages have either a MAC or a signature. Optionally, secured RPL messages also have encryption protection for confidentiality. Secured RPL message formats support both integrated encryption/authentication schemes (e.g., CCM) as well as schemes that separately encrypt and authenticate packets.

10.2. Joining a Secure Network​

RPL security assumes that a node wishing to join a secured network has been pre-configured with a shared key for communicating with neighbors and the RPL root. To join a secure RPL network, a node either listens for secure DIOs or triggers secure DIOs by sending a secure DIS. In addition to the DIO/DIS rules in Section 8, secure DIO and DIS messages have these rules:

  1. If sent, this initial secure DIS MUST set the Key Identifier Mode field to 0 (00) and MUST set the Security Level field to 1 (001). The key used MUST be the pre-configured group key (Key Index 0x00).

  2. When a node resets its Trickle timer in response to a secure DIS (Section 8.3), the next DIO it transmits MUST be a secure DIO with the same security configuration as the secure DIS. If a node receives multiple secure DIS messages before it transmits a DIO, the secure DIO MUST have the same security configuration as the last DIS to which it is responding.

  3. When a node sends a DIO in response to a unicast secure DIS (Section 8.3), the DIO MUST be a secure DIO.

The above rules allow a node to join a secured RPL Instance using the pre-configured shared key. Once a node has joined the DODAG using the pre-configured shared key, the 'A' bit of the Configuration option determines its capabilities. If the 'A' bit of the Configuration option is cleared, then nodes can use this preinstalled, shared key to exchange messages normally: it can issue DIOs, DAOs, etc.

If the 'A' bit of the Configuration option is set and the RPL Instance is operating in authenticated mode:

  1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure DIOs secured with Key Index 0x00. When processing DIO messages secured with Key Index 0x00, a processing node MUST consider the advertised Rank to be INFINITE_RANK. Any other value results in the message being discarded.

  2. Secure DAOs using a Key Index 0x00 MUST NOT have a RPL Target option with a prefix besides the node's address. If a node receives a secured DAO message using the preinstalled, shared key where the RPL Target option does not match the IPv6 source address, it MUST discard the secured DAO message without further processing.

The above rules mean that in RPL Instances where the 'A' bit is set, using Key Index 0x00, a node can join the RPL Instance as a host but not a router. A node must communicate with a key authority to obtain a key that will enable it to act as a router.

10.3. Installing Keys​

Authenticated mode requires a would-be router to dynamically install new keys once they have joined a network as a host. Having joined as a host, the node uses standard IP messaging to communicate with an authorization server, which can provide new keys.

The protocol to obtain such keys is out of scope for this specification and to be elaborated in future specifications. That elaboration is required for RPL to securely operate in authenticated mode.

10.4. Consistency Checks​

RPL nodes send Consistency Check (CC) messages to protect against replay attacks and synchronize counters.

  1. If a node receives a unicast CC message with the 'R' bit cleared, and it is a member of or is in the process of joining the associated DODAG, it SHOULD respond with a unicast CC message to the sender. This response MUST have the 'R' bit set, and it MUST have the same CC nonce, RPLInstanceID, and DODAGID fields as the message it received.

  2. If a node receives a multicast CC message, it MUST discard the message with no further processing.

Consistency Check messages allow nodes to issue a challenge-response to validate a node's current counter value. Because the CC nonce is generated by the challenger, an adversary replaying messages is unlikely to be able to generate a correct response. The counter in the Consistency Check response allows the challenger to validate the counter values it hears.

10.5. Counters​

In the simplest case, the counter value is an unsigned integer that a node increments by one or more on each secured RPL transmission. The counter MAY represent a timestamp that has the following properties:

  1. The timestamp MUST be at least six octets long.

  2. The timestamp MUST be in 1024 Hz (binary millisecond) granularity.

  3. The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC.

  4. If the counter represents a timestamp, the counter value MUST be a value computed as follows. Let T be the timestamp, S be the start time of the key in use, and E be the end time of the key in use. Both S and E are represented using the same three rules as the timestamp described above. If E > T < S, then the counter is invalid and a node MUST NOT generate a packet. Otherwise, the counter value is equal to T-S.

  5. If the counter represents such a timestamp, a node MAY set the 'T' flag of the Security section of secured RPL packets.

  6. If the Counter field does not present such a timestamp, then a node MUST NOT set the 'T' flag.

  7. If a node does not have a local timestamp that satisfies the above requirements, it MUST ignore the 'T' flag.

If a node supports such timestamps and it receives a message with the 'T' flag set, it MAY apply the temporal check on the received message described in Section 10.7.1. If a node receives a message without the 'T' flag set, it MUST NOT apply this temporal check. A node's security policy MAY, for application reasons, include rejecting all messages without the 'T' flag set.

The 'T' flag is present because many LLNs today already maintain global time synchronization at sub-millisecond granularity for security, application, and other reasons. Allowing RPL to leverage this existing functionality when present greatly simplifies solutions to some security problems, such as delay protection.

10.6. Transmission of Outgoing Packets​

Given an outgoing RPL control packet and the required security protection, this section describes how RPL generates the secured packet to transmit. It also describes the order of cryptographic operations to provide the required protection.

The requirement for security protection and the level of security to be applied to an outgoing RPL packet shall be determined by the node's security policy database. The configuration of this security policy database for outgoing packet processing is implementation specific.

Where secured RPL messages are to be transmitted, a RPL node MUST set the Security section (T, Sec, KIM, and LVL) in the outgoing RPL packet to describe the protection level and security settings that are applied (see Section 6.1). The Security subfield bit of the RPL Message Code field MUST be set to indicate the secure RPL message.

The counter value used in constructing the AES-128 CCM nonce (Figure 31) to secure the outgoing packet MUST be an increment of the last counter transmitted to the particular destination address.

Where security policy specifies the application of delay protection, the Timestamp counter used in constructing the CCM nonce to secure the outgoing packet MUST be incremented according to the rules in Section 10.5. Where a Timestamp counter is applied (indicated with the 'T' flag set), the locally maintained Timestamp counter MUST be included as part of the transmitted secured RPL message.

The cryptographic algorithm used in securing the outgoing packet shall be specified by the node's security policy database and MUST be indicated in the value of the Sec field set within the outgoing message.

The security policy for the outgoing packet shall determine the applicable KIM and Key Identifier specifying the security key to be used for the cryptographic packet processing, including the optional use of signature keys (see Section 6.1). The security policy will also specify the algorithm (Algorithm) and level of protection (Level) in the form of authentication or authentication and encryption, and potential use of signatures that shall apply to the outgoing packet.

Where encryption is applied, a node MUST replace the original packet payload with that payload encrypted using the security protection, key, and CCM nonce specified in the Security section of the packet.

All secured RPL messages include integrity protection. In conjunction with the security algorithm processing, a node derives either a MAC or signature that MUST be included as part of the outgoing secured RPL packet.

10.7. Reception of Incoming Packets​

This section describes the reception and processing of a secured RPL packet. Given an incoming secured RPL packet, where the Security subfield bit of the RPL Message Code field is set, this section describes how RPL generates an unencrypted variant of the packet and validates its integrity.

The receiver uses the RPL security control fields to determine the necessary packet security processing. If the described level of security for the message type and originator is unknown or does not meet locally maintained security policies, a node MUST discard the packet without further processing, MAY raise a management alert, and MUST NOT send any messages in response. These policies can include security levels, keys used, source identifiers, or the lack of timestamp-based counters (as indicated by the 'T' flag). The configuration of the security policy database for incoming packet processing is out of scope for this specification (it may, for example, be defined through DIO Configuration or through out-of-band administrative router configuration).

Where the message Security Level (LVL) indicates an encrypted RPL message, the node uses the key information identified through the KIM field as well as the CCM nonce as input to the message payload decryption processing. The CCM nonce shall be derived from the message Counter field and other received and locally maintained information (see Section 10.9.1). The plaintext message contents shall be obtained by invoking the inverse cryptographic mode of operation specified by the Sec field of the received packet.

The receiver shall use the CCM nonce and identified key information to check the integrity of the incoming packet. If the integrity check fails against the received MAC, a node MUST discard the packet.

If the received message has an initialized (zero value) counter value and the receiver has an incoming counter currently maintained for the originator of the message, the receiver MUST initiate a counter resynchronization by sending a Consistency Check response message (see Section 6.6) to the message source. The Consistency Check response message shall be protected with the current full outgoing counter maintained for the particular node address. That outgoing counter will be included within the security section of the message while the incoming counter will be included within the Consistency Check message payload.

Based on the specified security policy, a node MAY apply replay protection for a received RPL message. The replay check SHOULD be performed before the authentication of the received packet. The counter, as obtained from the incoming packet, shall be compared against the watermark of the incoming counter maintained for the given origination node address. If the received message counter value is non-zero and less than the maintained incoming counter watermark, a potential packet replay is indicated and the node MUST discard the incoming packet.

If delay protection is specified as part of the incoming packet security policy checks, the Timestamp counter is used to validate the timeliness of the received RPL message. If the incoming message Timestamp counter value indicates a message transmission time prior to the locally maintained transmission time counter for the originator address, a replay violation is indicated and the node MUST discard the incoming packet. If the received Timestamp counter value indicates a message transmission time that is earlier than the Current time less the acceptable packet delay, a delay violation is indicated and the node MUST discard the incoming packet.

Once a message has been decrypted, where applicable, and has successfully passed its integrity check, replay check, and optionally delay-protection checks, the node can update its local security information, such as the source's expected counter value for replay comparison.

A node MUST NOT update its security information on receipt of a message that fails security policy checks or other applied integrity, replay, or delay checks.

10.7.1. Timestamp Key Checks​

If the 'T' flag of a message is set and a node has a local timestamp that follows the requirements in Section 10.5, then a node MAY check the temporal consistency of the message. The node computes the transmit time of the message by adding the counter value to the start time of the associated key. If this transmit time is past the end time of the key, the node MAY discard the message without further processing. If the transmit time is too far in the past or future compared to the local time on the receiver, it MAY discard the message without further processing.

10.8. Coverage of Integrity and Confidentiality​

For a RPL ICMPv6 message, the entire packet is within the scope of RPL security.

MACs and signatures are calculated over the entire unsecured IPv6 packet. When computing MACs and signatures, mutable IPv6 fields are considered to be filled with zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPsec Authenticated Header). MAC and signature calculations are performed before any compression that lower layers may apply.

When a RPL ICMPv6 message is encrypted, encryption starts at the first byte after the Security section and continues to the last byte of the packet. The IPv6 header, ICMPv6 header, and RPL message up to the end of the Security section are not encrypted, as they are needed to correctly decrypt the packet.

For example, a node sending a message with LVL=1, KIM=0, and Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit MAC. The block cipher key is determined by the Key Index. The CCM nonce is computed as described in Section 10.9.1; the message to authenticate and encrypt is the RPL message starting at the first byte after the Security section and ends with the last byte of the packet. The additional authentication data starts with the beginning of the IPv6 header and ends with the last byte of the RPL Security section.

10.9. Cryptographic Mode of Operation​

The cryptographic mode of operation described in this specification (Algorithm = 0) is based on CCM and the block-cipher AES-128 [RFC3610]. This mode of operation is widely supported by existing implementations. CCM mode requires a nonce (CCM nonce).

10.9.1. CCM Nonce​

A RPL node constructs a CCM nonce as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Source Identifier                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+

                        Figure 31: CCM Nonce

  • Source Identifier: 8 bytes. Source Identifier is set to the logical identifier of the originator of the protected packet.

  • Counter: 4 bytes. Counter is set to the (uncompressed) value of the corresponding field in the Security option of the RPL control message.

  • Key Identifier Mode (KIM): 2 bits. KIM is set to the value of the corresponding field in the Security option of the RPL control message.

  • Security Level (LVL): 3 bits. Security Level is set to the value of the corresponding field in the Security option of the RPL control message.

Unassigned bits of the CCM nonce are reserved. They MUST be set to zero when constructing the CCM nonce.

All fields of the CCM nonce are represented in most significant octet and most significant bit first order.

10.9.2. Signatures​

If the KIM indicates the use of signatures (a value of 3), then a node appends a signature to the data payload of the packet. The Security Level (LVL) field describes the length of this signature. The signature scheme in RPL for Security Mode 3 is an instantiation of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of [RFC3447]. As public key, it uses the pair (n,e), where n is a 2048-bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode [RFC3610] as the encryption scheme with M=0 (as a stream-cipher). Note that although [RFC3610] disallows the CCM mode with M=0, RPL explicitly allows the CCM mode with M=0 when used in conjunction with a signature, because the signature provides sufficient data authentication. Here, the CCM mode with M=0 is specified as in [RFC3610], but where the M' field in Section 2.2 MUST be set to 0. It uses the SHA-256 hash function specified in Section 6.2 of [FIPS180]. It uses the message encoding rules of Section 8.1 of [RFC3447].

Let 'a' be a concatenation of a 6-byte representation of counter and the message header. The packet payload is the right-concatenation of packet data 'm' and the signature 's'. This signature scheme is invoked with the right-concatenation of the message parts a and m, whereas the signature verification is invoked with the right-concatenation of the message parts a and m and with signature s.

RSA signatures of this form provide sufficient protection for RPL networks. If needed, alternative signature schemes that produce more concise signatures is out of scope for this specification and may be the subject of a future specification.

An implementation that supports RSA signing with either 2048-bit or 3072-bit signatures SHOULD support verification of both 2048-bit and 3072-bit RSA signatures. This is in consideration of providing an upgrade path for a RPL deployment.

Last updated on