Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-23

[Ines Robles <[e-mail]>]

Hi Alvaro,

Thank you very much for the review.

We have created this ticket:
https://trac.ietf.org/trac/roll/ticket/186#ticket to address your comments.

We are going to analyze them and we will get back to you.

Thanks,

The authors.

2018-08-14 22:04 GMT+03:00 Alvaro Retana <[e-mail]>:

> Dear authors:
>
> I have (finally!) finished reading this document.  Thanks for all the work
> and time put into working out all the details.
>
> I have several concerns.  I'm listing some of the Major (and document-wide)
> ones up front.  I also put more comments and questions inline below.
>
> (1) [major] Where is the specification of the data-plane behavior?
>
> This document does a couple of things: it Updates several other RFCs, and
> presents a list of *example* flows where the expected behavior is
> illustrated.  The Updates are mostly about the new RPI value (0x23), but
> not about the behavior of the nodes.
>
> Most of the examples are worded such that they describe actions
> (encapsulate, remove, etc.)...and some even include rfc2119 Normative
> Keywords.  But they are called examples!  So...my questions are: is the
> behavior illustrated in §6 and §7 intended to be Normative?  IOW, do these
> sections include both examples and specify the behavior expected in the
> LLN?  Is the behavior already specified somewhere else (and this document
> is just illustrating)?  [I am asking that last question just-in-case,
> because the Introduction says that "this document clarifies what is the
> correct and the incorrect behaviour."]
>
> §8 seems to attempt to summarize "observations about the cases", but (if it
> is intended to be *the* Normative text about the behavior) it is general
> and short.
>
> [Some of my comments below ask about Normative language... Please take
> those in context with the answers here.]
>
>
> (2) [major] Operational Considerations
>
> Non-storing mode networks don't need the change to 0x23 (§8.2)...but making
> the change creates a flag day, and even then, implementations should still
> process both values (§3.1).  I would really like to see text about the
> operational considerations of introducing 0x23.  It concerns me that a
> significant change that most[*] networks don't need is being introduced.
> Please take a look at rfc5706 (Guidelines for Considering Operations and
> Management of New Protocols and Protocol Extensions), specially §2.
>
> [*] Most deployed networks work in non-storing mode, right?
>
>
> (3) [minor] >= ??
>
> There are several (25!) instances of text like this:
>
>    6LR_i are the intermediate routers from source to destination.  In
>    this case, "1 <= i >= n", n is the number of routers (6LR) that the
>    packet go through from source (6LN) to destination (6LBR).
>
> Maybe it's just me, but I don't understand why (or how!) i could ever be >=
> n.  The text says that i are the "intermediate routers from source to
> destination", while n is "the number of routers...from source (6LN) to
> destination (6LBR)".  Isn't that the same thing?  What am I missing?
>
>
> (4) Style nit: the document uses "we"...a third person style would be
> preferable.  For example: s/In this section we are going to
> describe.../This section describes...
>
>
> I will wait for the major points to be addressed before starting the IETF
> LC.
>
> Thanks!!
>
> Alvaro.
>
>
>
> [Note: the numbers came from the idnits output.]
>
> ...
> 10              When to use RFC 6553, 6554 and IPv6-in-IPv6
> 11                    draft-ietf-roll-useofrplinfo-23
>
> [minor] Can we come up with a more descriptive tittle?  Also, the
> "shorthand" version ("Useof6553") could be improved.
>
>
> ...
> 130 1.  Introduction
> ...
> 156   The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)
> 157   [RFC8138] defines a method to compress RPL Option information and
> 158   Routing Header type 3 [RFC6554], an efficient IP-in-IP technique, and
> 159   use cases proposed for the [Second6TischPlugtest] involving 6loRH.
>
> [nit] I'm having trouble parsing this last paragraph.  It sounds like
> rfc8138 (also) defines the use cases, but I don't remember seeing anything
> like that in there.  Is that what you meant?
>
> [nit] I think the Introduction would benefit from an overview of the
> document; something like "section X talks about abc, section Y presents
> examples, etc.".
>
> 161 2.  Terminology and Requirements Language
>
> 163   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> 164   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> 165   document are to be interpreted as described in RFC 2119 [RFC2119].
>
> [major] Please use the RFC8174 template.
>
> ...
> 170   RPL-node: A device which implements RPL, thus we can say that the
> 171   device is RPL-capable or RPL-aware.  Please note that the device can
> 172   be found inside the LLN or outside LLN.  In this document a RPL-node
> 173   which is a leaf of a DODAG is called RPL-aware-leaf.
>
> [nit] RPL-capable is not used anywhere else.
>
> ...
> 180   pledge: a new device which seeks admission to a network. (from
> 181   [I-D.ietf-anima-bootstrapping-keyinfra])
>
> 183   Join Registrar and Coordinator (JRC): a device which brings new nodes
> 184   (pledges) into a network. (from
> 185   [I-D.ietf-anima-bootstrapping-keyinfra])
>
> [minor] Do these two terms need to be defined in this document?  They are
> only used once, and with a reference to
> I-D.ietf-anima-bootstrapping-keyinfra next to them.  Also, and more
> important, the definition here doesn't match the one in that other draft.
> Please take out the definitions and just make reference later on...
>
> 187   Flag day: A "flag day" is a procedure in which the network, or a part
> 188   of it, is changed during a planned outage, or suddenly, causing an
> 189   outage while the network recovers [RFC4192]
>
> [nit] rfc4192 seems like an odd place to pull a reference to "flag day" --
> specially as it is being defined as "a procedure" and not the effect it
> causes, which seems to be how it is used in the text: "creates a flag day",
> "will experience a flag day", "avoid a flag day".  This is not a big issue
> -- if it was up to me, I would either make my own definition, or just not
> define it at all: I think it is a well known term...
>
> 191 2.1.  hop-by-hop IPv6-in-IPv6 headers
>
> 193   The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
> 194   that originates from a node to an adjacent node, using the addresses
> 195   (usually the GUA or ULA, but could use the link-local addresses) of
> 196   each node.  If the packet must traverse multiple hops, then it must
> 197   be decapsulated at each hop, and then re-encapsulated again in a
> 198   similar fashion.
>
> [minor] That term is not used anywhere...but "hop-by-hop IP-in-IP" is.
>
> IPv6-in-IPv6 and IP-in-IP are used interchangeably throughout the
> document.  This use is not wrong, but it is inconsistent.  Adding a note
> about it (even though it may be obvious to many readers that the terms
> refer to the same thing) would be nice...being consistent even nicer.
>
> Later on, "IPIP" is also used...
>
>
> [nit] Why is this definition in its own sub-section?
>
> 200 3.  Updates to RFC6553, RFC6550 and RFC 8138
>
> 202 3.1.  Updates to RFC 6553
>
> ...
> 209   [RFC6553] states as showed below, that in the Option Type field of
> 210   the RPL Option header, the two high order bits MUST be set to '01'
> 211   and the third bit is equal to '1'.  The first two bits indicate that
> 212   the IPv6 node MUST discard the packet if it doesn't recognize the
> 213   option type, and the third bit indicates that the Option Data may
> 214   change en route.  The remaining bits serve as the option type.
>
> s/showed/shown
>
> [major] The 2 MUSTs used above are used paraphrasing rfc6553, and don't
> define Normative behavior in this document.  Please either use a direct
> quote, or use non-normative language.
>
> ...
> 223   Recent changes in [RFC8200] (section 4, page 8), states: "it is now
> 224   expected that nodes along a packet's delivery path only examine and
> 225   process the Hop-by-Hop Options header if explicitly configured to do
> 226   so".  Processing of the Hop-by-Hop Options header (by IPv6
> 227   intermediate nodes) is now optional, but if they are configured to
> 228   process the header, and if such nodes encounter an option with the
> 229   first two bits set to 01, they will drop the packet (if they conform
> 230   to [RFC8200]).  Host systems should do the same, irrespective of the
> 231   configuration.
>
> [minor] The description above seems to be missing "...if the option is not
> recognized".
>
> 233   Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
> 234   receives a packet with an RPL Option, it should ignore the HBH RPL
> 235   option (skip over this option and continue processing the header).
>
> s/That/that
>
> ...
> 266   When forwarding packets, implementations SHOULD use the same value as
> 267   it was received (This is required because, RPI type code can not be
> 268   changed by [RFC8200]).  It allows to the network to be incrementally
> 269   upgraded, and for the DODAG root to know which parts of the network
> 270   are upgraded.
>
> [major] There seems to be a contradiction above: "SHOULD use the same
> value...this is required..."   If required by rfc8200, why not use MUST?
>
> 272   When originating new packets, implementations SHOULD have an option
> 273   to determine which value to originate with, this option is controlled
> 274   by the DIO option described below.
>
> [minor] §3.3 defines the option...but it doesn't explicitly say what the
> receivers should do with it.  It may be obvious, but it should be explicit
> for completeness.
>
> [major] It seems to me that the paragraph above may be out of place,
> doesn't say much, may be wrong...or maybe all 3.  The text says that the
> originating value is controlled by the option in §3.3 (again, but that
> section doesn't explicitly say what should be done)...but it also says
> (with the SHOULD) that an implementation may have valid reasons to not pay
> attention to the option -- what are those??
>
>
> ...
> 281 3.2.  Updates to RFC 8138
>
> 283   RPI-6LoRH header provides a compressed form for the RPL RPI
> 284   [RFC8138].  It should be considered when the Option Type in RPL
> 285   Option is decompressed, should take the value of 0x23 instead of
> 286   0x63.
>
> [major] AFAICT, the compression specified in rfc8138 doesn't include the
> RPI option type...but the use of the 6LoRH Type 5 implies the RPI.  If I
> got that right, then how would the decompressing node know which RPI type
> was in use when first compressed?  Given that both types may be used in a
> network (§3.1), how would one know unless the 6LoRH type was also changed?
> Or are you suggesting that the decompression should always use 0x23?  In
> any case, I think that stronger language might be needed.
>
>
> 288 3.3.  Updates to RFC 6550: Indicating the new RPI in the DODAG
> 289      Configuration Option Flag.
>
> 291   In order to avoid a flag day caused by lack of interoperation between
> 292   new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new
> 293   nodes and old nodes, the new nodes may be put into a compatibility
> 294   mode until all of the old nodes are replaced or upgraded.
>
> 296   This can be done via a DODAG Configuration Option flag which will
> 297   propogate through the network.  Failure to receive this information
> 298   will cause new nodes to remain in compatibility mode, and originate
> 299   traffic with the old-RPI (0x63) value.
>
> s/propogate/propagate
>
> [major] "compatibility mode"
>
> What is "compatibility mode"?  Initially I thought that it was maybe the
> ability of new nodes to use both RPI values...but the end of the second
> paragraph suggests using only 0x63.
>
> The text suggests that "compatibility mode" can be enabled via "via a DODAG
> Configuration Option flag" -- that flag is not defined anywhere...but
> "failure to receive this information will cause new nodes to remain in
> compatibility mode".  So...would it be enabled using a flag, or is it the
> default?
>
> Why wouldn't the default be the new RPI?  I can see how most of the
> networks will support the old RPI, but that will eventually be the
> exception...
>
> 301   As stated in [RFC6550] the DODAG Configuration option is present in
> 302   DIO messages.  The DODAG Configuration option distributes
> 303   configuration information.  It is generally static, and does not
> 304   change within the DODAG.  This information is configured at the DODAG
> 305   root and distributed throughout the DODAG with the DODAG
> 306   Configuration option.  Nodes other than the DODAG root do not modify
> 307   this information when propagating the DODAG Configuration option.
>
> 309   The DODAG Configuration Option has a Flags field which is modified by
> 310   this document.  Currently, the DODAG Configuration Option in
> 311   [RFC6550] is as follows. .
>
> 313   Flags: The 4-bits remaining unused in the Flags field are reserved
> 314   for flags.  The field MUST be initialized to zero by the sender and
> 315   MUST be ignored by the receiver.
>
> 317 0                       1                    2                     3
> 318 +-----------------+-----------------------------------------
> ----------+
> 319 |  Type = 0x04    |  Opt Length = 14| Flags  | A | PCS| DIOIntDoubl.  |
> 320 +-----------------------------------------------------------
> ----------+
> 321 | DIOIntMin.      |  DIORedund.     |  MaxRankIncrease                |
> 322 +-----------------+-----------------------------------------
> ----------+
> 323 |  MinHopRankIncrease               |            OCP                  |
> 324 +-----------------+-----------------------------------------
> ----------+
> 325 |Reserved         | Def. Lifetime   |         Lifetime Unit           |
> 326 +-----------------+-----------------+-----------------------
> ----------+
>
> 328                   Figure 3: DODAG Configuration Option.
>
> [minor] Suggestion: instead of copying (and not quoting the Normative
> language) the text from rfc6550 above, just indicate what the Update is:
> "the unused bits MUST...".  Also, I think that Figure 3 is not needed.
>
>
> ...
> 342   In case of rebooting, the node does not remember the flag.  Thus, the
> 343   DIO is sent with flag indicating the new RPI value.
>
> [minor] By "the node", which node are you referring to?  The root?  If it
> doesn't remember, it means that it needs to be configured -- how does that
> happen?  Why isn't the configuration persistent at the root?
>
> 345 4.  Sample/reference topology
>
> 347   A RPL network in general is composed of a 6LBR (6LoWPAN Border
> 348   Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
> 349   (6LoWPAN Node) as leaf logically organized in a DODAG structure.
> 350   (Destination Oriented Directed Acyclic Graph).
>
> [minor] The 6BBR doesn't appear in the Figure.
>
> [nit] BTW, it might be better to put the topology diagram right after this
> first paragraph.
>
> [nit] The DODAG expansion should be on first use.
>
> 352   RPL defines the RPL Control messages (control plane), a new ICMPv6
> 353   [RFC4443]  message with Type 155.  DIS (DODAG Information
> 354   Solicitation), DIO (DODAG Information Object) and DAO (Destination
> 355   Advertisement Object) messages are all RPL Control messages but with
> 356   different Code values.  A RPL Stack is showed in Figure 5.
>
> [minor] Not exactly sure what this paragraph has to do with the reference
> topology (yet), but (same comment as above) it might be good to put the
> figure right after the text.
>
> s/showed/shown
>
>
> ...
> 428                    Figure 6: A reference RPL Topology.
>
> 430   Figure 2 shows the reference RPL Topology for this document.  The
> 431   letters above the nodes are there so that they may be referenced in
> 432   subsequent sections.  In the figure, 6LR represents a full router
> 433   node.  The 6LN is a RPL aware router, or host.
>
> s/Figure 2/Figure 6
>
> [minor] The 6LN is defined in the first paragraph as a node (not a
> router).  BTW, what is the difference between a "full router" and (just) a
> "router" (6LR vs 6LN)?
>
> [minor] 6LN is characterized above as "RPL aware", but (below) the "Raf"
> mark is also used for that -- so it seems that "~Raf 6LN" would be a
> "not-RPL aware leaf...RPL aware router, or host".
>
> Some terminology clean up is needed.
>
> 435   But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I)
> 436   are RPL nodes with no children hosts.
>
> [minor] Is there a relevance to the "children hosts" existing?  Can it be
> concluded that ~Raf nodes have children hosts?
>
>
> ...
> 446 5.  Use cases
> ...
> 507   This means that when the no-drop RPI option code 0x23 is used, a
> 508   packet that leaves the RPL domain of an LLN (or that leaves the LLN
> 509   entirely) will not be discarded when it contains the [RFC6553] RPL
> 510   Hop-by-Hop option known as RPI.  Thus, the RPI Hop-by-Hop option MAY
> 511   be left in place even if the end host does not understand it.
>
> [minor] If the last RPL-aware node knows that the host doesn't understand
> the RPI, why would it not remove it (if it can)?  IOW, I understand how it
> causes no harm (leading to the optional behavior above), but just because
> it can be done doesn't mean that it should.  Are there cases where it can
> be used for something?
>
> If the RPI can't be removed because the border is not the destination, then
> the MAY above is insignificant: no one can strip it, so there's no real
> option.
>
> 513   NOTE: There is some possible security risk when the RPI information
> 514   is released to the Internet.  At this point this is a theoretical
> 515   situation; no clear attack has been described.  At worst, it is clear
> 516   that the RPI option would waste some network bandwidth when it
> 517   escapes.  This is traded off against the savings in the LLN by not
> 518   having to encapsulate the packet in order to remove the artifact.
>
> [major] AFAICT, leaking the RPI means leaking the RPLInstanceID and the
> SenderRank.  The Security Considerations already mentions what an attacker
> could do if it knows the RPLInstanceID...but it doesn't say anything about
> the SenderRank.
>
> I'm thinking that the SenderRank may help an attacker to have an idea of
> the topology of the LLN, right?  I don't know what an attacker can do with
> that information, but the fact that could be used for that (and it could be
> a privacy issue) should be mentioned in the Security Considerations section