Subject: AD reviews of draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Jul 2011 13:55:12 -0400

JP, Jonathan,

Has there a been response to the two reviews from June? I'd like to move 
these drafts forward...

Jari

Jari Arkko kirjoitti:
> I have reviewed this draft. Some of the issues from the other draft 
> are visible in this one as well, and I saw two additional substantive 
> issues:
>
> - we need to specify the behavior with regards to the data in this 
> option better
> - the text about processing packets in RPL border routers should be 
> written in a different manner
>
> Both of these should be easily addressed, however. Please revise the 
> draft and we can send the draft to IETF Last Call.
>
> Here are my comments in more detail:
>
>> Datagrams being forwarded within a RPL domain MUST include a RPL
>> Option.  For datagrams sourced within a RPL domain, the RPL Option
>> MAY be included in the datagram itself.
>
> I'm not sure I understand the difference or its motivation. Do you 
> really mean that a packet might not have the option until it hits the 
> first router? Or are you just talking about something that happens 
> internally on a host, but on the wire all packets would still have the 
> option? Also, since the tunnel (or something else) is used to include 
> the option for datagrams sourced outside the RPL domain, wouldn't it 
> be easier to just say this:
>
> "Datagrams sent between nodes within an RPL domain MUST include an RPL 
> Option."
>
>>   For datagrams sourced
>>    outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in
>>    [RFC2473 <http://tools.ietf.org/html/rfc2473>] SHOULD be used to 
>> include a RPL Option.
>
> This text should be aligned with whatever conclusion we will have for 
> the issue that I raised with the other document.
>
>> To help avoid IP-layer fragmentation, the RPL Option has a maximum
>> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain
>> SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop
>> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional
>> extension headers or options needed within RPL domain).
>>   
>
> There's a same MTU issue here as in the other document.
>
>> The action taken by using the RPL Option and the potential set of
>> sub-TLVs carried within the RPL Option MUST be specified by the RFC
>> of the protocol that use that option.  No TLVs are defined in this
>> document.
>>   
>
> I think you should define the behavior when a node encounters a 
> sub-TLV that it does not recognize. E.g., ignore and move on to the 
> next sub-TLV. Or do you want a stricter policy? In any case, for 
> future extensions it will be necessary to know how they are treated by 
> legacy RPL nodes.
>
>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due
>> to the added cost and complexity required to process and carry a
>> datagram with two IPv6 headers.  [I-D.hui-6man-rpl-headers 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.hui-6man-rpl-headers>] 
>> describes
>> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and
>> the risks involved.
>>   
>
> Again, the same comments as in the other draft. Please delete this 
> paragraph.
>
>> For datagrams exiting the RPL domain, RPL Border Routers MUST remove
>> the RPL Option from the datagram.  If the RPL Option was included
>> using tunneled mode and the RPL Border Router serves as the tunnel
>> end-point, removing the outer IPv6 header serves to remove the RPL
>> Option as well.  Otherwise, the RPL Border Router assumes that the
>> RPL Option was included using transport mode and MUST remove the RPL
>> Option from the IPv6 Hop-by-Hop Option header.
>>   
>
> The part about removing the RPL option even in a non-tunneled case 
> relates to the issue of supporting that particular mode of operation.
>
> But in addition, I wonder if you should write the above text not in 
> terms of packet modification operations but rather in terms of 
> forwarding decision outcomes. Like this, for instance:
>
> "For datagrams destined to the RPL Border Router the router processes 
> the packet in the usual way. For instance, if the RPL Option was 
> included using tunneled mode and the RPL Border Router serves as the 
> tunnel end-point, the router removes the outer IPv6 header, at the 
> same removing the RPL Option as well. Datagrams destined elsewhere 
> within the same RPL domain are forwarded to the right interface. 
> Datagrams destined outside the RPL domain are dropped."
>
>> 6. Usage of the RPL Option
>>
>>    The RPL Option is only for use within a RPL domain.  RPL routers MUST
>>    process and include the RPL Option when forwarding datagrams to other
>>    nodes within the RPL domain.  Routers on the edge of a RPL domain
>>    MUST remove the RPL Option when forwarding datagrams to nodes outside
>>    the RPL domain.
>
> What is it that this section says that is not already covered by 
> sections 2 and 5:
>
> Sect 2: Datagrams being forwarded within a RPL domain MUST include a 
> RPL Option.
>
> Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 
> header serves to remove the RPL Option as well.  Otherwise, the RPL 
> Border Router assumes that the RPL Option was included using transport 
> mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option 
> header.
>
>> This option may be used to mount several potential attacks since
>> routers may be flooded by bogus datagram containing the RPL option.
>> It is thus RECOMMENDED for routers to implement a rate limiter for
>>    datagrams using the RPL Option.
>>   
>
> Please open this up a bit. What specific danger does flooding by bogus 
> datagrams and RPL options cause? What would be the default settings 
> for the rate limiter?
>
>>    Opt Data Len:  8-bit field indicating the length of the option, in
>>          octets, excluding the Option Type and Opt Data Len fields.
>>
>>    Down 'O':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>]. 
>>
>>
>>    Rank-Error 'R':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>]. 
>>
>>
>>    Forwarding-Error 'F':  1-bit flag as defined in Section 11 of
>>          [I-D.ietf-roll-rpl 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>]. 
>>
>>
>>    RPLInstanceID:  8-bit field as defined in Section 11 of
>>          [I-D.ietf-roll-rpl 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>]. 
>>
>>
>>    SenderRank:  16-bit field as defined in Section 11 of
>>          [I-D.ietf-roll-rpl 
>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>]. 
>>
>>
>>    Values within the RPL Option are expected to change en-route. 
>
> This specification needs to describe what the behavior of a router is 
> with the content of the option. I think this is easy, you should just 
> add to the end: "The processing shall follow the rules described in 
> Section 11.2 of [roll-rpl].
>
> As an aside, the entire Section 11 is marked in roll-rpl as 
> non-normative. I don't think that's actually right as far as 11.2 
> goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want 
> to fix that in AUTH48...
>
> Jari
>
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 28 Jul 2011 14:47:04 -0400

Thanks a lot Jari, sorry for the delay, Jonathan and I just had a discussion and will send a proposal
this week.

Thanks.

JP.

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 29 Jul 2011 14:55:42 -0700

Hi Jari,

Again, thanks for your review and apologize for the delay.  See my responses below:

On Jun 17, 2011, at 2:22 PM, Jari Arkko wrote:

> I have reviewed this draft. Some of the issues from the other draft are visible in this one as well, and I saw two additional substantive issues:
> 
> - we need to specify the behavior with regards to the data in this option better
> - the text about processing packets in RPL border routers should be written in a different manner
> 
> Both of these should be easily addressed, however. Please revise the draft and we can send the draft to IETF Last Call.
> 
> I'm not sure I understand the difference or its motivation. Do you really mean that a packet might not have the option until it hits the first router? Or are you just talking about something that happens internally on a host, but on the wire all packets would still have the option? Also, since the tunnel (or something else) is used to include the option for datagrams sourced outside the RPL domain, wouldn't it be easier to just say this:
> 
> "Datagrams sent between nodes within an RPL domain MUST include an RPL Option."

Agree.

>>   [RFC2473 <http://tools.ietf.org/html/rfc2473>] SHOULD be used to include a RPL Option.
> 
> This text should be aligned with whatever conclusion we will have for the issue that I raised with the other document.

Agree.  See my response to your other review.

> There's a same MTU issue here as in the other document.

Agree.  See my response to your other review.

> I think you should define the behavior when a node encounters a sub-TLV that it does not recognize. E.g., ignore and move on to the next sub-TLV. Or do you want a stricter policy? In any case, for future extensions it will be necessary to know how they are treated by legacy RPL nodes.

Yes, we need to define the behavior.  I'm comfortable with specifying an skip-over-and-continue policy for unknown sub-TLVs.

>> datagram with two IPv6 headers.  [I-D.hui-6man-rpl-headers <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.hui-6man-rpl-headers>] describes
> Again, the same comments as in the other draft. Please delete this paragraph.

Agree.

> The part about removing the RPL option even in a non-tunneled case relates to the issue of supporting that particular mode of operation.
> 
> But in addition, I wonder if you should write the above text not in terms of packet modification operations but rather in terms of forwarding decision outcomes. Like this, for instance:
> 
> "For datagrams destined to the RPL Border Router the router processes the packet in the usual way. For instance, if the RPL Option was included using tunneled mode and the RPL Border Router serves as the tunnel end-point, the router removes the outer IPv6 header, at the same removing the RPL Option as well. Datagrams destined elsewhere within the same RPL domain are forwarded to the right interface. Datagrams destined outside the RPL domain are dropped."

The intent was to allow operation where a device within the RPL domain could source a packet destined outside the RPL domain and not use tunneling.  In this case, we would like to simply remove the option at the border router rather than drop the packet.  Do you see cases where removing the option is unacceptable?

> What is it that this section says that is not already covered by sections 2 and 5:
> 
> Sect 2: Datagrams being forwarded within a RPL domain MUST include a RPL Option.
> 
> Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 header serves to remove the RPL Option as well.  Otherwise, the RPL Border Router assumes that the RPL Option was included using transport mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option header.

Agree.  Will remove the redundant text.

> Please open this up a bit. What specific danger does flooding by bogus datagrams and RPL options cause? What would be the default settings for the rate limiter?

The option contains information that can affect the operation of RPL.  For example, an inconsistent Rank value can cause a RPL router to reset its trickle timer.

After some careful thought, I'm not sure specifying a default setting for a rate limiter is the best approach.  Determining what is acceptable vs. unacceptable can vary greatly between different deployments and environments.  But rather than rate limiting, how about the following:

  This option may be used to mount several potential attacks since
  routers may be flooded by bogus datagrams containing the RPL
  option.  In particular, an inconsistent Rank value can cause a RPL
  router to reset its DIO Trickle timer.  Thus, it is RECOMMENDED
  that a RPL router monitor triggers caused by receiving a RPL
  option and log conditions when the average rate is higher than
  expected.

>>         [I-D.ietf-roll-rpl <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>> 
>>         [I-D.ietf-roll-rpl <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>> 
>>         [I-D.ietf-roll-rpl <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>> 
>>         [I-D.ietf-roll-rpl <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>> 
>>         [I-D.ietf-roll-rpl <http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
>> 
> This specification needs to describe what the behavior of a router is with the content of the option. I think this is easy, you should just add to the end: "The processing shall follow the rules described in Section 11.2 of [roll-rpl].

Agree.

> As an aside, the entire Section 11 is marked in roll-rpl as non-normative. I don't think that's actually right as far as 11.2 goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48...

Right.

Thanks.

--
Jonathan Hui