Subject: [secdir] SECDIR review of draft-hui-6man-rpl-routing-header

From: Chris Lonvick <[email-masked]>
Date: Wed, 2 Nov 2011 16:16:12 -0700 (PDT)

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

---

From: David Culler <[email-masked]>
Date: Thu, 3 Nov 2011 09:10:07 -0700

Chris,
   Thanks very much.  It should be natural to address these comments.

D.

On Nov 2, 2011, at 4:16 PM, Chris Lonvick wrote:

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