Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,


On Thu, Dec 17, 2020 at 07:00:40PM +0000, Pascal Thubert (pthubert) wrote:
> Hello again Benjamin. 
> 
> I have (plenty of) coffee, it's early afternoon, I had (almost) no red wine at lunch... I'm ready for your review comments : ) : )

I am ... not so well prepared.  Hopefully it goes okay; yours seems to have
been successful :)

> As usual I committed my run in github , https://github.com/roll-wg/roll-unaware-leaves/commit/b5846736dc41da21ab89261949b31edecbea64d4
> 
> I published 27 so that the next reviewers may benefit from the changes. 
> The diffs are:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-27
> 
> Let's go for the details !
> 
> First and as usual, a great many thanks for the depth and thoroughness of your review; please see below:
> 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Thanks to Carl Wallace for the secdir review, and to the authors for having
> > addressed the review comments.
> > 
> > There's a lot of updates in this document of various sorts, and it's a bit
> > challenging to reason about all of them, especially with respect to feature
> > negotiation/incremental deployment.  This will be a recurring theme in my
> > detailed comments.  My current understanding so far is:
> > 
> > - there is not currently any support for RULs, so we don't really need
> >   to worry about existing RULs that do not comply with this spec (though
> >   this spec does add a couple new requirements not present with the
> >   stock versions of 6LoWPAN ND, etc.)
> 
> Correct
> 
> > - If the RPL Root doesn't support this, it can't be used
> 
> There's a subtlety that the root can support the external route but not the proxy DAR operation. 
> The support of external route only is governed by useofrplinfo. 
> Otherwise, if a legacy Root is not deterred by the larger RPL Target Option, it should be fine.
> 
> But better safe then sorry I added in the intro:
> "
> 
>    This specification can be deployed incrementally in a network that
>    implements [USEofRPLinfo].  Only the Root and the 6LRs that connect
>    the RULs need to be upgraded.  The RPL routers on path will only see
>    unicast IPv6 traffic between the Root and the 6LR.
> "
> 
> > - the RPL Root advertises its support via the 'P' flag in the DODAG
> 
> Again that's the Proxy thingy

I guess the §6.2 text about "set to 1 to indicate that the Root performs
the proxy operation, which implies that it supports this specification and
the updated RPL Target Option" made me think it was supposed to be a
broader indication than just strictly support for the proxying.

> >   Configuration Option that is sent to all 6LRs
> 
> Yes, flooded unchanged in the DIO
> 
> > - Many message flows require the support of a 6LR to initiate them
> 
> Yes
> 
> > - but there seem to be some cases where there are asynchronous messages
> >   originating from the root (or 6LBR) ... can they end up at a 6LR that
> >   does not support the new structures?
> 
> The new message is the Non-storing DCO.  The EDAR is controlled by RFC 8505 that the 6LR supports.
> The average RPL Joe's behavior is governed by RFC 6550 section 6:
> 
> "
>    If a node receives a RPL control message with an unknown Code field,
>    the node MUST discard the message without any further processing, MAY
>    raise a management alert, and MUST NOT send any messages in response.
> "
> 
> But that would be accidental. The DCO is triggered by a non-storing DAO with the 'E' flag. 
> This becomes possible with useofrplinfo along, but I have no knowledge that anyone tried it at home.

And we think it's unlikely that someone ten years from now would feel like
doing useofrplinfo but not do this one.  I'm failing to come up with
anything useful to say to give a reader of this document a warning about
that (presumably the previous bit about "only the root and 6LRs that
connect to RULs" will suffice).

> > - The RPL Root can now proxy EDAR/EDAC ... but can a 6LR "miss the memo"
> >   for that and also attempt EDAR?  (IIUC, "no", since such a 6LR
> >   wouldn't know about RULs in the first place.)
> 
> That's useless but BAU for the 6LBR which will answer both. 
> This situation exists in RFC 8505 if a 6LN registers to several 6LRs; all of them do the EDAR/EDAC exchange.

It does sound like business as usual for the 6LBR, and if you care about
the overhead of the extra traffic you will presumably notice it happening.

> 
> > - Some of the new mechanisms (e.g., suppression of periodic EDAR in
> >   favor of DAO and proxying by the RPL Root) are not limited to use by
> >   RULs (?) and thus could be triggered on behalf of nodes not expecting
> >   such services (?)
> 
> You're right, this is useful in any non-storing mode situation, including RAN, and not just for external host routes.
> I'm happy to extend to that but then we need control. Let me add a flag to control this in the Target Option.

I'm also happy to see this extended and have the control flag.  I do wonder
a bit if this is a somewhat big change to make at IESG Evaluation time, and
hope that we can get eyes on it from others in the WG.

> This impacts the 1) Target option format, 2) the IANA section, and the 3) description of the behavior of the 6LR and Root, and in subsections of 9.2.
> 
> Proposed updates:
> 
> For  1) in Section 6.1
> "
>    X:  1-bit flag.  Set to 1 to request that the Root performs a proxy
>       EDAR/EDAC exchange.  The 'X' flag can only be set to 1 if the
>       DODAG is operating in Non-Storing Mode and if the Root sets the
>       "Root Proxies EDAR/EDAC (P)" flag to 1 in the DODAG Configuration
>       Option, see Section 6.2.  The 'X' flag can be set for host routes
>       to RULs and RANs; it can also be set for internal prefix routes if
>       the 'F' flag is set, using the node's address in the Target Prefix
>       field to form the EDAR, but it cannot be used otherwise.
> 
> "
>
> For  2) in Section 12.4
> "
> 
>    Section 6.1 also defines 2 new entries in the Registry as follows:
> 
>       +---------------+--------------------------------+-----------+
>       | Bit Number    | Capability Description         | Reference |
>       +---------------+--------------------------------+-----------+
>       | 0 (suggested) | Advertiser address in Full (F) | THIS RFC  |
>       +---------------+--------------------------------+-----------+
>       | 1 (suggested) | Proxy EDAR Requested (X)       | THIS RFC  |
>       +---------------+--------------------------------+-----------+
> 
>                    Table 3: RPL Target Option Registry
> "
> 
> In Fig 7 the X flag is set to 0 on the first exchange, that's actually cleaner:
> 
> "
> 
> 
>    6LN/RUL            6LR   <6LR*>   Root               6LBR
>       |<---Using ND--->|<--Using RPL->|<-----Using ND---->|
>       |                |<-----------Using ND------------->|
>       |                |              |                   |
>       |   NS(EARO)     |              |                   |
>       |--------------->|                                  |
>       |                |            EDAR                  |
>       |                |--------------------------------->|
>       |                |                                  |
>       |                |             EDAC                 |
>       |                |<---------------------------------|
>       |                |                                  |
>       |                |   DAO(X=0)   |                   |
>       |                |------------->|                   |
>       |                |                                  |
>       |                |    DAO-ACK   |                   |
>       |                |<-------------|                   |
>       |   NA(EARO)     |              |                   |
>       |<---------------|              |                   |
>       |                |              |                   |
> 
>                    Figure 7: First RUL Registration Flow
> 
> "
> 
> In 9.2.2
> "
> 
>    If the R Flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the
>    host route in RPL, unless this is barred for other reasons, such as
>    the saturation of the RPL parents.  The 6LR MUST use a RPL Non-
>    Storing Mode signaling and the updated Target Option (see
>    Section 6.1).  The 6LR SHOULD refrain from setting the 'X' flag to
>    avoid a redundant EDAR/EDAC flow to the 6LBR.  The 6LR MUST request a
>    DAO-ACK by setting the 'K' flag in the DAO message.  Success
>    injecting the route to the RUL's address is indicated by the 'E' flag
>    set to 0 in the RPL status of the DAO-ACK message.
> 
>    For the registration refreshes, if the RPL Root sets the 'P' flag in
>    the DODAG Configuration Option to 1, then the 6LR MUST refrain from
>    sending the keep-alive EDAR; instead, it MUST set the 'X' flag to 1
>    in the Target Option of the DAO messages, to request that the Root
>    proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
>    Section 6); if the 'P' flag is set to 0 then the 6LR MUST set the 'X'
>    flag to 0 and handle the EDAR/EDAC flow itself.
> "

I don't mind this, but IIUC the "MUST" may not be indicating a technical
requirement, just an efficiency one?  (The mirroring of doing the one if
and only if you do the other does seem to be something that should be
MUST-level required.)

> In 9.2.3
> 
> 
> > It would be great to have some exposition on how this stuff is expected to be
> > rolled out and how it's safe for incremental deployment, especially if (as the
> > shepherd report indicates) we don't have any implementation experience to
> > build confidence.
> 
> I guess the 'X' flag helps since it answers a number of your questions.
> Note that we have a lot of experience in non-storing mode; the main difference is that the tunnel does not end at the destination but at the router serving it.

Yes, I think the 'X' flag helps to clarify the deployment scenario.

> The real challenge will be to find a good ROV mechanism based on the ROVR.
> 
> > 
> > There might be a small internal inconsistency in §9.2.2 in terms of what needs to
> > be waited for before the NA(EARO) is emitted (see the detailed comments for
> > why).
> > 
> 
> Deferring the response
> 
> > 
> > I still feel that if we're going to incrementally add new properties to MOP 7, we
> > should list the relevant documents as references in the registry until MOP 7 is 
> > fully specified.  In this case we can arguably get away with not doing so since this
> > document Updates: RFC 6550 already and thus could be said to be doing the
> > reservation by modification of the core protocol, but we are not using that
> > procedure universally (e.g., for turnon-rfc8138) and it seems prudent to use a
> > consistent mechanism.
> 
> Yes, we have a github page for that, see https://github.com/roll-wg/RPLv2; I added your concern above in there.
> 
> It is duplicated there https://github.com/roll-wg/RFC6550bis/ in case we decide to write that is RFC 6550 bis
> 
> I guess we're good.

[this continued in a subthread]

> 
> > 
> > Section 1
> > 
> >    A RUL may be unable to participate because it is very energy-
> >    constrained, code-space constrained, or because it would be unsafe to
> >    let it inject routes in RPL.  Using 6LoWPAN ND as opposed to RPL as
> >    the host-to-router interface limits the surface of the possible
> >    attacks by the RUL against the RPL domain, and can protect RUL for
> >    its address ownership.
> > 
> > (nit?) I am not entirely sure what sense "and can protect" is used in.
> > IIUC, a given leaf could either be a RAL or a RUL; an RAL participates in RPL and
> > as such is assumed to be trusted to properly advertise routes, including
> > protecting routes to its own address.  In contrast, an RUL requires assistance of
> > the RPL router to be able to protect its address, something that 6LoWPAN ND
> > enables by virtue of the ROVR.  So I feel like the contrast is more of a "but can
> > still protect the RUL's address ownership" -- the "and can" construction suggests
> > that this is an additional benefit of using 6LoWPAN ND that is not achieved when
> > the leaf is RPL-aware.  (Or am I conflating RPL and 6LoWPAN ND too much?)
> 
> Yes, this part is not "as opposed to RPL" since it is done with ND in all cases. 
> Better split in 2 sentences? 
> 
> "
>    A RUL may be unable to participate because it is very energy-
>    constrained, code-space constrained, or because it would be unsafe to
>    let it inject routes in RPL.  Using 6LoWPAN ND as opposed to RPL as
>    the host-to-router interface limits the surface of the possible
>    attacks by the RUL against the RPL domain.  If all RULs and RANs use
>    6LoWPAN ND for Neighbor Discovery, it is also possible to protect the
>    address ownership of all nodes, including the RULs.
> "

That does read more easily, yes.  I did not try to think through how it
plays out if RANs use 6LoWPAN ND vs directly participating in RPL, in terms
of whether protecting address ownership of all nodes is possible in both
cases, but I trust you to have done so.

> > 
> > Section 3
> > 
> >    details).  If the packet from the RUL has an RPI, the 6LR as a RPL
> >    border router SHOULD rewrite the RPI to indicate the selected
> >    Instance and set the flags, but it does not need to encapsulate the
> >    packet.
> > 
> > (1) why is there any normative language in a non-normative section?
> 
> Removed the normative there, added a link to 9.2.2
> 
> > (2) doesn't it need to be a MUST, if it's not encapsulating?
> 
> Added text in 9.2.2 instead.
> 
> "   When forwarding a packet from the RUL into the RPL domain, if the
>    packet does not have an RPI then the 6LR MUST encapsulate the packet
>    to the Root, and add an RPI.  If there is an RPI in the packet, the
>    6LR MUST rewrite the RPI but does not need to encapsulate.
> 
> "
> 
> 
> > 
> >    A RUL is not expected to support the compression method defined in
> >    [RFC8138].  For that reason, the border router uncompresses the
> >    packet before forwarding it over an external route to a RUL
> >    [USEofRPLinfo].
> > 
> > Just to confirm: the "border router" here is not the 6LBR but rather a "normal"
> > 6LR (i.e., an "RPL border router")?
> 
> Yes; I changed to " the border router (the 6LR here)". Since we now have external routes, we now have a southern border as well. 
> 
> > 
> > Section 4.2
> > 
> >    "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
> >    updates the behavior of RFC 6775 to enable a generic Address
> >    Registration to services such as routing and ND proxy, and defines
> >    the Extended Address Registration Option (EARO) as shown in Figure 2:
> > 
> > nit: the grammar seems off here; it would scan better if it was "to provide
> > services", but I'm not 100% sure that's correct.
> 
> It is a registration to services (or maybe for services?) but not the services themselves
> What about
> "
>    "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
>    updates RFC 6775 into a generic Address Registration mechanism that
>    can be used to access services such as routing and ND proxy.  To that
>    effect, [RFC8505] defines the Extended Address Registration Option
>    (EARO), shown in Figure 2:
> 
> "

Looks good; thanks!

> > 
> > Section 4.3
> > 
> >    The exchange is protected by the retry mechanism (ARQ) specified in
> >    Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than
> >    the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1
> >    second may be necessary to cover the round trip delay between the 6LR
> >    and the 6LBR.
> > 
> > This is the only place in the document that we use the term ARQ (other than the
> > glossary), and RFC 6775 itself does not use the term either.
> > So I'm not sure that it's adding much value (just risk of confusion if someone
> > expects it to be present in RFC 6775 the way I did).
> 
> Removed
> 
> > 
> > Section 5.1
> > 
> >    To obtain routing services from a router that implements this
> >    specification, a RUL needs to implement [RFC8505] and sets the "R"
> >    and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and
> >    Section 4.2.3, respectively.  Section 9.2.1 specifies new behaviors
> > 
> > nit: s/4.2.3/4.2.2/
> 
> Done
> 
> > 
> > Section 6.1
> > 
> >    The updated format is illustrated in Figure 4.  It is backward
> >    compatible with the Target Option in [RFC6550].  It is recommended
> > 
> > I agree that it is backwards compatible in the sense that it degenerates into the
> > previous structure when the ROVR size is zero.  But do we have confidence that
> > existing implementations will do something useful if we use bits that they treat
> > as flags, to indicate that the overall size of the option is increased in a way not
> > previously envisioned?
> 
> The flags field was reserved in section 6.7.7 of RPL so that much is ok I guess.
> There is nothing in that section that prevents the length from exceeding 20 bytes.
> If an implementation has a sanity check, it is non-standard will need to be disabled.
> Note that this does not hurt this RFC since the packet is unicast from the 6LR to the Root.
> And I added that sentence that says that they need to be upgraded.

I probably missed that it was unicast, so thanks for pointing that out.
That reduces the magnitude of my worrying, at least.

> > 
> > Section 6.2
> > 
> >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
> >    definition of the Flags applies to Mode of Operation (MOP) values
> >    zero (0) to six (6) only.  For a MOP value of 7, the implementation
> >    MUST consider that the Root performs the proxy operation.
> > 
> > How is this to be noted for future implementors of MOP value 7?  Are we relying
> > on the "Updates:" relationship with 6550 to note this?
> 
> As discussed in your summary, I rely on the RPL-WG github https://github.com/roll-wg/RPLv2/blob/main/README.md
> 
> 
> 
> > 
> > Section 6.3
> > 
> >    Status Value:  6-bit unsigned integer.  If the 'A' flag is set to 1
> >       this field transports a Status value defined for IPv6 ND EARO.
> >       When the 'A' flag is set to 0, the Status value is defined for
> >       RPL.
> > 
> > nit(?): I suggest "the Status value is as defined for RPL" (add "as", or perhaps
> > "one" in the same place).
> 
> Done
> 
> 
> > 
> >    Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with
> >    a RPL Status that has the 'A' flag set, the 6LR MUST copy the RPL
> >    Status value unchanged in the Status field of the EARO when
> >    generating an NA to the RUL.
> > 
> > By my reading "copy the RPL Status value unchanged" includes the values of the
> > E and A flags (and this is predicated on 'A' being set), which doesn't seem like it
> > would have the desired effect...I expect that only the StatusValue field is
> > supposed to be copied (with the high bits set to zero)?
> 
> Well, you're correct and I thought the text you copied above did not leave room for mistake.
> " Status Value:  6-bit unsigned integer". 
> 
> "
>    Status Value:  6-bit unsigned integer.
> 
>       If the 'A' flag is set to 1 this field transports a value defined
>       for the 6LoWPAN ND EARO Status.
> 
>       When the 'A' flag is set to 0, this field transports a Status
>       Value defined for RPL.
> "

Hmm, that is true.  ("Status Value" with majuscule 'V' might help get
there.)  I assume that I was seeing "RPL Status" and thinking "the thing in
the core RFC", where it was 8 bits.  I am not sure that we should put much
more time into this point, though.

> 
> 
> > Section 7
> > 
> >    In the case of a RUL, the 6LR that serves the RUL acts as the RAN
> >    that receives the Non-Storing DCO.  This specification leverages the
> >    Non-Storing DCO between the Root and the 6LR that serves as
> >    attachment router for a RUL.  A 6LR and a Root that support this
> >    specification MUST implement the Non-Storing DCO.
> > 
> > Should we mention with in the discussion of the 'P' flag in §6.2?
> 
> The 'P' flag is not the enabler for this support. 
> 
> > I'm not entirely sure how the negotiation/enablement procedure works for a
> > RAL, either.
>  
> Well, there's none; a RAN that does not understand the async Non-Storing DCO will ignore it (see my RPL quote above).
> It may think that it has reachability for a while. Its next registration will resynchronize, hopefully for the good.
> 
> 
> > Section 8
> > 
> >    *  If the RPL Root advertises the capability to proxy the EDAR/EDAC
> >       exchange to the 6LBR, the 6LR refrains from sending the keep-alive
> >       EDAR message.  If it is separated from the 6LBR, the Root
> >       regenerates the EDAR message to the 6LBR periodically, upon a DAO
> >       message that signals the liveliness of the address.
> > 
> > I feel like we should mention the situation where the RPL Root advertises the 'P'
> > flag but the 6LR does not support this specification.
> > Do we end up with both the 6LR and the RPL Root sending the EDAR message, or
> > is the RPL Root expected to notice that the 6LR is sending one and refrain from
> > generating an additional one?  (I guess we expect it to be uncommon that 6LBR
> > and RPL Root are different, anyway?)  Or is this just not supposed to happen
> > because the mechanism only exists to support RULs and an un-updated 6LR will
> > not attempt to support RULs?
> > 
> > Section 9.1
> > 
> >           6LN/RUL            6LR   <6LR*>   Root               6LBR
> >              |                |              |                   |
> >              |<------ND------>|<----RPL----->|<-------ND-------->|
> >              |                |<----------------ND-------------->|
> > 
> > Are these arrows still part of the "legend" (of sorts) as opposed to being
> > indications of the initial flow(s)?
> 
> Yes, is this better?
> "
> 
>    6LN/RUL            6LR   <6LR*>   Root               6LBR
>       |<---Using ND--->|<--Using RPL->|<-----Using ND---->|
>       |                |<-----------Using ND------------->|
> "

Yes, thanks.

> 
> 
> >    To achieve this, the Path Sequence and the Path Lifetime in the DAO
> >    message are taken from the Transaction ID and the Address
> >    Registration lifetime in the NS(EARO) message from the 6LN.
> > 
> > Reusing an identifier taken from one context in one protocol to play a role in a
> > different context in a different protocol has historically led to security-relevant
> > flaws/attacks.  What kind of analysis has been done to consider the risk of such
> > issues here?
> 
> None. I have no idea what opening this creates. 
> All I can say is that as opposed maybe to your examples, the TID was designed to be mapped onto RPL from the beginning and to mean the same thing.
> If you look at the text in RFC 8505 for the TID: It is the verbatim copy of the text for the Path Sequence in RPL. It's easier to drive when you know where's you're going 😊. For the lifetime, we had to go through a translation.

"TID was designed to be mapped onto RPL from the beginning" helps a lot;
thanks.

> > 
> >    [RFC8929] expects that the 6LBR is collocated with the RPL Root, but
> >    if not, the 6LBR MUST forward the status code to the originator of
> >    the EDAR, either the 6LR or the RPL Root that proxies for it.  The ND
> >    status code is mapped in a RPL Status value by the RPL Root, and then
> >    back by the 6LR.
> > 
> > Continuing the theme, can we get into a scenario where the 6LR in this flow does
> > not implement this specification but receives a DCO carrying an EARO status
> > code?
> 
> I can add a note. What about:
> "
>    Note that a legacy RAN that receives a Non-Storing
>    DCO that it does not support will ignore it silently, as specified in
>    section 6 of [RFC6550].  The result is that it may ignore for a while
>    that it is no more reachable.  The situation will be cleared upon the
>    next Non-Storing DAO exchange if the error is returned in a DAO-ACK.
> 
> "

Looks good.
(s/no more reachange/no longer reachable/, but that's just a nit)

> 
> > 
> >    Figure 9 illustrates this in the case where the 6LBR and the Root are
> >    not collocated, and the Root proxies the EDAR messages.
> > 
> > (The figure shows an EDAC message being proxied, not an EDAR message,
> > though for the general case using EDAR as the description seems to make
> > sense.)
> 
> Changed to "the Root proxies the EDAR/EDAC flow"
> 
> > 
> > Section 9.2.1
> > 
> >    This specification does not alter the operation of a 6LoWPAN ND-
> >    compliant 6LN/RUL, which is expected to operate as follows:
> >    [...]
> >    5.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
> >        the R Flag in the EARO of its registration(s) for which it
> >        requires routing services.  If the R Flag is not echoed in the
> >        NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
> >        ensure that one registration succeeds before setting the R Flag
> >        to 0.  [...]
> > 
> > AFAICT the SHOULDs here represent a divergence from the previously specified
> > 6LN/RUL 6LoWPAN ND behavior (not least because this document seems to be
> > the first definition of using the R flag in the NA as opposed to NS), in
> > contravention to the initial statement.
>  
> Changed " does not alter " to  "builds on". Note that the RUL could have been implemented that way.
> 
> 
> > Section 9.2.2
> > 
> >    As described in [RFC8505], if the "I" field is zero, then the Opaque
> >    field is expected to carry the RPLInstanceID suggested by the 6LN;
> >    otherwise, there is no suggested Instance.  If the 6LR participates
> >    in the suggested RPL Instance, then the 6LR MUST use that RPL
> >    Instance for the Registered Address.
> > 
> > This MUST-level requirement seems to preclude any kind of policy filter on the
> > 6LR to apply authorization checks to attempts to use a given RPL Instance.  Is
> > that intended?
> 
> There is no alternate design for the else statement that must come with a SHOULD.
> 
> We have this in the security section:
> "
>     The Opaque field in the EARO enables the RUL to suggest a RPLInstanceID
>     where its traffic is placed. It is also possible for an attacker RUL to
>     include an RPI in the packet. This opens to attacks where a RPL instance
>     would be reserved for critical traffic, e.g., with a specific bandwidth
>     reservation, that the additional traffic generated by a rogue may disrupt.
>     The attack may be alleviated by traditional access control and traffic
>     shaping mechanisms where the 6LR controls the incoming traffic from the
>     6LN. More importantly, the 6LR is the node that injects the traffic in the
>     RPL domain, so it has the final word on which RPLInstance is to be used
>     for the traffic coming from the RUL, per its own policy.
> "
> Is that enough?

Yes, that will work.  It implies ("access control") that attempting to use
an RPL Instance that's supposed to be for critical traffic will result in
an unauthorized node's traffic getting dropped (rather than remapped to a
different instance), but I will not get too bent out of shape if someone
ends up doing such remapping.

> > 
> >    NA(EARO) to the RUL.  Upon receiving an asynchronous DCO message, if
> >    a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send
> >    the NA(EARO) and deliver the status found in the DCO, else it MUST
> >    send an asynchronous NA(EARO) to the RUL immediately.
> > 
> > I think I missed the explanation for why it has to wait for the DAO-ACK before
> > sending the NA(EARO), if the DCO is going to take precedence.
> > In particular, it seems to be in conflict with the description of the general flow in
> > §9.1, which says that "[u]pon the DAO-ACK - or the DCO if one arrives first - the
> > 6LR responds to the RUL with an NA(EARO)."
> 
> Oups! Great catch. I was afraid of race conditions since the path sequence is not reflected in the DCO. But I do not have a flow to justify this.
> I removed the wait:
> "
>   
>    Upon receiving or timing out the DAO-ACK after an implementation-specific 
>    number of retries, the 6LR MUST send the corresponding NA(EARO) to the RUL. 
>    Upon receiving an asynchronous DCO message, it MUST send an asynchronous 
>    NA(EARO) to the RUL immediately, but still be capable of processing the
>    DAO-ACK if one is pending.
> 
> "
> 
> > 
> >    The 6LR MUST set the R Flag to 1 in the NA(EARO) back if and only if
> >    the 'E' flag is set to 0, indicating that the 6LR injected the
> >    Registered Address in the RPL routing successfully and that the EDAR
> >    proxy operation succeeded.
> > 
> > Please use a bit more detail on where the 'E' flag is (I assume it's the one taken
> > from a bit that was formerly part of the 'Status' field in the RPL message, but in
> > the next paragraph we clearly say it's the flag "in the RPL Status" to avoid any
> > doubt).
> 
> Done 
> 
> > 
> >    An error injecting the route causes the 'E' flag to be set to 1.  If
> >    the error is not related to ND, the 'A' flag is set to 0.  In that
> >    case, the registration succeeds, but the RPL route is not installed.
> >    So the NA(EARO) is returned with a status indicating success but the
> >    R Flag set to 0, which means that the 6LN obtained a binding but no
> >    route.
> > 
> > Continuing the theme, can we get into a situation where the RUL does not check
> > the R flag and assumes that there is a route installed?
> 
> That was missing from RFC 8505. We should have indicated it. Currently we have:
> "
>    5.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
>        the R Flag in the EARO of its registration(s) for which it
>        requires routing services.  If the R Flag is not echoed in the
>        NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
>        ensure that one registration succeeds before setting the R Flag
>        to 0.  In case of a conflict with the preceding rule on lifetime,
>        the rule on lifetime has precedence.
> 
> "
> And 
> "
> when the R Flag set to 1 in a NS(EARO) is not echoed in the NA(EARO), 
> which indicates that the route injection failed.
> "
> 
> Actually the former does not really implement the latter though it should.
> Changing to 
> "
> 
>    5.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
>        the R Flag in the EARO of its registration(s) for which it
>        requires routing services.  If the R Flag is not echoed in the
>        NA, the RUL MUST consider that establishing the routing services
>        via this 6LR failed and it SHOULD attempt to use another 6LR.
>        The RUL SHOULD ensure that one registration succeeds before
>        setting the R Flag to 0.  In case of a conflict with the
>        preceding rule on lifetime, the rule on lifetime has precedence.
> 
> "

Okay.  So basically the story here is just "this is part of the Updates:
8505 and what 8505 says doesn't quite work", so there's not much else we
can do.  (And §8 already says as much.)

> > 
> >    If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then
> >    the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success)
> >    MUST be returned to the 6LN.  The EARO Status of 0 MUST also be used
> >    if the 6LR did not attempt to inject the route but could create the
> >    binding after a successful EDAR/EDAC exchange or refresh it.
> > 
> >    If the 'E' flag is set to 1 in the RPL Status of the DAO-ACK, then
> >    the route was not installed and the R flag MUST be set to 0 in the
> >    NA(EARO).  The R flag MUST be set to 0 if the 6LR did not attempt to
> >    inject the route.
> > 
> > These two paragraphs seem to have some amount of redundancy with the
> > preceding few paragraphs, though I'm not entirely sure how much.
> 
> I was careful when writing them. Some deal with the NCE, others with the routes.
> 
> > 
> >    In a network where Address Protected Neighbor Discovery (AP-ND) is
> >    enabled, in case of a DAO-ACK or a DCO indicating transporting an
> > 
> > nit: It seems that we should just pick one of "indicating transporting".
> Picked "transporting"
> 
> >    EARO Status value of 5 (Validation Requested), the 6LR MUST challenge
> >    the 6LN for ownership of the address, as described in section 6.1 of
> >    [RFC8928], before the Registration is complete.  This flow,
> >    illustrated in Figure 10, ensures that the address is validated
> >    before it is injected in the RPL routing.
> > 
> > To me Figure 10 is showing the flow where the 6LR itself initiates the "Validation
> > Requested" state; I don't see a triggering DAO-ACK or DCO.
> 
> It is a step that runs upon a proof of ownership, as you do remember from RFC 8928.
> 
> I changed the drawing to
> 
> 
> 6LN                                       6LR        Root        6LBR
>  |                                         |           |           |
>  |<--------------- RA ---------------------|           |           |
>  |                                         |           |           |
>  |------ NS EARO (ROVR=Crypto-ID) -------->|           |           |
>  |                                         |           |           |
>  |<- NA EARO(status=Validation Requested) -|           |           |
>  |                                         |           |           |
>  |----- NS EARO and Proof-of-ownership  -->|                       |
>  |                                         |           |           |
>  |                                <validate the Proof> |           |
>  |                                                     |           |
>  |<----------- NA EARO (status=10)---<if failed>       |           |
>  |                                                     |           |
>  |                                       <else>        |           |
>  |                                         |           |           |
>  |                                         |--------- EDAR ------->|
>  |                                         |                       |
>  |                                         |<-------- EDAC --------|
>  |                                         |                       |
>  |                                         |           |           |
>  |                                         |-DAO(X=0)->|           |
>  |                                         |           |           |
>  |                                         |<- DAO-ACK-|           |
>  |                                         |           |           |
>  |<----------- NA EARO (status=0)----------|           |           |
>  |                                         |           |           |
>                                      ...
>  |                                         |           |           |
>  |------ NS EARO (ROVR=Crypto-ID) -------->|           |           |
>  |                                         |-DAO(X=1)->|           |
>  |                                         |           |-- EDAR -->|
>  |                                         |           |           |
>  |                                         |           |<-- EDAC --|
>  |                                         |<- DAO-ACK-|           |
>  |<----------- NA EARO (status=0)----------|           |           |
>  |                                         |           |           |
>                                      ...
> 
> 
> > 
> >    The 6LR may at any time send a unicast asynchronous NA(EARO) with the
> >    R Flag set to 0 to signal that it stops providing routing services,
> > 
> > Staying on theme, what will a RUL that doesn't know about this spec do with
> > such an asynchronous NA(EARO)?
> 
> This was already prepared for in RFC 8505
> 
>    |   4   | Removed: The binding state was removed.  This Status MAY  |
>    |       | be placed in an NA(EARO) message that is sent as the      |
>    |       | rejection of a proxy registration to an IPv6 ND           |
>    |       | Registrar, or in an asynchronous NA(EARO), at any time.   |
>    |       |                                                           |
> 
> 
> > 
> > Section 9.2.3
> > 
> >    A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration
> >    Option of the DIO messages that it generates (see Section 6) to
> >    signal that it proxies the EDAR/EDAC exchange and supports the
> >    Updated RPL Target option.
> > 
> > [just noting that this is another place, in addition to §6.2, where we enumerate
> > what the 'P' flag signals, which may be incomplete, per my previous comment.]
> 
> I do not think it is incomplete 
> 
> 
> > 
> > Section 10
> > 
> >    The 6LR acts as a generic MLD querier and generates a DAO with the
> >    Multicast Address as the Target Prefix as described in section 12 of
> >    [RFC6550].  As for the Unicast host routes, the Path Lifetime
> >    associated to the Target is mapped from the Query Interval, and set
> >    to be larger to account for variable propagation delays to the Root.
> > 
> > (Is this just the "round up, if needed" setting, or is there more to consider when
> > accounting for variable propagation delays?)
> 
> Propagation delay can be very long, like a number of seconds.

Perhaps we should say more in §9.2.2, then, as the only corresponding text
I could find for the unicast route case was "in that operation, the Path
Lifetime must be rounded, if needed, to the upper value to ensure that the
path has a longer lifetime than the registration."  What you describe seems
to be more than just a "rounding" operation by adding additional time.

> > 
> >    The Root proxies the MLD exchange as a listener with the 6LBR acting
> >    as the querier, so as to get packets from a source external to the
> >    RPL domain.
> > 
> > (Only if the source is external to the RPL domain, right?)
> 
> Yes
> 
> 
> > 
> > Section 11
> > 
> >    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.
> > 
> > (editorial) I suggest some phrasing akin to "this specification improves the
> > situation by isolating edge nodes so they can only interact [...]".
> 
> Done
> 
> 
> > 
> >    In a general manner, the Security Considerations in [RFC7416]
> >    [RFC6775], and [RFC8505] apply to this specification as well.
> > 
> > But not those of RFC 6550?
> 
> Oups, added
> 
> > 
> >    More importantly, the 6LR is the node that injects the traffic in the
> >    RPL domain, so it has the final word on which RPLInstance is to be
> >    used for the traffic coming from the RUL, per its own policy.
> > 
> > [I do believe I commented previously about just this topic :) ]
> 
> Yes, I suggest to add 
> "
>                                                                                             In particular, a
>     policy can override the formal language that forces to use the Opaque field
>     or to rewrite the RPI provided by the RUL, in a situation where the
>     network administrator finds it relevant.
> "
> I hope that sorts it out, but we can have another round.
> 
> As usual now, many thanks for your incredible review. I'm learning a lot.
> 
> Take care, and enjoy the break!

You, too!

-Ben