Last Call Review of draft-ietf-6man-rpl-option-

Request Review of draft-ietf-6man-rpl-option
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-11-29
Requested 2011-10-28
Authors Jonathan Hui, Vasseur Jp
Draft last updated 2011-12-04
Completed reviews Secdir Last Call review of -?? by Matt Lepinski
Assignment Reviewer Matt Lepinski
State Completed
Review review-ietf-6man-rpl-option-secdir-lc-lepinski-2011-12-04
Review completed: 2011-12-04


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 


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