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

[Alvaro Retana <[e-mail]>]

On April 27, 2019 at 2:07:34 PM, Rahul Jadhav ([e-mail]) 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.