I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document addresses a reliability problem with removing routes in RPL. Currently, when a node in the network determines to change the route by which data is delivered to itself, it sends an “add route” message (DAO) to the new upstream adjacency indicating that this its new route. It also sends a “delete route” message (NPDAO)  to the old upstream adjacency indicating that the old route is to be torn down. Both the DAO and NPDAO are to be forwarded upstream by the receiving adjacencies until they reach a common ancestor. However, if the NPDAO message gets lost then data sent to the node may fail because the its no longer listening the adjacency beginning the old path.

To solve this reliability problem, this document defines a new Destination Cleanup Option (DCO) message that is initiated from a common parent to both the old and new routes. When the common ancestor sees a request to send a DCO come upstream from a node, it creates and sends a DCO down the path where the NPDAO should have come. Thus, the new DCO downsteam message should make up for a loss of a potential lost NPDAO upstream message.

RPL is a distance vector protocol. In most distance vector protocols, each node summarizes its routing table and sends the summary to their peers. From a security perspective, the peers receiving these messages can at best validate that the information was provided by a trusted peer but they cannot validate whether the routing summary or any other information in the message (e.g, the message header) is accurate or not. They cannot validate messages sent from a “peer of a peer” or further along the graph. So if any previous node  in the graph lied than the lie is propagated. I believe RPL also works this way, although I’d be happy to be corrected and it could change the results of this review.

From a security considerations perspective then, we can’t usually expect more than for a node to validate that a trusted peer has sent this data. RPL can validate this using a MAC (keyed by either a group or pair-wise key,  or a digital signature. This document describes these options, and this is good. However, note that there doesn't seem to be a facility for verifying that any part of the message propagated by a "peer of a peer", etc. is accurate.

However, I believe that the network flow of this DCO brings in some additional risks in the context of a distance vector protocol.  The security considerations does mention that a rogue ancestor could imitate a malicious route invalidation, and that’s a good statement. But I think the risk goes beyond that.

This document adds a signal (the “I” bit) to an upstream RPL routing message. This “I” bit indicates that any ancestor should invalidate any previous routes that it has.  The intent is for the node initiating a legitimate routing change to request an ancestor having more than one downstream route to that node to send a DCO down the old route. But if any node along the path can create this header, then not only the initiating node can add the "I" bit — any malicious node forwarding the RPL frame upstream can also add it. That would (I think for the first time) allow a malicious node to explicitly cause another off-path route to be destroyed — potentially leaving a target with no routes to it at all. This attack should be described in the security considerations as a risk.  It’s at a very least a problem when all of the nodes share a MAC key, and if I’m correct that only neighbor MACs or signatures are verified in RPL then it’s a problem even if the secure version of messages is deployed because a “peer of a peer” or earlier node could have added the “I” bit.

Another aspect of this new network flow is that previously a node could have protected itself from attacks deleting routes by only accepting a change of route from an adjacency representing the routed path. Spoofed “delete path” messages could be ignored from other adjacencies. That seems no longer possible with the DCO, since by definition it comes downstream rather than upstream direction from the node (possibly) changing its routes. If there’s any operational mitigation possible by which a node could protect itself against spoofed “delete path” messages then this should be added to security considerations.