Re: [Roll] giving back MPDAO to RFC editor

[Rahul Jadhav <[e-mail]>]

The erratum seems to have been reported long back.
Final updates: https://github.com/roll-wg/efficient-route-invalidation/commit/9fff6e6051c2a2560bddd3f5097bf19149edd52a

On Thu, 5 Sep 2019 at 12:01, Pascal Thubert (pthubert)
<[e-mail]> wrote:
>
> Hello Rahul
>
>
>
> RPL says
>
>
>
>      1-127:  Not an outright rejection; the node sending the DAO-ACK
>
>                is willing to act as a parent, but the receiving node is
>
>                suggested to find and use an alternate parent instead.
>
>      127-255:  Rejection; the node sending the DAO-ACK is unwilling to
>
>                act as a parent.
>
>
>
>
>
> Note that the 127 as a rejection is a typo. The intent was that 127 is not a rejection. We could write an erratum for this I guess so rejection starts at 128.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> From: Rahul Jadhav <[e-mail]>
> Sent: jeudi 5 septembre 2019 05:44
> To: Pascal Thubert (pthubert) <[e-mail]>; Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] giving back MPDAO to RFC editor
>
>
>
> Thank you Pascal for the changes and pull request.
>
> Have merged the changes.
>
> I made two minor changes, please check if there are ok:
>
> https://github.com/roll-wg/efficient-route-invalidation/commit/8af38e8f44b963987ee6754d644d6ef70409462f
>
>
>
> If yes, then please use the latest xml from
>
> https://github.com/roll-wg/efficient-route-invalidation/blob/master/draft-ietf-roll-efficient-npdao.xml
>
>
>
> Thanks,
>
> Rahul
>
> ________________________________
>
> From: Roll <[e-mail]> on behalf of Ines Robles <mariainesrobles=[e-mail]>
> Sent: Wednesday, September 4, 2019 10:33 AM
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: roll <[e-mail]>
> Subject: Re: [Roll] giving back MPDAO to RFC editor
>
>
>
> Hi Pascal,
>
>
>
> Thank you very much for your hard work.
>
>
>
> Could you please convert the draft-ietf-roll-efficient-npdao-16.xml to txt [https://xml2rfc.tools.ietf.org/] and put them here https://github.com/roll-wg/efficient-route-invalidation, so people can read the complete document with the proposed changes, thus we can have a last call.
>
>
>
> Many thanks again,
>
>
>
> Ines and Peter.
>
>
>
>
>
>
>
> On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <[e-mail]> wrote:
>
> Dear all
>
>
>
> We are holding NP DAO for a change that does not impact the behavior of the node but improves traceability.
>
> I would like to confirm consensus on this change rapidly so we can give the doc back to RFC editor.
>
>
>
> The proposed change is as follows:
>
>
>
> ----------------------------------
>
>
>
> diff --git "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml" "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
>
> index 8a0acca..2ed0920 100644
>
> --- "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml"
>
> +++ "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
>
> @@ -35,7 +35,7 @@
>
> <?rfc subcompact="yes" ?>
>
> <!-- keep one blank line between list items -->
>
> <!-- end of list of popular I-D processing instructions -->
>
> -<rfc category="std" docName="draft-ietf-roll-efficient-npdao-15" ipr="trust200902">
>
> +<rfc category="std" docName="draft-ietf-roll-efficient-npdao-16" ipr="trust200902">
>
>    <!-- category values: std, bcp, info, exp, and historic
>
>       ipr values: full3667, noModification3667, noDerivatives3667
>
>       you can add the attributes updates="NNNN" and obsoletes="NNNN"
>
> @@ -582,11 +582,12 @@
>
>
>
>              <t>
>
>                  This document specifies a change in the Transit Information Option to
>
> -                contain the "Invalidate previous route" (I) flag. This I-flag signals
>
> +                contain the "Invalidate previous route" (I) flag. This 'I' flag signals
>
>                  the common ancestor node to generate a DCO on behalf of the
>
> -                target node. The I-flag is carried in the Transit Information
>
> +                target node with a RPL Status of 130 indicating that the address
>
> +                has moved. The 'I' flag is carried in the Transit Information
>
>                  Option which augments the reachability information for a given
>
> -                set of RPL Target(s). Transit Information Option with I-flag
>
> +                set of RPL Target(s). Transit Information Option with 'I' flag
>
>                  set should be carried in the DAO message when route
>
>                  invalidation is sought for the corresponding target(s).
>
>              </t>
>
> @@ -615,8 +616,8 @@
>
>              </t>
>
>              <t>
>
>                  The common ancestor node SHOULD generate a DCO message in
>
> -                response to this I-flag when it sees that the routing
>
> -                adjacencies have changed for the target. The I-flag is
>
> +                response to this 'I' flag when it sees that the routing
>
> +                adjacencies have changed for the target. The 'I' flag is
>
>                  intended to give the target node control over its own route
>
>                  invalidation, serving as a signal to request DCO generation.
>
>              </t>
>
> @@ -638,7 +639,7 @@
>
> 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
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> -| RPLInstanceID |K|D|   Flags   |   Reserved    | DCOSequence   |
>
> +| RPLInstanceID |K|D|   Flags   |  RPL  Status  | DCOSequence   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |                                                               |
>
> +                                                               +
>
> @@ -683,8 +684,15 @@
>
>                  the sender and MUST be ignored by the receiver.
>
>              </t>
>
>              <t>
>
> -                Reserved: 8-bit unused field. The field MUST be initialized to
>
> -                zero by the sender and MUST be ignored by the receiver.
>
> +                RPL Status: The RPL Status as defined in section 6.5.1 of <xref
>
> +                target="RFC6550"/>.
>
> +                Indicative of the reason why the DCO happened, the RPL Status
>
> +                MUST NOT be changed as the DCO is propagated down the route
>
> +                being invalidated.
>
> +                This value is informative and does not affect the behavior of
>
> +                the receiver. In particular, unknown values are ignored by the
>
> +                receiver.
>
> +                Only Rejection Codes (value above 128) are expected in a DCO.
>
>              </t>
>
>              <t>
>
>                  DCOSequence: 8-bit field incremented at each unique DCO message
>
> @@ -759,7 +767,7 @@
>
> 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
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> -| RPLInstanceID |D|   Flags     |  DCOSequence  |    Status     |
>
> +| RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |                                                               |
>
> +                                                               +
>
> @@ -788,8 +796,10 @@
>
>                      copied from the DCOSequence received in the DCO message.
>
>                  </t>
>
>                  <t>
>
> -                    Status: Indicates the completion. Status 0 is defined as
>
> -                    unqualified acceptance in this specification. Status 1 is
>
> +                    DCO-ACK Status: Indicates the completion. A value of 0 is
>
> +                    defined as
>
> +                    unqualified acceptance in this specification. A value of 1
>
> +                    is
>
>                      defined as "No routing-entry for the Target found". The
>
>                      remaining status values are reserved as rejection codes.
>
>                  </t>
>
> @@ -910,7 +920,7 @@
>
>                      nodes will generate their respective DAOs to update their
>
>                      paths, and the previous route invalidation for those nodes
>
>                      should work in the similar manner described for switching
>
> -                    node. The dependent node may set the I-flag in the Transit
>
> +                    node. The dependent node may set the 'I' flag in the Transit
>
>                      Information Option as part of regular DAO so as to
>
>                      request invalidation of previous route from the common
>
>                      ancestor node.
>
> @@ -920,7 +930,7 @@
>
>                      of their parents in turn have decided to switch their
>
>                      parent. Thus for route invalidation the dependent nodes may
>
>                      choose to always set the 'I' flag in all its DAO message's
>
> -                    Transit Information Option. Note that setting the I-flag is
>
> +                    Transit Information Option. Note that setting the 'I' flag is
>
>                      not counterproductive even if there is no previous
>
>                      route to be invalidated.
>
>                  </t>
>
> @@ -1103,7 +1113,7 @@
>
>
>
>          <t>
>
>              IANA is requested to allocate bit 1 from the Transit Information
>
> -            Option Flags registry for the I-flag (<xref target="transit_opt_changes"/>)
>
> +            Option Flags registry for the 'I' flag (<xref target="transit_opt_changes"/>)
>
>          </t>
>
>          <section title="New Registry for the Destination Cleanup Object (DCO) Flags">
>
>              <t>
>
> @@ -1210,22 +1220,29 @@
>
>              This document introduces the ability for a common ancestor node to
>
>              invalidate a route on behalf of the target node. The common
>
>              ancestor node could be directed to do so by the target node using
>
> -            the I-flag in DCO's Transit Information Option. However, the common
>
> +            the 'I' flag in DCO's Transit Information Option. However, the common
>
>              ancestor node is in a position to unilaterally initiate the route
>
>              invalidation since it possesses all the required state information,
>
>              namely, the Target address and the corresponding Path Sequence..
>
>              Thus a rogue common ancestor node could initiate such an
>
>             invalidation and impact the traffic to the target node.
>
>          </t>
>
> +        <t> The DCO carries a RPL Status value, which is informative. New Status
>
> +            values may be created over time and a node will ignore an unknown
>
> +            Status value. Which makes it so that the RPL Status field may be
>
> +            used as a cover channel. But the channel only works once since the
>
> +            message destroys its own medium, that is the existing route that it
>
> +            is removing.
>
> +        </t>
>
>          <t>
>
> -            This document also introduces an I-flag which is set by the target
>
> +            This document also introduces an 'I' flag which is set by the target
>
>              node and used by the ancestor node to initiate a DCO if the
>
>              ancestor sees an update in the route adjacency. However,
>
>              this flag could be spoofed by a malicious 6LR in the path and can
>
>              cause invalidation of an existing active path. Note that invalidation
>
>              will happen only if the other conditions such as Path Sequence
>
>              condition is also met. Having said that, such a malicious 6LR may
>
> -            spoof a DAO on behalf of the (sub) child with the I-flag set and
>
> +            spoof a DAO on behalf of the (sub) child with the 'I' flag set and
>
>              can cause route invalidation on behalf of the (sub) child node..
>
>              Note that, using existing mechanisms offered by <xref
>
>                  target="RFC6550"/>, a malicious 6LR might also spoof a DAO with
>
>
>
>
>
> Chairs, could we please last call or whatever so we can move on?
>
>
>
> Many thanks!
>
>
>
> Pascal
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll