Last Call Review of draft-ietf-6man-rpl-routing-header-
review-ietf-6man-rpl-routing-header-secdir-lc-lonvick-2011-11-08-00

Request Review of draft-ietf-6man-rpl-routing-header
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-10-31
Requested 2011-10-28
Other Reviews Genart Telechat review of - by Miguel García (diff)
Genart Telechat review of - by Miguel García (diff)
Review State Completed
Reviewer Chris Lonvick
Review review-ietf-6man-rpl-routing-header-secdir-lc-lonvick-2011-11-08
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg02959.html
Draft last updated 2011-11-08
Review completed: 2011-11-08

Review
review-ietf-6man-rpl-routing-header-secdir-lc-lonvick-2011-11-08

Hi,

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.



I havn't seen source routing in a long time so I had to wrap my head 


around that again.  I tried working through some examples on how this 


would work for verious network conditions, but gave up before my head 


started hurting.  :)






Overall, it looks like the security concerns are addressed in the 


document.




I do have some minor nits that the authors may wish to discuss.

1. I don't think that the following sentence in Section 6.1 is needed:
   "Furthermore, it is RECOMMENDED that non-RPL
   routers and firewalls drop packets with a SRH by default."


That is already discussed in RFC 5095.  Having it here is therefore 


redundant.






2. I'm not sure that I am correctly following all of your pseudocode in 


Section 4.2.  In most places it looks like separate instructions within 


curly braces are separated by blank lines.  From that, I'm not sure of 


what is meant by a semicolon in the following:



       else {
          decrement Segments Left by 1;
          compute i, the index of the next address to be visited in
          the address vector, by subtracting Segments Left from n

          if Address[i] or the IPv6 Destination Address is multicast {
             discard the packet
          }

Hope this helps,
Chris