Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello again Alvaro


This is a quick pass on the nits (and snipped those I implemented as suggested):


> [major] A mention of Updating draft-ietf-roll-efficient-npdao is missing in the
> Abstract.  See also the comments in §5.

Removed the formal update and commented out the update text


> ...
> 98	1.  Introduction
> 
> [nit] It would be nice to offer a roadmap ("Section x talks about y,
> ...") in the Introduction...perhaps at the end of the section.
> 

added
"
   This document is organized as follows:

   *  Section 3 and Section 4 present salient aspects of RPL and 6LoWPAN
      ND, respectively, that are leveraged in this specification to
      provide connectivity to a RUL across a RPL network.

   *  Section 5 lists the expectations that a RUL needs to match in
      order to be served by a RPL router that complies with this
      specification.

   *  Section 6, Section 7, and Section 8 presents the additions to
      [RFC6550], [EFFICIENT-NPDAO], and [RFC8505].

   *  Section 9 and Section 10 present the operation of this
      specification for unicast and multicast flows, respectively, and
      Section 11 presents associated security considerations.

"


> [minor] "routing stretch (see [RFC6687])"  The term "routing stretch"
> is not in rfc6687...but there are other terms that might be what you meant.

Yes, they use path stretch; updating.
 

> [] "lazily"  Maybe I'm not getting the proper meaning, but it doesn't sound
> good...

We use the term "lazy" to mean an update that is not done immediately upon the event but opportunistically sometime later. This applies for instance to writing to disk in the db world.


> [minor] Do we really need rfc4862 as a reference for IPv6 ND?

Hard to present classic IPv6 ND without mentioning SLAAC, is it? 
I'd rather not make a change there


> ...or perhaps simply [USEofRPLinfo], since there will be an RFC number by the
> time we publish.

Even better yes


> 161	   This specification leverages the Address Registration mechanism
> 162	   defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN)
> to
> 163	   interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) and
> 164	   request that the 6LR injects a Host route for the Registered Address
> 165	   in the RPL routing on its behalf.  A RUL may be unable to participate
> 166	   because it is very energy-constrained, or because it is unsafe to let
> 167	   it inject routes in RPL, in which case using 6LowPAN ND as the
> 168	   interface for the RUL limits the surface of the possible attacks and
> 169	   optionally protects the address ownership.
> 
> [major] "unsafe to let it inject routes in RPL"   This is a good topic to talk about
> more in the Security Considerations section.

Yes, this is the point of the text below:

"

11.  Security Considerations

   First of all, it is worth noting that with [RFC6550], every node in
   the LLN is RPL-aware and can inject any RPL-based attack in the
   network.  This specification isolates edge nodes that can only
   interact with the RPL Routers using 6LoWPAN ND, meaning that they
   cannot perform RPL insider attacks.

   6LoWPAN ND can optionally provide SAVI features with [AP-ND], which
   reduces even more the attack perimeter that is available to the edge
   nodes.

"

> 
> [major] Even if 6LoWPAN ND is used, a rogue router can still inject instability,
> or too much control information in the LLN by adding/removing addresses
> constantly, for example.  Maybe a risk to be flagged in the Security
> Considerations.

We had
"
   This trust model could be at a minimum based on a Layer-2 Secure
   joining and the Link-Layer security.  This is a generic 6LoWPAN
   requirement, see Req5.1 in Appendix of [RFC8505]. 
"

I'm now adding
"
                                                                                                   It is needed in
   particular to prevent Denial-Of-Service attacks whereby a rogue 6LN
   creates a high churn in the RPL network by constantly registering and
   deregistering addresses with the "R" flag set in the EARO.   
"


> 
> ...
> 186	2.1.  BCP 14
> 
> [] s/BCP 14/Requirements Language

Yes I saw it coming and did that in the previous pass 

> 
> 
> 213	   This document uses the terms RPL-Unaware Leaf (RUL) and RPL
> Aware
> 214	   Leaf (RAL) consistently with [USEofRPLinfo].  The term RPL-Aware
> Node
> 215	   (RAN) is introduced to refer to a node that is either an RAL or a RPL
> 216	   Router.  As opposed to a RUL, a RAN manages the reachability of its
> 217	   addresses and prefixes by injecting them in RPL by itself.
> 
> [a comment for USEofRPLinfo] "consistently with [USEofRPLinfo]"  It would be
> nice if USEofRPLinfo referenced this document on the definition of a RUL,
> instead of defining it there too.  Yes, that would mean a Normative
> dependency.

This was the final intention after some back and forth fluctuation. 
And yes it is a normative reference for exactly that reason.

> 
> 354	3.2.2.  TID, I Field and Opaque Fields
> 
> 356	   When the "T" flag is set, the EARO includes a sequence counter
> called
> 357	   Transaction ID (TID), which maps to the Path Sequence Field found
> in
> 358	   the RPL Transit Option.  This is the reason why the support of
> 359	   [RFC8505] by the RUL as opposed to only [RFC6775] is a prerequisite
> 360	   for this specification (more in Section 7.1).  The EARO also
> 361	   transports an Opaque field and an associated "I" field that describes
> 362	   what the Opaque field transports and how to use it.  Section 10.2.1
> 363	   specifies the use of the "I" field and of the Opaque field by a RUL.
> 
> [nit] "This is the reason..."  What is the reason?  A counter?  It may not be
> clear to other readers what you're referring to.
> 


Reworded
"
   When the "T" flag is set, the EARO includes a sequence counter called
   Transaction ID (TID), that is needed to fill the Path Sequence Field
   in the RPL Transit Option.  This is the reason why the support of
   [RFC8505] by the RUL as opposed to only [RFC6775] is a prerequisite
   for this specification (more in Section 5.1).
"
 
> 
> 
> ...
> 411	3.3.1.  RFC 7400 Capability Indication Option
> ...
> 435	   A 6LR that can provide reachability services for a RUL in a RPL
> 436	   network as specified in this document SHOULD include a 6CIO in its
> RA
> 437	   messages and set the L, P and E flags as prescribed by [RFC8505],
> see
> 438	   Section 7.1 for the corresponding behavior of the RUL.
> 
> [major] "SHOULD include a 6CIO"  What are the cases where it is ok to not
> include the 6CIO?  IOW, why is this behavior not a requirement?

Could be configuration. But OK made it a MUST


> 
> 440	4.  Updating RFC 6550
> 
> [major] To me, Updating an RFC means that the implementations of that RFC
> should also implement this one.  In this case, there would be an expectation
> that all RPL nodes would support everything mentioned here.  Is that what is
> intended?  Should all the changes in this section be part of the Update?

Well, I have not seen that we converged to that understanding. 
There were reviews after yours that told me to do the opposite on the turnon RFC 8138 draft 
Did we reach an agreement at IESG level on this?
In the meantime, I'll trust you again though I'm prepared for more churn.

> Note that Updating is different than simply expecting the nodes that
> implement this specification to comply.

There's updated that replaces stuff and updated that adds stuff on top. 
Here we are updating the format of RPL messages in a backward compatible fashion.
For me that means updates. Anyway we find later that updates is needed.

> 
> [Personal opinion: it seems to me that some of the enhancements make sense
> on some nodes, but it is not necessary for all the nodes to support this
> specification for it to work.  For example, Figure 5 shows the flow with
> participation from the 6LR, Root, and 6LBR -- the other nodes in the LLN don't
> need to be aware of the changes.]

Very correct. If only enough 6LRs at the edge do it we're done.


> 
> 442	   This document specifies a new behavior whereby a 6LR injects DAO
> 443	   messages for unicast addresses (see Section 10) and multicast
> 444	   addresses (see Section 11) on behalf of leaves that are not aware of
> 445	   RPL.  The RUL addresses are exposed as external targets [RFC6550].
> 446	   Conforming [USEofRPLinfo], an IP-in-IP encapsulation between the
> 6LR
> 447	   and the RPL Root is used to carry the RPL artifacts and remove them
> 448	   when forwarding outside the RPL domain, e.g., to a RUL.
> 

> 
> [] Is there anything in rfc6550 that limits the source of the routing information
> in the DAOs?  It seems to me that rfc6550 already allows external information
> to be injected in the network...so getting it from a RUL doesn't sound like an
> Update to me.
> 

True, that is not why we have the updates. See sections "Updated RPL Status " and "Updated RPL Target Option"

> 
> 450	   This document also synchronizes the liveness monitoring at the Root
> 451	   and the 6LBR.  The same value of lifetime is used for both, and a
> 452	   single keep-alive message, the RPL DAO, traverses the RPL
> network.  A
> 453	   new behavior is introduced whereby the RPL Root proxies the EDAR
> 454	   message to the 6LBR on behalf of the 6LR (more in Section 6), for
> any
> 455	   6LN, RUL or RAN.
> 
> [] Yes, there's a proxy behavior...but I would see that more as a change to ND
> than an Update to rfc6550.

This is why we also update 8505, see section" Updating RFC 8505 ". I restored that updates too.

> 
> 457	   Section 6.7.7 of [RFC6550] introduces RPL Target Option, which can
> be
> 458	   used in RPL Control messages such as the DAO message to signal a
> 459	   destination prefix.  Section 9 adds the capabilities to transport the
> 460	   ROVR field (see Section 3.2.3) and the IPv6 Address of the prefix
> 461	   advertiser when the Target is a shorter prefix, signaled by a new "F"
> 462	   flag.  The position of the "F" flag is indicated in Section 15.
> 
> [] §9 says that this change is backward compatible; do we need all RPL nodes
> to support it?  See my comment there about requiring (vs
> recommending) the use...and about the potential forward compatibility need
> to Update...

Not so. The RUL is advertised in non-storing mode, meaning unicast from access 6LR straight to the Root
So this particular spec is backward compatible, as per your own intuition (your [personal opinion point above)


> 
> [] I put a note in §15 about Updading rfc6550 because of the changes in the
> registry (which is different than the functionality described here)...take a look.
> 

Sorry I'm not following. Please let me know if I need to restore the updates or not?

> [minor] "the IPv6 Address of the prefix advertiser when the Target is a shorter
> prefix"   I'm confused about this because then the F flag is set the Target is a
> full 128 bit address, not a shorter one.  What did I miss?
> 

Reworded to
"
   Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which
   can be used in RPL Control messages such as the DAO message to signal
   a destination prefix.  Section 6.2 adds the capabilities to transport
   the ROVR field (see Section 4.2.3) and the full IPv6 Address of the
   prefix advertiser when the Target is a shorter prefix, signaled by a
   new "F" flag.

"
Added "full". The point of "F" is similar to what we do in mobile IP. We place the 128bits address of the advertising node within the longer prefix that is advertised for routing purpose.


> 
> 464	   Section 6.7.6 of [RFC6550] defines the DODAG Configuration option
> 465	   with reserved flags.  This specification defines the new "Root
> 466	   Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved
> 467	   flags.  The "P" flag is set to indicate that the Root performs the
> 468	   proxy operation, which implies that it supports the Updated RPL
> 469	   Target Option (see Section 9).  The position of the "P" flag is
> 470	   indicated in Section 14.
> 
> [major] The P flag is not defined in §9...or anywhere else.

That was the definition of the "P" flag. I added a subsection based on the converged text in the turnon RFC 8138 draft. Note that I still need you and Benjamin Kaduk to agree on the updates or not there too - at the latest it is back on.

"
6.2.  Updated DODAG Configuration Option

   The DODAG Configuration Option is defined in Section 6.7.6 of
   [RFC6550].  Its purpose is extended to distribute configuration
   information affecting the construction and maintenance of the DODAG,
   as well as operational parameters for RPL on the DODAG, through the
   DODAG.  As shown in Figure 4, the Option was originally designed with
   4 bit positions reserved for future use as Flags.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 0x04 |Opt Length = 14| |P| | |A|       ...           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +

            Figure 4: DODAG Configuration Option (Partial View)

   This specification defines a new flag "Root Proxies EDAR/EDAC" (P).
   The "P" flag is set to indicate support for this specification at the
   Root within the DODAG.  The "P" flag is encoded in position 1 of the
   reserved Flags in the DODAG Configuration Option (counting from bit 0
   as the most significant bit) and set to 0 in legacy implementations
   as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550].

   The "P" flag is set to indicate that the Root performs the proxy
   operation, which implies that it supports the Updated RPL Target
   Option (see Section 6.1).

   The RPL DODAG Configuration Option is typically placed in a DODAG
   Information Object (DIO) message.  The DIO message propagates down
   the DODAG to form and then maintain its structure.  The DODAG
   Configuration Option is copied unmodified from parents to children.

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
   the DIO Base Object.  This specification applies to MOP values 0 to
   6.  For a MOP value of 7, the bit in position 1 is considered
   unallocated and [RFC8138] MUST be used by default.

   [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
   modify this information when propagating the DODAG Configuration
   option".  Therefore, a legacy parent propagates the "P" flag as set
   by the Root whether it supports this specification or not.  So when
   the "P" flag is set, it is transparently flooded to all the nodes in
   the DODAG.


"
> 
> [] Hard to say if this change is an Update without a specification of the P flag.
> 

Please consider sections

  7.  Updating draft-ietf-roll-efficient-npdao  . . . . . . . . . .  16
   8.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Protocol Operations for Unicast Addresses . . . . . . . . . .  16

For now based on discussion deeper in tis thread I restored the formal updates.

> 472	   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP)
> in
> 473	   the DIO Base Object.  The new "P" flag is defined only for MOP value
> 474	   between 0 to 6.  For a MOP value of 7 or above, the flag MAY be
> 475	   redefined and MUST NOT be interpreted as "Root Proxies
> EDAR/EDAC"
> 476	   unless the specification of the MOP indicates to do so.
> 
> [] We have an ongoing discussion about MOPs elsewhere.  For now, I think
> that the Update should happen elsewhere.

I used the final text in turnon RFC 8138 to create the new section above


> 
> ...but here's a suggestion anyway...
> 
> [] NEW>
>    Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the
>    DIO Base Object.  This specification of the new "P" flag applies to MOP
>    values 0 to 6.

I'll rather use the new section that went through IESG reviews

> 
> 478	   The RPL Status defined in section 6.5.1 of [RFC6550] for use in the
> 479	   DAO-ACK message is extended to be placed in DCO messages
> 480	   [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
> 481	   to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and
> DCO
> 482	   messages, embedded in a RPL Status, more in Section 8.
> 
> [major] Besides enabling the EARO status to be carried, §8 also reduces the
> size of the status from 8 to 6 bits, with the new encoding...  This *is* a
> necessary Update to rfc6550.
> 

Restored! 


> [] Note that even though the same RPL Status is used in the DCO message, a
> formal Update is not required for EFFICIENT-NPDAO for the reduction of the
> size since that document is already inheriting the Update from rfc6500: "RPL
> Status: As defined in [RFC6550] and updated in [I-D.ietf-roll-unaware-leaves]."
> 
> 
> 484	5.  Updating draft-ietf-roll-efficient-npdao
> 
> [major] To me, Updating an RFC means that the implementations of that RFC
> should also implement this one.  In this case, there would be an expectation
> that all nodes that support the DCO would support the Non-Storing MOP as
> well.  Is that what is intended?

Actually that would be better for e.g., the backbone router, but is not necessary for this spec.
With this reading I'd rather do the updates but I keep it out for now.

> Note that Updating is different than simply expecting the nodes that
> implement this specification to comply.
> 
> [Personal opinion: I don't think a formal Update of draft-ietf-roll-efficient-
> npdao is needed.  As mentioned below, this document "extends"...]

OK then!

Voila!

This second set of diffs is available here

https://github.com/roll-wg/roll-unaware-leaves/commit/de2ce1ae31b78b664a94dfc08bb0f52dac882d62

That's a bunch! I published -20 so we can have a new reference to discuss about with the aggregation of the 2 diff sets.


Html:           https://www.ietf.org/id/draft-ietf-roll-unaware-leaves-19.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-19
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-19


Please let me know : )
Many thanks Alvaro!

Take care,

Pascal