Last Call Review of draft-ietf-6man-rpl-option-
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
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.)