Skip to main content

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 revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-10-31
Requested 2011-10-28
Authors David Culler , Jonathan Hui , JP Vasseur , Vishwas Manral
I-D last updated 2011-11-08
Completed reviews Genart Telechat review of -?? by Miguel Angel García
Genart Telechat review of -?? by Miguel Angel García
Secdir Last Call review of -?? by Chris M. Lonvick
Assignment Reviewer Chris M. Lonvick
State Completed
Request Last Call review on draft-ietf-6man-rpl-routing-header by Security Area Directorate Assigned
Completed 2011-11-08
review-ietf-6man-rpl-routing-header-secdir-lc-lonvick-2011-11-08-00
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