Subject: Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09

From: Alvaro Retana <[email-masked]>
Date: Tue, 7 May 2019 16:23:01 -0700

On April 27, 2019 at 2:07:34 PM, Rahul Jadhav ([email-masked]) wrote:

Rahul

Hi!

I have some remaining comments below.  I think that all of them can be
handled as IETF Last Call comments — so I’ll go ahead and start it.

The only remaining item is whether you (the WG) want an ancestor to be able
(as a feature) to generate a DCO without the corresponding DAO…. I’ll let
you discuss that in the WG an include it (or not) before we start IESG
Evaluation.

Thanks!

Alvaro.

...

418 4.3.2. DCO Options

420 The DCO message MAY carry valid options. This specification allows
421 for the DCO message to carry the following options:

423 0x00 Pad1
424 0x01 PadN
425 0x05 RPL Target
426 0x06 Transit Information
427 0x09 RPL Target Descriptor

429 The DCO carries a Target option and an associated Transit Information
430 option with a lifetime of 0x00000000 to indicate a loss of
431 reachability to that Target.

[major] Are the RPL Target and Transit Information options mandatory? If
so, then that is at odds with the MAY above.

[RJ] Explicitly added the MUST clause for Target and Transit options. Also
the
lifetime field in the transit option MUST be set to 0 in DCO's transit
option.

The new text is redundant (talks about the lifetime twice):

   The DCO carries an RPL Target Option and an associated Transit

   Information Option with a lifetime of 0x00000000 to indicate a loss

   of reachability to that Target.  The lifetime indicated in the

   Transit Information Option of the DCO message MUST be set to

   0x00000000.

...

433 4.3.3. Path Sequence number in the DCO

435 A DCO message may contain a Path Sequence in the transit information
436 option to identify the freshness of the DCO message. The Path
437 Sequence in the DCO MUST use the same Path Sequence number present in
438 the regular DAO message when the DCO is generated in response to DAO
439 message. The DAO and DCO path sequence are picked from the same
440 sequence number set. Thus if a DCO is received by a 6LR and
441 subsequently a DAO is received with old seqeunce number, then the DAO
442 should be ignored.

[minor] To make sure I'm clear: the "DCO path sequence" refers to the Path
Sequence field in the Transit Information Option, right? If so, please be
clear and specific.

[RJ] Updated.

There is redundant text here too:

   Option to identify the freshness of the DCO message.  The Path

   Sequence in the DCO MUST use the same Path Sequence number present in

   the regular DAO message when the DCO is generated in response to a

   DAO message.  The Path Sequence present in the Transit Information

   Option of the DAO and the correspondingly triggered DCO MUST be same.

...

[major] "Path Sequence in the DCO MUST use the same Path Sequence number
present in the regular DAO message when the DCO is generated in response to
DAO message" The DAO message is obviously the one that triggered the
DCO... When would a DCO *not* be originated in response to a DAO? Are
there other cases when the DCO can be originated? Requiring the same Path
Sequence is fine...the reason for this comment is the condition ("when the
DCO...").

[RJ] One other condition that i can think of is, if the common ancestor node

somehow believes that there are other high priority routing entries that it
must entertain, thus evicting existing ones. During such eviction the common

ancestor node could make use of the stored path sequence and initiate a DCO.

DCO can fully support this in current form. Do you think this use-case makes

sense? We introduced 'I' bit especially so that target is in full control of

its own invalidation. With such change we loosen up that part.

Hmm…I initially thought that this case would be a vulnerability. :-(

Are there cases that you can come up with where those other “high priority
routing entries” would have to be invalidated and that they wouldn’t just
be preferred normally??  It is really up to the WG to determine if that is
an use case that makes sense….

Either way, the vulnerability still exists.

...

498 4.4.1. Dependent Nodes invalidation

500 Current RPL [RFC6550] does not provide a mechanism for route
501 invalidation for dependent nodes. This document allows the dependent
502 nodes invalidation. Dependent nodes will generate their respective
503 DAOs to update their paths, and the previous route invalidation for
504 those nodes should work in the similar manner described for switching
505 node. The dependent node may set the I-bit in the transit
506 information option as part of regular DAO so as to request
507 invalidation of previous route from the common ancestor node.

[major] This part is underspecified. How do the dependent nodes know of
the switch? Is A (Figure 1) the common ancestor node mentioned above?

I found the same question being asked during WGLC, and the answer seems to
be: "the dependent nodes will always set the I-flag". Is that my correct
interpretation? The behavior needs to be reflected in the specification.

https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg

[RJ] I have added a para to describe this more. Please check if it makes
sense.

If the dependent node always sets the I bit, wouldn’t that result in
constant invalidation (unless no route existed before)?  IOW, it seems like
the setting of the I bit has to be conditional.  The mail archive talks
about the DTSN incrementing — I’m assuming this will happen then the parent
switches to a different parent…is that true?  If so, then I think that this
piece of text still needs some work.

[nit] The I bit is sometimes called the I flag…please be consistent.

...

570 7. Security Considerations

[major] This section mostly points at rfc6550 (which is ok), but it doesn't
say anything about vulnerabilities (if any) that this specification may be
introducing...or why it doesn't. [See my related comment in §4.3.3.]

I would like to see (perhaps after the current text) something along the
lines of "This document introduces the ability to do abc. It doesn't
introduce any new vulnerabilities becasue... OR ... These are the new
vulnerabilities and this is how they can be mitigated...or why they are not
really of concern..."

[RJ] Have added this text in the beginning of the security considerations
section. Also have updated the "Unsecured" mode para, to say that the DCO
and
DCO-ACK MUST be link-layer encrypted if link-layer security is been put to
use.

That is not what I read in the new text: "A DCO and DCO-ACK message which
is not encrypted at link-layer MUST not be handled by the RPL layer.  Also
all the DCO and DCO-ACK messages that are transmitted MUST be link-layer
encrypted.”  I read this text as saying that the DCO/DCO-ACK MUST always be
link-layer encrypted… I couldn’t find that to be the same expectation as in
rfc6550.

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Thu, 16 May 2019 05:37:39 +0000

Thanks Alvaro for rechecking the draft updates.
And thanks to Francis for the review comments.

Updates:

1.       Removal of redundant text, I-flag naming consistency as per Alvaro’s comments.

2.       Fixed nits as per Francis comments.
These updates are currently in roll-wg github only (here<https://github.com/roll-wg/efficient-route-invalidation/commit/775886bf93223e80273be04f9d993526d01cfb64>). Would be uploading the new ID along with changes, if any, resulting out of other discussion.

Please find comments inline for other points.

Still pending, is the discussion about allowing unsolicited DCO.

Regards,
Rahul

The only remaining item is whether you (the WG) want an ancestor to be able (as a feature) to generate a DCO without the corresponding DAO…. I’ll let you discuss that in the WG an include it (or not) before we start IESG Evaluation.

[RJ] This discussion is initiated.

   0x00000000.

[RJ] Have removed the redundant text.

...

   Option of the DAO and the correspondingly triggered DCO MUST be same.
[RJ] Removed the redundant text.

...

Are there cases that you can come up with where those other “high priority routing entries” would have to be invalidated and that they wouldn’t just be preferred normally??  It is really up to the WG to determine if that is an use case that makes sense….

[RJ] I’ll leave this to the explicit discussion we are having on another thread.

[RJ] The weak points of DCO is same as that of DAO. I mean, if there is a malicious 6lr which somehow manages to break into RPL network i.e. gets access keys used for encryption/mic, then there are several attacks possible using existing DAO itself … The route invalidation vulnerability exists with DAO itself. Any malicious 6LR can trigger a no-path DAO causing route invalidation, the same could be done with DCO as well. In the security consideration, we raised the possibility that malicious 6LR can initiate DCO unilaterally and invalidate active routes. The prevention plan is same as RFC6550.

...

[RJ] I have added a para to describe this more. Please check if it makes sense.

If the dependent node always sets the I bit, wouldn’t that result in constant invalidation (unless no route existed before)?  IOW, it seems like the setting of the I bit has to be conditional.  The mail archive talks about the DTSN incrementing — I’m assuming this will happen then the parent switches to a different parent…is that true?  If so, then I think that this piece of text still needs some work.

[RJ] Made it I flag everywhere consistently.

...

[RJ] Have added this text in the beginning of the security considerations
section. Also have updated the "Unsecured" mode para, to say that the DCO and
DCO-ACK MUST be link-layer encrypted if link-layer security is been put to use.

That is not what I read in the new text: "A DCO and DCO-ACK message which is not encrypted at link-layer MUST not be handled by the RPL layer.  Also all the DCO and DCO-ACK messages that are transmitted MUST be link-layer encrypted.”  I read this text as saying that the DCO/DCO-ACK MUST always be link-layer encrypted…    I couldn’t find that to be the same expectation as in rfc6550.

[RJ] Yes. MUST is not mentioned in 6550. Thanks for this observation. I have removed the two stmts and aligned it with 6550 text.

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Thu, 16 May 2019 08:37:46 +0000

I missed one important point raised in Alvaro’s review:

[RJ]  Actually this point has relation on how sub-dodag (rooted at 6LR switching the parent) routing state update happens in storing MOP. Unfortunately 6550 is not clear on this. We had made this observation in the rpl-observation draft.

If the sub-dodag has to be updated then there are two ways:

1.       Incrementing DTSN by the switching 6LR. When downstream child 6LRs see a new DTSN from their preferred parent, they also increment DTSN (as well as resetting trickle timer) and thus update the sub-dodag. This has control overhead implications but most easy to implement. If the network is not too deep/mobile and the MRHOF switching threshold is high enough then this works out great.

2.       Other option is that switching 6LR update the routing state on new path based on its own routing state. This has looping implications as Pascal mentioned in previous mail and also is not easy to implement because you can only stuff in x number of targets/transit options in a given DAO and then managing multiple DAOs is painful.

My implementation currently uses option 1. Thus I am tempted to follow option 1 and let I-flag be enabled only on identifying DTSN increment. But then I didn’t see any loss in keeping I-flag enabled always if target is interested in its invalidation. The invalidation only happens if the route entry is with different nexthop and the path sequence criteria is fulfilled on the ancestor node. In my implementation, I currently enable I-flag always (even though I could have enabled it on the basis of DTSN value). Having said that, if anyone else has any other opinion, I am open to changing the text and setting I-flag conditionally based on DTSN increment.

Or I could point out these possibilities as it is in the draft and let the implementers decide?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 May 2019 09:12:07 +0000

Hello Rahul:

My intuition was that a node that ceases to see or ceases to want to use one of its parents P (a parent through which it sent a DAO in the past) would increment its path sequence and send a new DAO with the I flag set via the new set of selected parents. Note that if the parent is still reachable the NPDAO can also invalidate the route but the DCO has a number of advantages. In particular it only kills the old route when the new route is available, and it follows the traffic on the way down to it does not kill it as the cross like a NPDAO would.

The result is invalidation of all the routes with the older path sequence. To answer Alvaro, the trigger is a loss of a parent, or the desire to stop getting traffic from a parent for whatever other reasons.
Also note that a common ancestor may have more than one child reaching the target and all the children with the stale path sequence should get a DCO.

DTSN will pull the routes and if a stale route shows up at the common ancestor then the common ancestor may decide to send a DCO that is not triggered by a I flag but by observing a stale route. The target cannot know that. I agree that the I flag is relatively armless since the DCO is only sent to stale paths. But how long would a target still set it? For me it is mostly a one shot thing, at least if the DAO is acked.

All the best,

Pascal

From: Rahul Arvind Jadhav <[email-masked]>
Sent: jeudi 16 mai 2019 10:38
To: Routing Over Low power and Lossy networks <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: roll-chairs <[email-masked]>; [email-masked]
Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-09