Subject: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 02 May 2019 06:53:47 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-useofrplinfo-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There are several internal inconsistencies that needs to be
resolved before publication, specifically for:
(1) the destination address of the IPv6-in-IPv6 tunnel used for flows
from the Internet to a ~Raf -- Section 6.2.4 says addressed to the ~Raf,
but Figure 7 says "hop".
(2) the destination address of the IPv6-in-IPv6 tunnel used for flows
from a ~Raf to a ~Raf -- Section 6.3.4 says addressed to the ~Raf, but
Figure 7 says "hop"
(3) Table 14 says "(opt: RPI)" which, though not defined, I take to mean
as indicating that the insertion of the RPI is optional, but the body
text in Section 7.1.2 is unconditional that the 6LBR inserts an RPI
header
(4) Section 7.2.1 does not mention adding v6-in-v6 encapsulation, but
Figure 8 has a "must" in that column.
(5) Section 7.3.1 only has descriptive text that "[t]he originating node
should put the RPI into an IPv6-in-IPv6 header", but Figure 8 lists this
behavior as "must" (though there would also be a second v6-in-v6
encapsulationi from root to destination, which is clearly a must).
(Note that Section 7.3.2 covers essentially the same flow, but uses
"which must be in an IPv6-in-IPv6 header addressed to the root".)
(6) In Section 5, we say that the DODAG root "SHOULD force [rank information]
to zero" but then that "[t]he Internet will therefore not see any SenderRank
information", and a SHOULD-level requirement is not enough to guarantee
this statement as fact.

Additionally, there are some terminology inconsistencies in Figures 7
and 8 that need to be cleaned up or explained.  For example, in Figure
7, what is the difference between "Yes" and "must" in the "IPv6-in-IPv6"
column, and in the "v6-in-v6 dst" column, what does "root" mean?
In Figure 8, what does "Opt" mean in the "RPI" column?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

   An interim meeting went through the 24 cases defined here to discover
   if there were any shortcuts, and this document is the result of that
   discussion.  This document clarifies examples that intend to
   illustrate the result of the normative language in RFC8200 and
   RFC6553.  In other words, the examples are intended to be normative
   explanation of the results of executing that language.

I agree with the GenART reviewer that this language is hard to parse
into useful expectations, and I'm not sure that the suggestion in
https://mailarchive.ietf.org/arch/msg/gen-art/FnrfXDQ4ZmGniUpa2y-qKA6bkOg
helps very much.  In particular, what does it mean for an example to be
a "normative explanation"?

Section 2

As noted by the rtgdir reviewer, the volume of new terminology
introduced is rather extensive, and hard for a newcomer to overcome.

   Flag Day: A transition that involves having a network with different
   values of RPL Option Type.  Thus the network does not work correctly.

This does not match up with what I understood the colloquial definition
of "flag day" to be (i.e., the specific act of cutting over from old to
new, designed to minimize the duration of the transient period when the
network does not work correctly, with extensive planning and
coordination needed to effectuate a scheduled, as opposed to rolling,
cutover).  It seems that the later usage of the term "flag day" in this
document is internally consistent with the definition here, at least.

   Hop-by-hop IPv6-in-IPv6 headers: The term "hop-by-hop IPv6-in-IPv6"
   header refers to: adding a header that originates from a node to an
   adjacent node, using the addresses (usually the GUA or ULA, but could
   use the link-local addresses) of each node.  If the packet must
   traverse multiple hops, then it must be decapsulated at each hop, and
   then re-encapsulated again in a similar fashion.

I'm not seeing where in the description the "IPv6-in-IPv6" nature is
used -- couldn't this description equally apply to regular hop-by-hop
IPv6 headers?  Is the distinction that the added header is specifically
on the *inner* IPv6 representation?

Section 3.1

   Based on that, if an IPv6 (intermediate) node (RPL-not-capable)
   receives a packet with an RPL Option, it should ignore the HBH RPL
   option (skip over this option and continue processing the header).
   This is relevant, as it was mentioned previously, in the case that
   there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1).

   Thus, this document updates the Option Type field to: the two high
   order bits MUST be set to '00' and the third bit is equal to '1'.

I am not sure that the "Thus" is appropriate -- as the secdir reviewer
notes, the logical connection is a bit tenuous, and the main connection
here seems to just be that 8200 endorses the concept of skipping over
some things, which gives us cover to use an option type that is
skippable.  But I'm probably misunderstanding here, and would welcome an
explanation of the nature of my confusion.

   The non-storing mode case does not require the type change from 0x63
   to 0x23, as the root can always create the right packet.  The type
   change does not adversely affect the non-storing case.

This section doesn't seem to explicitly call out the storing case for
special discussion.  Is there anything useful to say about it?

Section 3.2

                                                         The node will
   know which to use based upon the presence of the DODAG Configuration
   Option described in the next section.  [...]

nit: is it the mere *presence* of the DODAG Configuration Option, or the
information contained therein, that is relevant for this decision?

   There are potential significant advantages to having a single code
   path that always processes IPv6-in-IPv6 headers with no options.

nit(?): There seems to be potential ambiguity about whether "no options"
means "no IPv6 options" or "no conditional branches in the processing
flow".

I'm also not entirely sure how this sentence is supposed to tie in to
the rest of the section.

Figure 3 is pretty sparsely annotated.

Section 4

In Figure 5, why does the line from D to B have an arrowhead but none of
the other lines do?

Section 5

   NOTE: There is some possible security risk when the RPI information
   is released to the Internet.  At this point this is a theoretical
   situation; no clear attack has been described.  At worst, it is clear
   that the RPI option would waste some network bandwidth when it
   escapes.  This is traded off against the savings in the LLN by not
   having to encapsulate the packet in order to remove the artifact.

The risk seems open-ended given the potential for sub-TLVs in the RPI.
Where would a potential author of a new sub-TLV look to get guidance on
the potential security risks from having the sub-TLV contents released
to the internet?  Is there something useful we could add via this
document?
Also, I agree with the secdir reviewer that "at worst" should be "at a
minimum".

   Despite being legal to leave the RPI artifact in place, an
   intermediate router that needs to add an extension header (RH3 or RPI
   Option) MUST still encapsulate the packet in an (additional) outer IP
   header.  The new header is placed after this new outer IP header.

I didn't think that "RH3 or RPI Option" was an exhaustive list, and
isn't this duplicating a requirement from another specification anyway?
(That is, the "MUST" is probably not appropriate.)

   RPI MUST be present in every single RPL data packet.  There is one
   exception in non-storing mode: when a packet is going down from the
   root the RPI MAY be omitted.  The rational is that in a downward non-

This "MUST be present [...] one exception" is not a great way to phrase
things.  Collapsing into the same sentence with a comma "MUST be present
[...], with one execption: [...]" would help some, but it may even be
possible to use descriptive rather than normative language.

nit: s/rational/rationale/

Section 6

   The following table (Figure 7) itemizes which headers are needed in
   each of the following scenarios.  It indicate if an IPv6-in-IPv6
   header must be inserted, and whether the destination address of the
   IPv6-in-IPv6 header is the next hop, or the final target address.
   There are these possible situations: hop-by-hop necessary (indicated
   by "hop"), or final target address possible (indicated by "tgt").  In
   all cases hop by hop may be used rather than the final target
   address.

nit: we could probably make a stronger rhetorical connection betweeen
"the destination address is the next hop" and "hop-by-hop necessary" --
these tables are pretty complicated as-is, so every bit helps!

   In each case, 6LR_i are the intermediate routers from source to
   destination.  "1 <= i <= n", n is the number of routers (6LR) that
   the packet go through from source (6LN) to destination.

nit: singular/plural mismatch with "packet" and "go through"

Section 6.1.1

   For example, a communication flow could be: Node F --> Node E -->
   Node B --> Node A root(6LBR)

I think maybe a directorate reviewer already noted, but it seems that
node D was intended rather than node E.

Section 6.2.2

Should we say what the IPv6-in-IPv6 destination address is set to in
this case?

Section 6.2.3

Why does the 6LBR not remove headers in the the IPv6-in-IPv6(RPI)(2) case?

Section 6.2.4

I'm not sure how to interpret the Table.  Does the IPv6 node remove the
RPI or ignore it?

Section 6.3.1

   While the 6LR nodes will update the RPI, no node needs to add or
   remove the RPI, so no IPv6-in-IPv6 headers are necessary.  This may
   be done regardless of where the destination is, as the included RPI
   will be ignored by the receiver.

I'm not sure what variation in the receiver location this is supposed to
allow, given that we have already specified it to be a Raf in the same
RPL Domain.

Section 6.3.4

   not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not-
   RPL-aware 6LN (IPv6 dst)

Is the root considered to be a 6LR_ia or a 6LR_id?

   Note that this flow is identical to Section 6.3.3, except for where
   the IPv6-in-IPv6 header is inserted.

I'm still not seeing a difference in where the IPv6-in-IPv6 header is
inserted.

Section 7

   The following table (Figure 8) summarizes what headers are needed in
   the following scenarios, and indicates when the RPI, RH3 and IPv6-in-
   IPv6 header are to be inserted.  There are these possible situations:
   target destination address possible (indicated by "tgt"), to a 6LR,
   to a 6LN or to the root.  In cases where no IPv6-in-IPv6 header is
   needed, the column states as "No".

"There are these possible situations" seems overly broad; if I
understand correctly, it is discussing only the last ("v6-in-v6 dst")
column's possible values.

Is the "to a 6LR" case always going to be "the last 6LR before the 6LN
or 6LBR"?  It may be worth a few words to clarify that.

   The leaf can be a router 6LR or a host, both indicated as 6LN
   (Figure 3).  In the Figure the (1) indicates a 6tisch case [RFC8180],
   where the instanceID portion of the RPI header may still be needed to
   pick an appropriate priority or channel at each hop.

This wording seems to imply that it is possible to cherry-pick just the
instanceID portion of the RPI header without (e.g.) the SenderRank,
which does not match my understanding of what is possible.  Perhaps
"where the RPI header may still be needed for the instanceID to be
available for priority/channel selection at each hop" is better wording?

Section 7.1.2

   The destination is known to RPL-aware because, the root knows the
   whole topology in non-storing mode.

nits: "to be", and no comma is needed.

Section 7.1.3

I think I would prefer if the body text mentioned that an RPI is
optionally added (for the 6tisch case where the instanceID is needed).

I'm not sure that I understand why the RPI is marked as being modified
by the 6LR_i in this case but not in Section 7.1.2.

Table 15 should probably keep the parentheses around "(opt: RPI)" in the
column for the ~Raf.

Section 7.2.4

It seems that Table 20 could coalesce the 6LR_1 column into the 6LR_i
column, and instead break out a 6LR_n column as is done in (e.g.)
Section 7.1.3.

Section 7.3.1

The conventions established previously in this document would seem to
have us include the "IPv6-in-IPV6()" indicator in the "Modified headers"
row.

Section 7.3.2

I think the Table 22 column header is better as 6LR_ia than 6LR_1.
It would be nice to be able to distinguish the generic 6LR_id and 6LR_m
cases, but I'm not sure if there's enough horizontal space for that.
Some textual discussion in the Table legend would be very helpful,
though.

Section 7.3.3

   not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id -->
   6LN

Is there a separate 6LR_1 step to be mentioned here?

It's unclear if there's enough room for it in Table 23, but presumably
the generic 6LR_ia are modifying the IPv6-in-IPv6(RPI_1) headers?

Section 7.3.4

   not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id -->
   not-RPL-aware (IPv6 dst)

Are there separate 6LR_1 and 6LR_m steps to mention here?

As for 7.3.3, Table 24 seems to be missing some columns for intermediate
6LRs that merely modify the RPI headers, though I recognize space
concerns.

Section 8

   The above case occurs whenever traffic originates from the outside
   the LLN (the "Internet" cases above), and non-storing mode is used.
   In non-storing mode, the RPL root knows the exact topology (as it
   must be create the RH3 header), and therefore knows what the 6LR
   prior to the leaf --- the 6LR_n.

nit: "what the 6LR prior to the leaf is" or "which 6LR is immediately
prior to the leaf" or similar

Section 9

   During bootstrapping the node get the DIO with the information of RPL
   Option Type, indicating the new RPI in the DODAG Configuration Option
   Flag.  The DODAG root is in charge to configure the current network
   to the new value, through DIO messages and when all the nodes are set
   with the new value.  [...]

Perhaps a reminder of how "all the nodes are set with the new value" is
detected by the root would be helpful.

   The migration path to the change from 0x63 to 0x23 in networks that
   accepts both values is changed when the DIO is sent with the flag
   indicating the new RPI value.  Namely, it remains at 0x63 until it is

nit: How is it the *migration path* that is changed when the DIO with
flag is sent?  That seems to be making the migration happen, but the
path is the same as it ever was.

Section 11

   While a typical LLN may be a very poor origin for attack traffic (as
   the networks tend to be very slow, and the nodes often have very low
   duty cycles) given enough nodes, they could still have a significant
   impact, particularly if the attack was on another LLN!  Additionally,

I agree with the secdir reviewer that "target of the attack was another
LLN!" (or similar) would be clearer.

   With the above precautions, an attack using IPv6-in-IPv6 tunnels will
   be by a node within the LLN on another node within the LLN.  Such an

nit: I'd suggest s/will be/can only be/ to emphasize the restrictive
nature of the precautions.

   The RH3 header usage described here can be abused in equivalent ways
   with an IPv6-in-IPv6 header to add the needed RH3 header.  As such,

I don't think I understand what this is trying to say.  What are the
things that are equivalent?

   The RPI header, if permitted to enter the LLN, could be used by an
   attacker to change the priority of a packet by selecting a different
   RPLInstanceID, perhaps one with a higher energy cost, for instance.
   It could also be that not all nodes are reachable in an LLN using the
   default instanceID, but a change of instanceID would permit an
   attacker to bypass such filtering.  Like the RH3, a RPI header is to
   be inserted by the RPL root on traffic entering the LLN by first
   inserting an IPv6-in-IPv6 header.  The attacker's RPI header
   therefore will not be seen by the network.  Upon reaching the
   destination node the RPI header has no further meaning and is just
   skipped; the presence of a second RPI header will have no meaning to
   the end node as the packet has already been identified as being at
   it's final destination.

This text does not really convince me that it considers the non-storing
case where a packet is directed to a non-6LR-aware leaf, and the last
6LR removes the IPv6-in-IPv6 encapsulation prior to sending the packet
on to the IPv6 node.

   Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an
   attack on another part of the LLN, while disguising the origin of the
   attack.  The mechanism can even be abused to make it appear that the
   attack is coming from outside the LLN, and unless countered, this
   could be used to mount a Distributed Denial Of Service attack upon
   nodes elsewhere in the Internet.  See [DDOS-KREBS] for an example of
   such attacks already seen in the real world.

It's not really clear to me that [DDOS-KREBS] is illustrative of
IPv6-in-IPv6 spoofing from a LLN.

   If an attack comes from inside of LLN, it can be alleviated with SAVI
   (Source Address Validation Improvement) using [RFC8505] with
   [I-D.ietf-6lo-ap-nd].  The attacker will not be able to source with

nit: is "source with" a common term?

   an address that is not registered, and the registration checks for

nit: "registration process"?

   topological correctness.  Notice that there is an L2 authentication
   in most of the cases.  If an attack comes from outside LLN IPv6-in-
   IPv6 can be used to hide inner routing headers, but RH3 is protected
   by its definition.

Protected from what?  How?

   Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic
   through the RPL root to perform this attack.  To counter, the RPL
   root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the
   simpler solution), or it SHOULD do a deep packet inspection wherein
   it walks the IP header extension chain until it can inspect the
   upper-layer-payload as described in [RFC7045].  In particular, the

RFC 7045 does not use the term "deep packet inspection", that term has
negative connotations for many people, and it's not entirely clear that
it's the right term to describe the process of fully parsing the IPv6
headers, either.

---

From: Ines Robles <[email-masked]>
Date: Thu, 2 May 2019 17:05:51 +0300

Thank you Benjamin,

We will work on the comments.

Best,
Ines

---

From: Ines Robles <[email-masked]>
Date: Fri, 17 May 2019 11:35:51 +0300

Hi Benjamin,

Many Thanks for your detailed review. We have submitted a new version with
corrections. Please find answers in-line.

<author> fixed to hop-by-hop </author>

> from a ~Raf to a ~Raf -- Section 6.3.4 says addressed to the ~Raf, but

<author> fixed to hop-by-hop </author>

> text in Section 7.1.2 is unconditional that the 6LBR inserts an RPI
<author>fixed. Previous ideas was that downwards traffic could optionally
omit the RPI, but RPI is needed for quality of service, so no longer
optional</author>

> Figure 8 has a "must" in that column.

<author> Corrected to: Table 8 “must” changed by “No”

</author>

> "which must be in an IPv6-in-IPv6 header addressed to the root".)

<author>Corrected to: The originating node must put the RPI into an
IPv6-in-IPv6

               header addressed to the root </author>

> information", and a SHOULD-level requirement is not enough to guarantee

<author> Corrected to: changed to MUST </author>

> In Figure 8, what does "Opt" mean in the "RPI" column?

<author> Corrected Figure 7 to:   ~Raf to ~Raf changed from “Yes” to “must” in
the "IPv6-in-IPv6" column

Added in the text for figure 7: The root refers to the 6LBR.

</author>

<author>  New Paragraph: The ROLL WG analyzed how [RFC2460] rules apply to
storing and non-

  storing use of RPL.  The result was 24 data plane use cases.  They

  are exhaustively outlined here in order to be completely unambiguous.

  During the processing of this document, new rules were published as

  [RFC8200], and this document was updated to reflect the normative

  changes in that document.

</author>

> on the *inner* IPv6 representation?

<author> corrected to hop-by-hop re-encapsulation </author>

> explanation of the nature of my confusion.

<author> You have made the right conclusion.  How can we make the text
clearer that your conclusion is the desired one?</author>

> special discussion.  Is there anything useful to say about it?

<author> The above paragraph is part of the discussion/analysis of why/when
the type change is justified.  The downward non-storing case does not
specifically benefit, because it always has to add an IPv6-in-IPv6 header,
and it can always address the traffic in such a way that the header can be
removed.  However, in both storing and non-storing cases, the traffic from
RPL nodes to the Internet (MP2P traffic, i.e. sensor traffic) benefit from
simpler processing by being able to leave the RPI header in place for the
transit across the Internet.  If it would be simpler, the above paragraph
could be removed.</author>

> information contained therein, that is relevant for this decision?

<author> Corrected to: based upon the presence of the flag in the DIO
Configuration Option defined

</author>

> I'm also not entirely sure how this sentence is supposed to tie in to

<author> “no conditional branches in the processing flow” is intended.  We
have changed the ambiguity.</author>

> Figure 3 is pretty sparsely annotated.
<author> Figure 3 was changed for the correct one. </author>

> In Figure 5, why does the line from D to B have an arrowhead but none of

<author> fixed </author>

> to the internet?  Is there something useful we could add via this

<author>The answer: There is no TLV present in the RPI. Consuming space in
the ipv6 header and it might consume of resources in the routers.

</author>

> Also, I agree with the secdir reviewer that "at worst" should be "at a

<author> fixed </author>

> (That is, the "MUST" is probably not appropriate.)

<author> This entire document is repeating RFC8200 rules with specific
examples, so that nobody will be confused. We inserted “e.g.”</author>

> possible to use descriptive rather than normative language.

<author> since RPI is no longer optional. We deleted that part. </author>

> nit: s/rational/rationale/

<author> fixed </author>

> these tables are pretty complicated as-is, so every bit helps!

<author> New Paragraph:  The following table (Figure 7) itemizes which
headers are needed in

  each of the following scenarios.  It indicates if the IPv6-in-IPv6

  header that is added, must be addressed to the final destination (the

  Raf node that is the target(tgt)), to the "root" or if a hop-by-hop

  header must be added (indicated by "hop").

The tables were fixed to be clearer.

</author>

> nit: singular/plural mismatch with "packet" and "go through"
<author> fixed </author>

> node D was intended rather than node E.
<author> fixed </author>

> Should we say what the IPv6-in-IPv6 destination address is set to in

<author> Corrected To:

When the packet arrives from Internet to 6LBR the RPI header is added
   in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination
   address set to the 6LR) and sent to 6LR, which modifies the rank in
   the RPI.  When the packet arrives at 6LN the RPI header is removed

   and the packet processed.
</author>

> Why does the 6LBR not remove headers in the the IPv6-in-IPv6(RPI)(2) case?

<author> Fixed: added in the table for the 6LBR: <c>IPv6-in-IPv6(RPI)(1)(2)
</c>

</author>

> I'm not sure how to interpret the Table.  Does the IPv6 node remove the

<author>Answer: The IPv6 node removes the header and does not process the
RPI, the node ignores the RPI (this is normal IPv6 INPUT packet processing
when a packet arrives at the destination, processing extension headers
until the Upper Layer Protocol is reached).

</author>

> <author>Deleted this part: “This may be done regardless of where the
destination is, as the included RPI will be ignored by the receiver.”
</author>

> Is the root considered to be a 6LR_ia or a 6LR_id?

<author> fixed, root added to the table </author>

> I'm still not seeing a difference in where the IPv6-in-IPv6 header is

<author>fixed, we deleted that sentence </author>

> or 6LBR"?  It may be worth a few words to clarify that.

<author>Corrected to:

Old: There are these possible situations: target destination address
possible (indicated by "tgt"), to a 6LR, to a 6LN or to the root.

New: It depicts the target destination address possible (indicated by
"tgt"), to a 6LR (parent of a 6LN), to a 6LN or to the root.

</author>

> available for priority/channel selection at each hop" is better wording?

<author>Corrected as suggested in the text: The leaf can be a router 6LR or
a host, both indicated as 6LN

   (Figure 3).  In the Figure the (1) indicates a 6tisch case [RFC8180
<https://tools.ietf.org/html/rfc8180>],
   where the RPI header may still be needed for the instanceID to be
   available for priority/channel selection at each hop.

</author>

> nits: "to be", and no comma is needed.

<author>fixed </author>

> optionally added (for the 6tisch case where the instanceID is needed).

<author> we deleted the optionality of RPI </author>

> by the 6LR_i in this case but not in Section 7.1.2.

<author>fixed </author>

> Table 15 should probably keep the parentheses around "(opt: RPI)" in the

<author>fixed </author>

> column, and instead break out a 6LR_n column as is done in (e.g.)
<author>fixed </author>

> have us include the "IPv6-in-IPV6()" indicator in the "Modified headers"
<author>fixed </author>

> Some textual discussion in the Table legend would be very helpful,
<author>fixed </author>

> the generic 6LR_ia are modifying the IPv6-in-IPv6(RPI_1) headers?

<author>fixed </author>

> 6LRs that merely modify the RPI headers, though I recognize space

<author>fixed </author>

> prior to the leaf" or similar

<author> Added in Text: For example, in Figure 5, node E is the 6LR prior
to the leaf node G, or node C is the 6LR prior to the leaf node J.</author>

> detected by the root would be helpful.

<author> Added in Text: The DODAG Configuration option is contained in a
RPL DIO message, which contains a unique DTSN counter.  The leaf nodes
respond to this message with DAO messages containing the same DTSN. This is
a normal part of RPL routing; the RPL root therefore knows when the updated
DODAG Configuration Option has been seen by all nodes. </author>

> path is the same as it ever was.

<author> fixed, changed to migration procedure </author>

> LLN!" (or similar) would be clearer.

<author> fixed </author>

> nature of the precautions.

<author> fixed </author>

> things that are equivalent?

<author> added:” equivalent (to

  disguise the origin of traffic and attack other nodes) “

</author>

> 6LR removes the IPv6-in-IPv6 encapsulation prior to sending the packet

<author> This is a good point, thank you for observing this. You are right
that the 6LR that removes the outer IP/RH3/RPI will then possibly be
mistaken by the inner RPI inserted by the attacker.  Do you think it is
enough to declare that further RPI processing must be skipped by such a
final router? we do not think that we have a use case for a legitimate RPI
header here. </author>

> IPv6-in-IPv6 spoofing from a LLN.

<author> DDOS-KREBS is an example of high-bandwidth attacks being
constructed from millions of relatively low-bandwidth senders. It is not an
IPv6-in-IPv6 spoofing attack, as the script kiddies are as yet,
IPv6-ignorant and LLNs are uncommon.

</author>

> nit: is "source with" a common term?

<author> replaced by “source traffic” </author>

> nit: "registration process"?

<author> fixed </author>

> Protected from what?  How?

<author>

Old text: but RH3 is protected by its definition.

new text: but by construction, the RH3 can typically only address nodes
within the LLN.  That is, a RH3 with a CmprI less than 8 , should be
considered an attack (see RFC6554, section 3).

</author>

>  <author> corrected to: "... or it SHOULD walk the IP header extension chain

   until it can inspect the upper-layer-payload as described in

   [RFC7045 <https://tools.ietf.org/html/rfc7045>]..."

</author>

Many thanks again for the detailed review

Best regards,

Ines, Michael and Pascal.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 May 2019 21:22:21 -0700

> corrections. Please find answers in-line.

Thanks; I'll go clear my position in the datatracker.
Further notes on the comments inline...

> clearer that your conclusion is the desired one?</author>

Perhaps, "Given the current consensus regarding processing of hop-by-hop
options by intermediate routers (in particular, that in many cases it is
acceptable to skip over such options), it is appropriate for this
document to embrace an expectation of skipping.  Accordingly, this
document updates the Option Type [...]"?

> could be removed.</author>

I am happy to see this paragraph stay as-is; I just wanted to check if
there was anything else to add, but it sounds like there is not.

> the ipv6 header and it might consume of resources in the routers.

I'm not sure what is meant by "There is no TLV present in the RPI" --
I was looking at Figure 1 from RFC 6553, that does show a space for
"(sub-TLVs)".  Was I looking in the wrong place?

> until the Upper Layer Protocol is reached).

This seems pretty clear now on a re-read, so I guess I was just tired or
something the first time around; sorry for the noise.

> to the leaf node G, or node C is the 6LR prior to the leaf node J.</author>

To be clear, this was just intended to be a grammar nit and not a
request for further clarification.

> final router? we do not think that we have a use case for a legitimate RPI

I think that requiring the final router to skip further RPI processing
will suffice, yes.

> IPv6-ignorant and LLNs are uncommon.

Perhaps "an example of the potential consequences of DDoS attacks, even
in the non-spoofed case" would be friendlier to the reader, then?

> considered an attack (see RFC6554, section 3).

Thank you; that helps me a lot!

> Many thanks again for the detailed review

You're welcome, and thanks for all the updates to the document.

-Ben

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 29 May 2019 14:21:33 -0700

Hello folks,

Due to a lot of confusion on my end, this IoT-Dir review is very very 
late.  I hope it will be found to be useful.

I think the draft needs a bit of work before it can be published.  I 
have quite a few editorial comments and a couple of important technical 
concerns.

I started to review revision ...25.txt, but before I could finish that 
review, we were already up to revision ...29.txt so I started over with 
that revision.  Most of these are represented, albeit incompletely, in 
the attached file.

My main technical concern has to do with the attempt to classify RPI 
Option Types 0x23 and 0x63 as somehow being variants of the same Option 
Type.  I don't think this is really legitimate; they have to be 
considered to be two different Options.  I believe the idea is that it 
should be simple to implement both together, and type 0x23 is likely to 
survive traversal of the Internet.  An intermediate device that 
implements 0x63 but not 0x23 will not process any of the configuration 
options present in 0x23, but at least the packet won't be dropped.  I'm 
not sure how serious this problem is for intermediate 6LRs in the path 
of a 0x23 packet traversing the LLN, but those configuration options are 
meant for consumption by such intermediate 6LRs.

One thing that would help, is to include in the overview a very succinct 
list of design requirements and also a list of assumptions made during 
the design.  I had wanted to create this list but that would take 
another day.  Here is a start, and I hope that any misunderstanding that 
I have will be minor:

Requirements:

1. RPI has to be in every packet that traverses the LLN
2. Because of (1), packets from the Internet have to be encapsulated
3. Extension headers may not be added or removed except by the sender or 
the receiver
4. Packets that will traverse RPI-unaware nodes need encapsulation, but 
only sender or receiver can add the new RPI option (0x23)
5. Non-storing mode requires downstream encapsulation by root for RH

Assumptions:

- Each IPv6 node (including Internet routers) obeys RFC 8200, so that 
0x23 RPI can be safely inserted.
- All 6LRs obey RFC 8200

These requirements and assumptions determine the entries in the dozens 
of tables included within the document.  Without a clear grasp of them, 
it is easy to get lost in the sea of details about header insertion and 
encapsulation.

Most of my many comments are editorial.  I think that the draft could be 
easier to read with fewer digressions, and more consistent use of 
acronyms.  I have made a great many example revisions directly into the 
attached text file, which I hope will receive consideration by the 
authors.  Each editorial comment individually is typically less 
important than a technical error, but taken together I think they would 
greatly  promote readability and thus increase the likelihood that 
implementers will be able to understand the intention of the 
specification.   I have also inserted additional comments into the file, 
tagged by my initials "CEP:".   Here are some overall comments.

  *   not-RPL-aware --> RPL-unaware
  *   Raf could be confused as "RPL-aware forwarder".   Please change
    acronyms.  One possibility: ~Raf --> RuL,   Raf --> RaL  (for.,
    "RPL-aware-Leaf", "RPL-unaware-Leaf", respectively)
  *   Since the document already uses acronyms in an essential way,
    please also use them to improve clarity and shorten subsection
    titles, etc.
  *   Captions to figures and subsection titles should typically fit on
    a single line

I would like to verify the design assumptions and design requirements, 
and then use that knowledge to check the details of each of the 24 use 
cases.  One improvement that would be *very* helpful for this purpose, 
would be to assert *which* of the design requirements underlies each 
matrix entry for the 24 summary tables.

Regards,
Charlie P.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2019 18:53:01 -0400

Charlie Perkins <[email-masked]> wrote:
    > My main technical concern has to do with the attempt to classify RPI Option
    > Types 0x23 and 0x63 as somehow being variants of the same Option Type.  I
    > don't think this is really legitimate; they have to be considered to be two
    > different Options. 

Would IANA allocate options that differ only in the option action bits?
The registry has the following text:

   Each distinct 8-bit Option Type identifies a different option, i.e., the
   high-order 3 bits are considered part of the option identification.
   However, it is recommended that Option Types be assigned with distinct
   values in the "rest" subfield, until and unless that 5-bit space becomes
   full.

But, my question is, what would the material effect on the document be if we
considered it a different Option?

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

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 29 May 2019 16:56:50 -0700

Hello Michael,

> considered it a different Option?

I don't think this is a fatal flaw.  I provided alternative text in a 
lot of places that seems more accurate for the specification of a new 
Option Type instead of a "related" type of an existing Option Type (I'm 
not really sure how to express this).

Maybe the main thing is to emphasize that a 0x63-cognizant node probably 
cannot interpret the "RPI 0x23 enable" Configuration Option bit of the 
DIO unless that node is also 0x23-cognizant.  By the way, is Bit number 
3 the bit next to the 'A' bit?  How does the 0x63-cognizant node 
communicate to the root that it didn't understand the "RPI 0x23 enable" bit?

I wish I had had time to go through all of the 24 use cases.  Do you 
agree with my lists of design assumptions and design requirements?  I 
probably left something out, sigh.

Regards,
Charlie P.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 09:53:14 -0400

Charlie Perkins <[email-masked]> wrote:
    > cannot interpret the "RPI 0x23 enable" Configuration Option bit of the DIO
    > unless that node is also 0x23-cognizant.  By the way, is Bit number 3 the bit
    > next to the 'A' bit?  How does the 0x63-cognizant node communicate to the
    > root that it didn't understand the "RPI 0x23 enable" bit?

At this point, it would have to be a proprietary knowledge; you either
deployed the new firmware, or you didn't. Since firmware upgrades cost
bandwidth, and require restarts... therefore could take days to weeks to
deploy, you don't enable 0x23 until you are sure everything on your LLN
understands it.
Implementations could eventually withdraw support for 0x63, saving some code.

But, this is the goal of a capabilities report in the DAO.
(I thought someone had a draft for that)

    > I wish I had had time to go through all of the 24 use cases.  Do you agree
    > with my lists of design assumptions and design requirements?  I probably left
    > something out, sigh.

I liked it that text, and we will try to use it.