[secdir] SECDIR review of draft-ietf-6man-rpl-option-05

[Matt Lepinski <[e-mail]>]

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 specifies an IPv6 option for use in attaching RPL routing 
information to data packets within an RPL network. Initially (I believe) 
the information included in the option is for use only in loop avoidance 
and detection, but the syntax of the option is extensible and allows for 
arbitrary TLVs, for inclusion in RPL option, to be specified in a later 
document.

There is no integrity protection for this option and so there exists a 
potential attack where a malicious party fabricates data packets with 
"bogus" information in the RPL option and sends them to an RPL router. 
The security considerations in this document describe such an attack and 
suggest a countermeasure.

I believe that the principal secure concern (regarding an attack where a 
malicious party falsifies data in the RPL option) is that  setting the 
'O' bit and the 'Rank' field improperly can cause an RPL router to 
detect a "Rank Error" that does not exist. My understanding of RPL is 
that when a "Rank Error" is detected that the router resets its "DIO 
Trickle Timer" [see Note below]. The document suggests a potential 
counter-measure to such an attack where a router limits the rate at 
which it is willing to reset its DIO Trickle Timer in response to RPL 
option receipt to be less than some constant number of resets per hour. 
(This rate is a parameter of the system and the document suggests 20 as 
a reasonable parameter value).

Personally, I believe that the counter-measure suggested is appropriate 
given the lack of integrity protection for the RPL option. However, I 
don't understand Trickle well enough to know what the ramifications 
would be (i.e., what an adversary would accomplish) by causing a router 
to reset its DIO Trickle Timer too often. (I assume that this generates 
some combination of churn in routing state and/or flood of additional 
RPL control traffic, which the adversary would use to effect a denial of 
service attack on the network.)

Note: With regard to document clarity, it was somewhat difficult for me 
as reader to track down what happens when the Rank field in the RPL 
option is set improperly. In particular, the RPL option document refers 
to Section 11.2 in the RPL specification for information on the 
semantics of the data fields in the RPL option. Section 11.2 of the RPL 
specification describes (in particular) the Rank and 'O'-bits and 
indicates the circumstances in which a "rank inconsistency" occurs. 
However, Section 11.2 of the RPL specification does not specifically 
indicate what an RPL router does when such a rank inconsistency occurs. 
(That information is found in Section 8.3 of the RPL specification) 
Therefore, I would find it helpful to have in the security 
considerations section a reference to Section 8.3 of the RPL 
specification. Additionally, I find the use of the word "triggers" to be 
confusing in the Security Considerations section. (I believe the authors 
are using the word "triggers" to refer to triggering a reset of the DIO 
Trickle Timer, but that was not clear to me when I first read the document.)