Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt

Remous-Aris Koutsiamanis <> Sat, 29 February 2020 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1FA03A074E for <>; Fri, 28 Feb 2020 16:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=eBgFojta; dkim=pass (2048-bit key) header.b=rJGX9wMa
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zncPXW7N0kR6 for <>; Fri, 28 Feb 2020 16:05:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20F713A0764 for <>; Fri, 28 Feb 2020 16:05:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A092576 for <>; Sat, 29 Feb 2020 01:05:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20160819-nLV10XS2; t=1582934740; bh=52nXIxJqoPSa73urUbXC1KjP3DxhN2eyI4Ks7RBEijc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eBgFojtaj7Kt7G6X1bOHy2UKcyRX8x8YbXQkJho00Ev4e+NZsL6yoD+SJ3R5SSyXJ NhnGeGb9K9hiaa8fhvIcGcs15miUWfXJjF2rnudR7QlV9NvSakjxn+XxmR2pDC+1OW 3dOXPTrbna2zx87eXTcxLozSQhZzbXgmD5LEAWiR+HHVnJehwVcsAGEDBmJUkCsA7Z DyHhy2XQfv5otm+NFh7UQJ6WB0LDZMmrftUYLVHuX1uKMWT1CJ74Zt7YRqRGn+vuEJ NTMYsPUs2cDYvdJdwM/+z4cusKenbNba9WPXYu1gtTkTjlnIhhwx+Nonp66EboVmcL lWnqCuBg/vnog==
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1582934740; s=20191001-wvim;;; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=19693; bh=52nXIxJqoPSa73urUbXC1KjP3DxhN2eyI4Ks7RBEijc=; b=rJGX9wMacSUm9vhTrpW6CfTPrEDkJ8mvOgjl8u064Jj/8JN2SxukBATksrDXZHuj nDdvvjUSm7N1F6wYDKjac+xOciY4cWWtibsvmYaFZPoF+D6iU/ktCGTftYZ/Y9Oq3r6 5q/lLRPGQuI52/UEktp1mFQhxB5ZqkF2R5HHOhWXLJ2iz6n2PxVj5cIbLaAFazKf7gQ aQ69+xBdjaG1Ic3TvSG8vgT1yR1cb4T7NjowGBDjrxfbLOGMZcr3OHtT4gXcvJHhDUh VtWYiKv0GTF/9RwFOSfdAtUTJtoCfC1rqdNvsEQREGfAxHcPWaMxZhCSWHikArAKnKt YL+8dl6xTA==
Received: by with ESMTPA for <> ; Sat, 29 Feb 2020 01:05:34 +0100 (CET)
Received: by with SMTP id z1so5434720iom.9 for <>; Fri, 28 Feb 2020 16:05:33 -0800 (PST)
X-Gm-Message-State: APjAAAU5v5/NgzvVn2oSZOf7HvK4Sm633A8cUVVSXpv9uOmU1iLSz749 D8TuEJ0SuX+0nwgKqHIO9lUjeiIoJknFoT/21zE=
X-Google-Smtp-Source: APXvYqytuk8fzhZpginqkvG8oOE5xGhj8fZoROLgTOkxYxpxppPsQdiJHkSj8eRRyQdwDsYvu+iSukmHvXi+wH5YWlI=
X-Received: by 2002:a5d:860a:: with SMTP id f10mr5741457iol.259.1582934729243; Fri, 28 Feb 2020 16:05:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Remous-Aris Koutsiamanis <>
Date: Sat, 29 Feb 2020 01:05:35 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: dominique barthel <>
Cc: Routing Over Low power and Lossy networks <>, "Georgios Z. Papadopoulos" <>
Content-Type: multipart/alternative; boundary="0000000000003d41cb059fabb65c"
X-ContactOffice-Account: com:113819248
Archived-At: <>
Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Feb 2020 00:05:47 -0000

Hello Dominique,

thank you very much for the thorough review.
Comments inline.

On Wed, Feb 26, 2020 at 12:15 PM <> wrote:

> Hello all,
> Another comment about this draft. The Security Considerations section
> currently says
> " The structure of the DIO control message is extended, within the pre-
>    defined DIO options.  Therefore, the security mechanisms defined in
>    RPL [RFC6550] apply to this proposed extension."
> I don't think this addresses the purpose of a Security Considerations
> section.

OK, maybe I misunderstood what exactly I should have elaborated on.

I think it should talk about the potential security issues introduced by
> the draft, and why they are not real concerns.

I thought that no real extra concerns are present, but as you propose,
maybe some more details would be helpful.

> I guess that, what this draft changes compared to RFC6550-6551, is the
> sending of the Parent Set of a node in its DIO. From there:
> - This could result in a privacy issue. Yes, but the Parent Set is not
> propagated further down the DODAG, so this disclosure does not reach far
> beyond the propagation range of the radios of the Parents. So no tracking
> of nodes by their IPv6 address possible from remote (a least no more than
> in the current situation).

This is definitely present, I will add this issue, despite it not being
especially problematic. Just to be complete.

> - This could result in introducing a vulnerability: could an attacker
> exploit the knowledge gained from learning the PS? …

Well, maybe with an assumption of a malicious node being able to decode the
DIO, i.e. having the correct enc/decryption keys.
1. A malicious node that can read the DIO can "see" further than it's own
neighbourhood by one hop, learning the addresses of it's two hop neighbors.
So as mentioned, this is a privacy / network discovery issue.
2. A node that can send DIOs can use the parent set to convince neighbours
to route through itself, instead of the normal preferred parent they would
use. However, with other OFs this is already possible by reporting a fake
rank value of 0 in the DIO, thus appearing as the DODAG root.

As far as I can tell, if a malicious node manages to participate in the RPL
network (i.e. decode/encode the RPL control packet) it is game over and it
can definitely severely affect the operation of the whole network, just by
reporting a fake rank.
However, maybe this is not true; I'm not really an very familiar with the
security of RPL.

I don't see any other opportunities for security issues.
I will add these two to the draft unless you have something additional.

> Best regards
> Dominique

Thank you very much Dominique for the help.


> De : Roll <> on behalf of "Georgios Z. Papadopoulos"
> <>
> Répondre à : "" <>
> Date : Monday 10 February 2020 16:51
> À : "" <>
> Objet : [Roll] Fwd: New Version Notification for
> draft-ietf-roll-nsa-extension-06.txt
> Dear all,
> FYI, we just submitted the 06 version where we addressed the comments from
> Rahul.
> Many thanks Rahul,
> Georgios and Aris
> Begin forwarded message:
> *From: *
> *Subject: **New Version Notification for
> draft-ietf-roll-nsa-extension-06.txt*
> *Date: *February 10, 2020 at 16:16:06 GMT+1
> *To: *"Nicolas Montavont" <>, "Pascal
> Thubert" <>, "Georgios Papadopoulos" <
>>, "Remous-Aris Koutsiamanis" <
> A new version of I-D, draft-ietf-roll-nsa-extension-06.txt
> has been successfully submitted by Remous-Aris Koutsiamanis and posted to
> the
> IETF repository.
> Name: draft-ietf-roll-nsa-extension
> Revision: 06
> Title: Common Ancestor Objective Function and Parent Set DAG Metric
> Container Extension
> Document date: 2020-02-10
> Group: roll
> Pages: 15
> URL:
> Status:
> Htmlized:
> Htmlized:
> Diff:
> Abstract:
>   Implementing Packet Replication and Elimination from/to the RPL root
>   requires the ability to forward copies of packets over different
>   paths via different RPL parents.  Selecting the appropriate parents
>   to achieve ultra-low latency and jitter requires information about a
>   node's parents.  This document details what information needs to be
>   transmitted and how it is encoded within RPL control packets to
>   enable this functionality.  This document also describes Objective
>   Function which take advantage of this information to implement multi-
>   path routing.
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.