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

[Rahul Arvind Jadhav <[e-mail]>]

Thanks Brian for the review. The comments will be addressed in the next draft update.

> -----Original Message-----
::::
> 
> >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.

[RJ] Yes this risk will be added in the security considerations. Thank you for noticing this point.

> 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.

[RJ] Even with DCO traversing downstream, the adjacencies have to be verified i.e., the nodes in the path sending the DCO needs to have the routing entry for the target node along with the right state information (in the form of Path Sequence).