[secdir] Secdir last call review of draft-ietf-roll-efficient-npdao-10

[Brian Weis via Datatracker <[e-mail]>]

Reviewer: Brian Weis
Review result: Has Issues

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.