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

From: Ines Robles <[email-masked]>
Date: Fri, 15 Mar 2019 22:48:22 +0200

Hi Alvaro,

 Thanks again for your review. We believe that the new version address all
your comments. Please see in-line.

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

> On January 23, 2019 at 5:06:24 PM, Ines Robles (
> [email-masked]) 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.
>

We did that, changed to non-normative language.

>
> 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.
>
Operational considerations is completed now.

>
> ...
>
> [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.
>
fixed

>
> ...
>
> 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.
>
Thanks, fixed

>
> ...
>
> ...
>
> 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.
>

Thanks, fixed

>
> ...
>
> 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.
>

We used artwork, to display a  nice table , based on the xml2rfc FAQ "Note:
for tables that are more complex, inserting the table as a figure (i.e.,
inside of <figure> <artwork> tags) might be the best option." [
https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html]. We additionally, added
some clarification in the text.

>
> ...
>
> 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?
>
Thanks, fixed. The new paragraph does not depend of this document, it
states:

The final node should be able to remove one or more IPv6-in-IPv6
   headers which are all addressed to it.  Furhter details about this
   are mentioned in [I-D.thubert-roll-unaware-leaves
<https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25#ref-I-D.thubert-roll-unaware-leaves>],
which specifies
   RPL routing for a 6LN acting as a plain host and not aware of RPL.

> ...
>
> 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
>
Fixed.

> ...
>
> 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
>
Fixed

>
> ...
>
> 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”.
>
figure fixed.

>
> ...
>> 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.
>

We added new paragraph based on the comment of the ML.

   If an attack comes from inside of LLN, it can be alleviated with SAVI
   (Source Address Validation Improvement) using [RFC8505
<https://tools.ietf.org/html/rfc8505>] with
   [I-D.ietf-6lo-ap-nd
<https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25#ref-I-D.ietf-6lo-ap-nd>].
The attacker will not be able to source with
   an address that is not registered, and the registration checks for
   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.

> ...
>
> [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.
>
fixed.

Thank you very much Alvaro again,

Ines.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 Mar 2019 10:12:14 -0400

On March 15, 2019 at 4:48:35 PM, Ines Robles ([email-masked])
wrote:

Hi!

your comments.

It does!  I have requested the start of the IETF LC.

Thanks!

Alvaro.

---

From: Ines Robles <[email-masked]>
Date: Thu, 21 Mar 2019 16:18:21 +0200

Thank you very much Alvaro!!

We are happy to know that the document addresses all the comments. :)

On Thu, Mar 21, 2019 at 4:12 PM Alvaro Retana <[email-masked]>
wrote:

> On March 15, 2019 at 4:48:35 PM, Ines Robles (