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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.