[Roll] Last call to draft-ietf-roll-efficient-npdao-16

Ines Robles <mariainesrobles@googlemail.com> Wed, 04 September 2019 14:02 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0DB120100 for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 07:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfdV5IEdyClT for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 07:02:49 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51F0120116 for <roll@ietf.org>; Wed, 4 Sep 2019 07:02:48 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id g207so3443418wmg.5 for <roll@ietf.org>; Wed, 04 Sep 2019 07:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=968eLaztDchjpSCa2L9f0aVBErRoSFgYtQDDDK/+yFs=; b=gzfWO7zquMR8sP1tLaGlxNIJ33r5g7jnHKR7MI3mfhg65mSW3rmHEsRFm/i8kotRTj b8hutq6q2WuQPWe7G5x6djY5avIUj7MujNLF0HIX2a2jdmoGgISUT6izjPjWBTaDeEnU kn1oY/Uuf9WkztxltPTpQChJAu+vHOO5M16UnDPxtfQpRIfAsLIOCLtITOdld9sCDCIJ UHkfZGqOlaBFx8qODpTV16i9A7Q5KooOrUIGTZePbjNwcwFVxswCCeRg9ftK5nW71JFu ksozYs2Ws4xy7c73rNdztvGhqbzS+sST4UonRXmqIjKHfEygxzZSd90IrXvDmEv1x6N6 4WAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=968eLaztDchjpSCa2L9f0aVBErRoSFgYtQDDDK/+yFs=; b=dYsYEEEdesG55iK75eQXOdb12mCGk5skPi0AJKfajs7yMOSqm7fs9UZQS9/di4yVMK SSoXj209tNXxrVWAqpwWparlcJ/dhUZWqGeSIbBBT7/THBoUzciHrej0bYVp9q891WlU Uj4L6XtTfmm9POsYef/PyKc82qxdKZEqmjfA1iiT8ZSfnFEosiUkTr4HKtojzO1R7ip7 /1DfDZHAFHd0PZ4ybYqfgZdj1UuttvG3epd0fIUi7nnL2IQdU/HlAGvxoU3vqREI0JZ0 VmiwhhAfqNpYBSn4d8yl5KIGtfT9rk2bgrq5iV4HjadnrNSjjthxcUwnFeD40pLUOIk6 lcKg==
X-Gm-Message-State: APjAAAW74WSgJQJ5pVoH4xy5zw6v0unzjZEkENYECMyapqoVgLljONLz tOiq9uJR1LzvJK9u3tFWMjRHsrc+CvXusIrGYhXnAYDF
X-Google-Smtp-Source: APXvYqxRVqMbIcr6/2Fg6/MqMcp3HIRkvUbZJx2+7HYQLdmXXXyRP8XMsu8dMxYltiZSS/6ZSWafSPOOYHfR5P1jr18=
X-Received: by 2002:a1c:7513:: with SMTP id o19mr4422292wmc.126.1567605767002; Wed, 04 Sep 2019 07:02:47 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB3565DAEEF4DD78D732EDE17DD8B80@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565DAEEF4DD78D732EDE17DD8B80@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 4 Sep 2019 17:02:35 +0300
Message-ID: <CAP+sJUeEWC-bhw2U0t82-45ha3vOEcuqiD9U4Hmc-xR=y6PM6w@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3dee00591baa852"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/zhkJiPRrhLm1qfk71j6G6ei3EN8>
Subject: [Roll] Last call to draft-ietf-roll-efficient-npdao-16
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 14:02:53 -0000

Dear all,

This is a last call for the modified NPDAO document (version 16) that you
can find here

https://github.com/pthubert/efficient-route-invalidation/blob/master/draft-ietf-roll-efficient-npdao.txt

This call is open until 23th September. Please let us know your opinion.

Thank you very much in advance,

Ines and Peter.

On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <pthubert@cisco.com>
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
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>