Subject: [Roll] Review of useofrplinfo-19

From: Rahul Jadhav <[email-masked]>
Date: Fri, 24 Nov 2017 18:21:57 +0800

The change of RPI option type has really helped to make things more easier to understand. Also, compared to the ver i previously reviewed, this ver has improved a lot in terms of structure and wordings. Thank you for the efforts.

Following are my review comments categorized as technical/editorial:

-----[Tech corrections/suggestions]-----

Section 3.1:

"It is suggested that implementations

accept both 0x63 and 0x23 when processing.  When forwarding packets,

implementations SHOULD use the same value as it was received.  When

originating new packets, implementations SHOULD have an option to

determine which value to originate with, this option is controlled by

the DIO option described below."

[RJ]: Regarding pkt fwding, it is mentioned that implementations should continue using the same option type that was rcvd in incoming pkt. Is there any specific reason for this behaviour? The reason why i ask this is, using this flag one can infer nodes that are not upgraded, and this may have security implications especially with RPI been sent out on Internet.

Section 3.3:

"In case of rebooting, the DIO is sent with flag indicating the new

RPI value."

[RJ]: Didn't understand why this should be stated. BR/Node reboot should not impact the choice of this flag, imo.

Section 4:

"A RPL network in general is composed of a 6LBR (6LoWPAN Border

Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN

(6LoWPAN Node) as leaf logically organized in a DODAG structure."

[RJ]: Why 6BBR in general case? Anyways the corresponding topology diagram (fig 6) below does not has 6BBR.

Section 4:

"The 6LN is a RPL aware router, or host.

But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I)

are RPL nodes with no children hosts."

[RJ]: Should the first line be, "The 6LN is a RPL aware leaf node or host.", but then it is redundant with the subsequent stmt.

Section 6:

"In storing mode (fully stateful), the sender can determine if the

destination is inside the LLN by looking if the destination address

is matched by the DIO's PIO option."

[RJ]: It is not necessary that the LLN will have RPL-aware-nodes addressed only using DIO's PIO. What happens if the dst RPL node has an IPv6 address not using this PIO? RPL does allow this. In storing mode i see no issues because the handling remains same, but for non-storing mode there may be implications.

Section 6.2.3:

"The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed

either to the root, or hop-by-hop such that the root can remove the

RPI header before passing upwards.  (EDNOTE: we SHOULD recommend one

or the other)"

[RJ]: Lingering EDNOTE... I like using IP-in-IP destined to root (because its relatively less processing overhead!), but hop-by-hop has its own advantage. The advantage is, If there is RPL aware node with a DAO-advertised IPv6 address not using the DIO-advertised network prefix in PIO, then the routing would be faster/more efficient (since 6LR_i would be able to remove IP-in-IP and check the routing table for the dst in underlying IP hdr).

Section 6.2.3:

"The originating node will ideally leave the IPv6 flow label as zero

so that the packet can be better compressed through the LLN.  The

6LBR will set the flow label of the packet to a non-zero value when

sending to the Internet."

[RJ]: The 6LBR is going to strip off the IP-in-IP(RPI) in this case. Why the stmt, "6LBR will set the flow label of the packet to a non-zero..."?

-----[Editorial fixes]-----

Section 3.3:

compatibilit => compatibility

Section 3.3:

"The DODAG Configuration Option is as follows.  The Flag field is the

interesting field.  The remaining fields states as defined in

[RFC6550]."

[RJ]: This para needs to be reworded. Suggesting,

"The DODAG Configuration Option has a Flags field which is modified by this document. Currently, the DODAG Configuration Option in [RFC6550] is as follows."

Section 4:

"A RPL Stack is showed in Figure 1."

[RJ]: A RPL Stack is showed in Figure 5.

Section 6:

"In all cases the RH3 is not need because..."

[RJ] In all cases the RH3 is not needed because...

Section 7.1.2:

"7.1.2.  on-SM:"

[RJ] "7.1.2.  Non-SM:"

Regards,

Rahul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 15:32:44 -0500

Thank you for the review!

>>>>> "Rahul" == Rahul Jadhav <[email-masked]> writes:
    Rahul> [RJ]: Regarding pkt fwding, it is mentioned that implementations
    Rahul> should continue using the same option type that was rcvd in incoming
    Rahul> pkt. Is there any specific reason for this behaviour? The reason why i
    Rahul> ask this is, using this flag one can infer nodes that are not
    Rahul> upgraded, and this may have security implications especially with RPI
    Rahul> been sent out on Internet.

By continuing to use the same option type that was received we do two things:
1) avoid changing packets mid-flight which RFC8200 says not to.

2) permit the network to be incrementally upgraded, and for the DODAG root to
   know which parts of the network are upgraded.
   (We also provided the flag and DIO configuration option, but it isn't
   clear to me that everyone will implement that or that it's even a good idea)

Packets with the old 0x63 option are likely to be dropped by the Internet
pre-RFC8200, so I don't see the problem.   If you can see RPI header in the
near term, I'd say that you are part of the Enterprise.  Afterward, you will
see only 0x23 options.   I think that this transition will take many years.

If knowing a node hasn't been upgraded lets you exploit it, then the exploit
is already possible. There are many other upgrades that a node could have...

    Rahul> Section 3.3:

    Rahul> "In case of rebooting, the DIO is sent with flag indicating the new

    Rahul> RPI value."

    Rahul> [RJ]: Didn't understand why this should be stated. BR/Node reboot
    Rahul> should not impact the choice of this flag, imo.

If a node has restarted, then it won't remember the flag.

    Rahul> Section 4:

    Rahul> "A RPL network in general is composed of a 6LBR (6LoWPAN Border

    Rahul> Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN

    Rahul> (6LoWPAN Node) as leaf logically organized in a DODAG structure."

    Rahul> [RJ]: Why 6BBR in general case? Anyways the corresponding topology
    Rahul> diagram (fig 6) below does not has 6BBR.

"in general" ... there might be a 6BBR, but showing it is too cumbersome in
the diagram and does not change anything.

    Rahul> Section 4:

    Rahul> "The 6LN is a RPL aware router, or host.

    Rahul> But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I)

    Rahul> are RPL nodes with no children hosts."

    Rahul> [RJ]: Should the first line be, "The 6LN is a RPL aware leaf node or
    Rahul> host.", but then it is redundant with the subsequent stmt.

That F, H and I have no children doesn't make them leaf (node) only.
They are simply routers without children *at the moment*.

    Rahul> "In storing mode (fully stateful), the sender can determine if the
    Rahul> destination is inside the LLN by looking if the destination address
    Rahul> is matched by the DIO's PIO option."

    Rahul> [RJ]: It is not necessary that the LLN will have RPL-aware-nodes
    Rahul> addressed only using DIO's PIO. What happens if the dst RPL node has
    Rahul> an IPv6 address not using this PIO? RPL does allow this. In storing
    Rahul> mode i see no issues because the handling remains same, but for
    Rahul> non-storing mode there may be implications.

If some node has an address which is not in the DIO's PIO prefix, then a
naive other node will assume it is not in the LLN.  That's the best heuristic
we came up with to determine if the destination is in the LLN, and therefore
RPL capable.

    Rahul> Section 6.2.3:

    Rahul> "The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed

    Rahul> either to the root, or hop-by-hop such that the root can remove the

    Rahul> RPI header before passing upwards. (EDNOTE: we SHOULD recommend one

    Rahul> or the other)"

    Rahul> [RJ]: Lingering EDNOTE... I like using IP-in-IP destined to root
    Rahul> (because its relatively less processing overhead!), but hop-by-hop has
    Rahul> its own advantage. The advantage is, If there is RPL aware node with a
    Rahul> DAO-advertised IPv6 address not using the DIO-advertised network
    Rahul> prefix in PIO, then the routing would be faster/more efficient (since
    Rahul> 6LR_i would be able to remove IP-in-IP and check the routing table for
    Rahul> the dst in underlying IP hdr).

yes, you are right.
Can you tell us why such a node would exist?  What's the use case?

    Rahul> [RJ]: The 6LBR is going to strip off the IP-in-IP(RPI) in this case.
    Rahul> Why the stmt, "6LBR will set the flow label of the packet to a
    Rahul> non-zero..."?

Because the flow-label is supposed to be non-zero when traffic enters the "Internet"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Nov 2017 20:47:59 +0000

Hello Michael

Item 1 is not correct. We can actually change the RPI in mid flight. RFC 8200 says no insertion or deletion for HbH but does not preclude mods. In fact every hop changes the RPI in Normal RPL behavior. I agree that changing the option type is more violent though.

Also packets with 0x63 probably obeyed the ancient rules thus IP in IP in which case the root decapsulates and the RPI goes.

Regards,

Pascal

Le 29 nov. 2017 à 21:33, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :

"Rahul" == Rahul Jadhav <[email-masked]<mailto:[email-masked]>> writes:

   Rahul> Section 3.3:

   Rahul> RPI value."

   Rahul> Section 4:

   Rahul> Section 4:

   Rahul> Section 6.2.3:

   Rahul> or the other)"

yes, you are right.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 21:38:19 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Item 1 is not correct. We can actually change the RPI in mid flight.
    > RFC 8200 says no insertion or deletion for HbH but does not preclude
    > mods. In fact every hop changes the RPI in Normal RPL behavior. I
    > agree that changing the option type is more violent though.

We can't change the RPI type code, just the contents of the header itself.
It would be delete 0x63 header and insert 0x23 header.

    > Also packets with 0x63 probably obeyed the ancient rules thus IP in IP
    > in which case the root decapsulates and the RPI goes.

True.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Nov 2017 05:21:45 +0000

I understand how you see it Michael. Makes sense to me.

Now if we do not rewrite then if a packet comes to the root with 0x63 and no IP in IP the root will not rewrite. If it follows the rules in the ops draft it should drop the packet. At least it could report an alert to document the issue.

But, same as leaking 0x23, that is a recipe for unhappy customers. In both cases we want to avoid keeping the RPI in the outer header. In both cases it is to avoid issues from devices that do not follow the rules but which we do not control either.

As a standard body we can probably ignore that. As a device manufacturer that builds RPL roots I can probably not. I will have to chose between ignoring the rule and reencapsulating the packet from the root  to its final destination.

I guess that’s OK. But I prefer the SR way that documents their deviation in an overriding RFC for their case and live quite happily with it. But maybe we do not have enough real deployments to bend the rules...

Take care,

Pascal

Le 30 nov. 2017 à 03:38, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

True.