Last Call Review of draft-ietf-6man-rpl-option-
review-ietf-6man-rpl-option-secdir-lc-lepinski-2011-12-04-00

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