Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
Extracted elements (30)
Group key (KIM=10) is recommended for RPL message security rather than pairwise keys because the relatively confined perimeter of a home or building network makes a group key sufficient, while encryption (LVL>0) is unlikely to be necessary given the non-confidential nature of RPL message payloads.
Multipath routing (at least two independent paths) is necessary even for one-hop neighbors because empirical measurements show that even line-of-sight neighbors in the clear region experience temporary reception failures lasting minutes, causing communication deadlines of 200 ms to be exceeded.
Non-storing mode with source routing is recommended for P2P-RPL because the majority of devices are Class 0 with extremely constrained memory; source routing avoids the need to store routing tables at intermediate nodes. Header compression (RFC6282, RFC6554) allows source-routed packets to fit in a single Layer 2 frame for networks up to 5 hops.
P2P-RPL is required instead of plain RPL for peer-to-peer traffic because RPL's DAG tree structure routes cross-branch P2P traffic up to the root and back down, causing traffic concentration, excessive battery drain, and route repair delays incompatible with the 250 ms response requirement.
The 200 ms end-to-end deadline for MPL multicast is derived from human-perception studies: if a light does not respond within ~250 ms, users assume failure and re-issue commands, generating command sequences like Light{on,off,on,off} that overload the network.
Adherence to the guidance in this document does not necessarily guarantee fully interoperable solutions in home or building control networks; additional rigorous and managed interoperability programs will be needed.
This document applies to IEEE 802.15.4 and G.9959 Layer 2 technologies adapted to IPv6 via RFC 4944 and RFC 7428 respectively. Other Layer 2 technologies are relevant provided there is no frame size issue and link-layer acknowledgements are available.
A node MUST be able to join at least one RPL Instance, as a new, temporary instance is created during each P2P-RPL route discovery operation. A node MAY be designed to join multiple RPL Instances.
Assigned IP addresses MUST be routable and unique within the routing domain [RFC5889].
EAP-TLS [RFC5216] MUST be used to carry TLS records for the authentication protocol, and EAP [RFC3748] MUST be used to provide mutual authentication mechanisms. PANA [RFC5191] and a PANA relay [RFC6345] MUST be used for multi-hop EAP transport.
Expected Transmission Count (ETX) is the RECOMMENDED path metric; [RFC6551] provides other options. Packets from asymmetric and/or unstable links SHOULD be deleted at Layer 2.
Link-layer unicast acknowledgements SHOULD be enabled when IEEE 802.15.4 or G.9959 is used with RPL and P2P-RPL.
MPL [RFC7731] is the RECOMMENDED protocol for multicast in home and building deployments, preferably deployed for N-cast over the wireless network.
Non-storing mode MUST be used to cope with the extremely constrained memory of a majority of nodes in the network, such as individual light switches.
Objective Function Zero (OF0) [RFC6552] MUST be the Objective Function. Other Objective Functions MAY be used when dictated by circumstances.
P2P-RPL [RFC6997] MUST be used to accommodate P2P traffic, which is typically substantial in home and building automation networks.
P2P-RPL SHOULD be used in home automation and building control networks, as its reactive discovery allows for low application response times even when on-the-fly route repair is needed. Non-storing mode SHOULD be used to reduce memory consumption.
RPL MAY use unsecured RPL messages to reduce message size, but if any single node uses unsecured RPL messages, link-layer security MUST be used on all nodes. All RPL messages MUST be secured using RPL message security, link-layer security, or both.
The configuration of multicast addresses for MPL routing MUST be secure, and Layer 2 security SHOULD be used for secure dissemination of MPL packets.
The joining node MUST act as the PANA Client (PaC); the parent edge router MUST act as a PANA Relay Element (PRE); and the Authentication Server MUST act as the PANA Authentication Agent (PAA).
The same symmetric key MUST NOT be used for both RPL message security and link-layer security between two peer nodes.
The symmetric key MUST be distributed or established in a secure fashion. The shared key MUST be stored in a secure fashion that will make it difficult to be read by an unauthorized party.
TLS [RFC5246] MUST be used at the highest layer of the authentication stack, carrying the authentication exchange using either PSK [RFC6655] or ECC [RFC7251] cipher suites.
Recommended MPL Trickle parameters for 200 ms deadline: Imin=10 to 50 ms, Imax=100 to 400 ms, k=2 or 3 (k > q where q=Imin/3ms), max_expiration=2 to 4. Higher max_expiration values generate copies likely to miss the deadline.
Recommended P2P-RPL parameter values: MinHopRankIncrease=1, MaxRankIncrease=0, MaxRank=6, Objective Function OF0. These values support the reactive P2P route discovery required for home and building automation.
Recommended RPL message security parameter values: Counter T-flag=0 (monotonically increasing counter, not timestamp), Algorithm=0 (AES-128 CCM), KIM=10 (group key with Key Source and Key Index), LVL=0 (MAC-32 integrity only).
Recommended Trickle parameter values for RPL DIO: DIOIntervalMin=4 (16 ms), DIOIntervalDoublings=14, DIORedundancyConstant=1. At steady state, DIO sending interval increases to ~4.37 minutes; absence of DIOs for >10 minutes signals connectivity loss.
During initial deployment, nodes are secured consecutively at the link layer using the PANA/EAP-TLS/TLS authentication stack (Section 4.1.8.2). The Authentication Server sends the network-wide symmetric key to the joining node via PANA after successful mutual authentication; unsecured PANA authentication packets are exempted at network edge enforcement points, but all other unsecured MAC-layer traffic MUST be discarded.
On detection of a compromised node, all trusted nodes must have symmetric keys known to be shared with the compromised node rekeyed, and the trusted network rebuilt using the initial deployment procedure.
This document does not specify a multicast security solution; networks rely on Layer 2 security to prevent outsiders from injecting multicast traffic. This does not protect against impersonation by already-trusted devices, which is identified as an area for future specification.