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

[Rahul Arvind Jadhav <[e-mail]>]

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.


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.

[RJ] Have removed the redundant text.

...

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.
[RJ] Removed the redundant text.

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

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

Either way, the vulnerability still exists.

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

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

[RJ] Made it I flag everywhere consistently.

...

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.

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