Re: [Roll] Datatracker State Update Notice: <draft-ietf-roll-useofrplinfo-23.txt>

[Ines Robles <[e-mail]>]

Thank you Alvaro for your comments. We are going to work on those and get
back to you.

Cheers, Ines.

On Wed, Jan 30, 2019 at 6:01 PM Alvaro Retana <[e-mail]>
wrote:

> On January 23, 2019 at 5:06:24 PM, Ines Robles (
> [e-mail]) wrote:
>
> [Explicitly adding the Chairs, the Shepherd and the Authors’ alias…just
> for completeness, even though everyone should be in the WG list and there’s
> overlap. ;-)  ]
>
> Ines:
>
> Hi!
>
> I have some comments below, please take a look.  Many of these comments
> are minor and nits — the significant items that I think we should settle on
> before starting the IETF LC are:
>
> - “normative examples” (point #1 below): I’ll let you chose how you want
> to move forward (see below)
> - Operational Considerations (§9) is WIP
> - dependency on I-D.thubert-roll-unaware-leaves (look for line 894)
>
> Thanks!!
>
> Alvaro.
>
>
> ...
>
> (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?
>
>
>
> [authors]The examples are intended to illustrate the result of the
> normative language in RFC8200 and RFC6553.
> So the examples are intended to be normative explanation of the results of
> executing that language.
>
>
>
>> 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)?
>
>
> [authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and
> section 4, “The Hop-by-Hop Options…”
> Combined with the desired results of  RFC6553, we conclude that we have to
> change the option value in order to make things work.
>
> I understand what you’re trying to do.
> To me, a “Normative example” is an impossible oxymoron: it’s either an
> example or it is a Normative specification of the behavior.
>
> In this document, the scenarios (maybe a better word than example,
> specially given how exhaustive the document is in considering all the
> possibilities) are not consistently treated as not all of them are
> described using Normative language.  Being consistent is *very* important
> given that we’re dealing with Normative language...
>
> **But** my heartburn really flares up when you mention "the normative
> language in RFC8200...” because rfc8200 doesn’t use rfc2119 keywords at
> all. :-(  The use of rfc2119 language is a completely separate discussion,
> but using it here as an interpretation of what is meant in rfc8200 is a
> stretch…at least to me.
>
> What do I want to see?  I would prefer to see the scenarios described NOT
> using rfc2119 keywords: simply changing the case would be enough.
>
> I don’t want to turn this review into a debate around rfc2119 and much
> less about how to interpret rfc8200.  If you really, really prefer to keep
> the Normative language, please be consistent (use it in all the
> scenarios).  We can see if anyone else in the IESG picks up on this same
> point or not…
>
> ...
>
> (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?
>>
>
> [authors]following our understanding, mostly yes.
> but, e.g. Anima network in storing mode. Not having loop detection.
>
> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#section-6.11.1.3
>
>
> Thanks for including Operational Considerations.  §8 looks good to me…and
> I see that §9 is still WIP.
>
>
> ...
>
> [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.".
>
>
> [authors]added
>
> This new section mentions the old §9.
>
>
> ...
>
> 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...
>>
>
> [authors]fixed. rewritten
>
> New text:
>
> 217	   Flag Day: A transition that involves have a network with different
> 218	   values of RPL Option Type.  Thus the network do not work correctly.
>
> s/involves have a network/involves having a network
>
> s/network do not work/network does not work
>
> Also, the reference to rfc4192 is not needed anymore.
>
> ...
>
> ...
>
> 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?
>>
> [authors]rewritten
>
>>
>> 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.
>>
> [authors]rewritten
>
>>
>> [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??
>>
>
> [authors]rewritten to
> "In the cases where a forwarding node is forwarding traffic that is not
>            addressed directly to it (such as when the outer IPv6-in-IPv6
> header is not a Link-Local address),
>            then RFC8200 forbids changing the RPI type code when forwarding.
>
>            When forwarding traffic that is wrapped in Link-Local
> IPv6-in-IPv6 headers,
>            the forwarding node is in effect originating new packets,
>            and it MAY make a choice as to whether to use the old (0x63)
> RPI Type code,
>            or the new (0x23) RPI Type code. In that situation,
> implementations SHOULD
>            use the same value as was received.  This allows to the network
> to be incrementally upgraded,
>            and in some cases may allow the DODAG root to know which parts
> of the network are upgraded."
>
> Ok, that looks good.
>
> You also added:
>
> 323	   Non-constrained uses of RPL are not in scope of this document, and
> 324	   applicability statements for those uses MAY provide different advice,
> 325	   E.g.  [I-D.ietf-anima-autonomic-control-plane].
>
> If out of scope, don’t use Normative language there.
>
> ...
>
> 613             Figure 7: IP-in-IP encapsulation in Storing mode.
>
>
>
> [nit] The table above is called Figure… There are also some Tables.  Maybe
> be consistent about what is called a Table and what is called a Figure.
> Personally, I don’t care…I just would prefer consistency.
>
> ...
>
> 894   Note that there is a requirement that the final node be able to
>
> 895   remove one or more IP-in-IP headers which are all addressed to it,
>> 896   mentioned in [I-D.thubert-roll-unaware-leaves] :
>>
>> 898   "RPL data packets are often encapsulated using IP in IP.  The 6LN
>> 899   MUST be able to decapsulate a packet when it is the destination of
>> 900   the outer header and process correctly the inner header."
>>
>> [major] I realize that we're not reviewing
>> I-D.thubert-roll-unaware-leaves at this point, but how can a requirement be
>> placed on a not-RPL-aware-leaf if, by definition, it is not aware of RPL??
>>  ...and I don't think we can assume it is aware of any other requirement...
>>
> [authors] We understand that the requirements are placed on the 6LR that
> accepts the 6LN
>    registration and also inject the relevant routing information on its
> behalf.
>
> The text above talks abut the 6LN, not the 6LR.
>
> If this document depends on the requirement in
>> I-D.thubert-roll-unaware-leaves, then the reference should be Normative (it
>> is now listed as Informative).
>>
> [authors]fixed
>
> I still don’t feel too good about depending on requirements for
> not-RPL-aware nodes in the network…. In this case, this document will not
> be able to be published as an RFC until that *individual* draft is
> published.  Is that what you want?  Is there any way to work around this
> dependency?  Why isn’t rfc8200 support enough in this case?
>
>
> ...
>
> 1194 7.1.1.  Non-SM: Example of Flow from RPL-aware-leaf to root
>>
>> 1196   In non-storing mode the leaf node uses default routing to send
>> 1197   traffic to the root.  The RPI header must be included to
>> avoid/detect
>> 1198   loops.
>>
>> [major] Should that "must" be Normative?
>>
> [authors] fixed.
>
> 1322	   In non-storing mode the leaf node uses default routing to send
> 1323	   traffic to the root.  The RPI header MUST be included since contains
> 1324	   the rank information, which is used to avoid/detect loops.
>
> s/be included since contains/be included since it contains
>
>
> ...
>
> 1254 7.1.3.  Non-SM: Example of Flow from root to not-RPL-aware-leaf
>
> ...
>> 1267   In 6LBR the RH3 is added, it is modified at each intermediate 6LR
>> 1268   (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n),
>> 1269   but left there.  If RPI is left present, the IPv6 node which does
>> not
>> 1270   understand it will ignore it (following RFC8200), thus
>> encapsulation
>> 1271   is not necesary.  Due the complete knowledge of the topology at the
>> 1272   root, the 6LBR may optionally address the IP-in-IP header to the
>> last
>> 1273   6LR, such that it is removed prior to the IPv6 node.
>>
>> s/necesary/necessary
>>
>> [major] So...encapsulation is not needed, but an IP-in-IP header is
>> optional.  When?  Are there advantages, disadvantages?   Same questions
>> about the RPI.
>>
> [authors]rewritten.
>
> s/Due the complete/Due to the complete
>
>
> ...
>
> 1731 9.  6LoRH Compression cases
>
>
>> 1733   The [RFC8138] proposes a compression method for RPI, RH3 and
>> IPv6-in-
>> 1734   IPv6.
>>
>> 1736   In Storing Mode, for the examples of Flow from RPL-aware-leaf to
>> non-
>> 1737   RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf
>> comprise
>> 1738   an IP-in-IP and RPI compression headers.  The type of this case is
>> 1739   critical since IP-in-IP is encapsulating a RPI header.
>>
>> 1741
>>  +--+-----+---+--------------+-----------+-------------+-------------+
>> 1742   |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN
>> IPHC |
>> 1743
>>  +--+-----+---+--------------+-----------+-------------+-------------+
>>
>> 1745                    Figure 9: Critical IP-in-IP (RPI).
>>
>> [major] Shouldn't this section also be an Update to rfc8138?
>>
>> [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is
>> introduced as Critical here.  The header must then be completely specified
>> in this document and the appropriate registry must be updated (in the IANA
>> Consideration section).
>>
>> Specifically...referring to rfc8138...
>>    - the meaning of the TSE depends on the Type (§4.2),
>>    - the Hop Limit is defined in §7, should it have the same
>> behavior/meaning here?
>>    - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header
>> (§6.3)?
>>    - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC
>> (rfc6282).
>>
>
> [authors] we think that the confusion is because we wrote: “The type of
> this case”...
> which sounds like we are changing 8138, when what we mean is that use of
> this elective type is a MUST for RPL.
> Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of
> 6lowpan do not
> need to support (compressed) RPI headers, but this document makes it a
> MUST because
> RPL uses of 6lowpan need it. Is there text that we need to update?
>
> I see that you moved this text to §3.2.  The Figure (now 3) is still
> labeled as “critical”.
>
>
> ...
>> 1774 11.  Security Considerations
>
>
> Your responses to trisection indicated several times “Discussion on the
> list”, but I could’t find those discussions.  Did they happen already?
>
> I would prefer it if the document has mitigation suggestions (at least) in
> it; that usually makes the SecDir happier. ;-)  But that is not an absolute
> requirement before moving this document forward.
>
> ...
>
> [major] What does "SHOULD be suspicious" mean?  How is that a Normative
>> behavior?  Would being suspicious include dropping the packet or some other
>> similar action?  When would the router *not* be suspicious?  Why is that
>> not a "MUST"?
>
>
> [authors]The presence of the second RH3 means that there is a configuration
>  mistake somewhere else in the network.  It would be reasonable to
> increment
>   a counter in a MIB (if we had a MIB) when this occurs.  Based upon the
> Postel
>    doctrine, ignoring the extra header (not acting on it), is the best
> policy.
>     An RH3 header was not completely consumed is discussed in RFC
>
> https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header
> with
>  additional “non-zero Segments Left value, if the IPv6 Destination Address
> is
>   not on-link” should be dropped.  In this case, the RH3 header is *inside*
>   the outer IPv6-in-IPv6 header, which has then been forwarded.
> We think that this header should simply be ignored in processing the
> packet.
>  To do otherwise (such as forwarding) would permit external attackers to
> send
>  traffic that appears to originate inside the LLN.
>
>  To be discussed on list
>
> Ok…whatever the outcome is, to “be suspicious” is not something that can
> be enforced normatively.  SHOULD log and error, etc..is something
> actionable.
>