Return-Path: 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 A1FA03A074E for ; Fri, 28 Feb 2020 16:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=eBgFojta; dkim=pass (2048-bit key) header.d=ariskou.com header.b=rJGX9wMa 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 zncPXW7N0kR6 for ; Fri, 28 Feb 2020 16:05:43 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F713A0764 for ; Fri, 28 Feb 2020 16:05:42 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (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; d=mailfence.com; 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; d=ariskou.com; i=aris@ariskou.com; 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 smtp.mailfence.com with ESMTPA for ; Sat, 29 Feb 2020 01:05:34 +0100 (CET) Received: by mail-io1-f46.google.com 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: <158134776694.4117.16175545100765405335.idtracker@ietfa.amsl.com> <25766_1582715717_5E565345_25766_121_1_DA7C0EE9.71074%dominique.barthel@orange.com> In-Reply-To: <25766_1582715717_5E565345_25766_121_1_DA7C0EE9.71074%dominique.barthel@orange.com> From: Remous-Aris Koutsiamanis Date: Sat, 29 Feb 2020 01:05:35 +0100 (CET) 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-BeenThere: roll@ietf.org 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 --0000000000003d41cb059fabb65c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? =E2=80=A6 > 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. Best, Aris > > De : Roll on behalf of "Georgios Z. Papadopoulos" > > R=C3=A9pondre =C3=A0 : "roll@ietf.org" > Date : Monday 10 February 2020 16:51 > =C3=80 : "roll@ietf.org" > 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 fro= m > Rahul. > > Many thanks Rahul, > Georgios and Aris > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *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" < > georgios.papadopoulos@imt-atlantique.fr>, "Remous-Aris Koutsiamanis" < > aris@ariskou.com> > > > 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: > https://www.ietf.org/internet-drafts/draft-ietf-roll-nsa-extension-06.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-06 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-extension-06 > > 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 tools.ietf.org. > > The IETF Secretariat > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000003d41cb059fabb65c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dominique,

thank you very much for the thorough review.
Comments inlin= e.

On Wed, Feb 26, 2020 at 12:15 PM <dominique.barthel@orange.com> wrote:
=
Hello all,

Another comment about this draft. The Security Considerations section = currently says
" The structure of the DIO control message is extended, within th= e pre-
=C2=A0 =C2=A0defined DIO options.=C2=A0 Therefore, the security mechan= isms defined in
=C2=A0 =C2=A0RPL [RFC6550] apply to this proposed extension."
I don't think this addresses the purpose of a Security Considerati= ons section.

OK, maybe I misund= erstood 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.
<= div>
I thought that no real extra concerns are present, but a= s you propose, maybe some more details would be helpful.
=C2= =A0
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 b= eyond 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.
=C2=A0
<= div style=3D"color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif= ">
- This could result in introducing a vulnerability: could an attacker = exploit the knowledge gained from learning the PS? =E2=80=A6

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 ca= n "see" further than it's own neighbourhood by one hop, learn= ing the addresses of it's two hop neighbors. So as mentioned, this is a= privacy / network discovery issue.
2. A node that can send D= IOs 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 ca= n 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 definitel= y severely affect the operation of the whole network, just by reporting a f= ake rank.
However, maybe this is not true; I'm not really an = very familiar with the security of RPL.

I don&= #39;t see any other opportunities for security issues.
I will add= these two to the draft unless you have something additional.
=C2=A0
Best regards
Dominique

Thank you very m= uch Dominique for the help.

Best,
Aris
=C2=A0
=

De=C2=A0: Roll <roll-bounces@ietf.org> on= behalf of "Georgios Z. Papadopoulos" <georgios.papadopoulos= @imt-atlantique.fr>
R=C3=A9pondre =C3=A0=C2=A0: "<= a href=3D"mailto:roll@ietf.org" target=3D"_blank">roll@ietf.org" &= lt;roll@ietf.org>=
Date=C2=A0: Monday 10 February 2020= 16:51
=C3=80=C2=A0: "roll@ietf.org" <roll@ietf.org>
Objet=C2=A0: [Roll] Fwd: New Versio= n 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:

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" <nicolas.m= ontavont@imt-atlantique.fr>, "Pascal Thubert" <pthubert@cisco.com>= , "Georgios Papadopoulos" <georgios.papadopoulos@imt-atlantiq= ue.fr>, "Remous-Aris Koutsiamanis" <aris@ariskou.com>


A new version of I-D, draft-ietf-roll-nsa-extension-06.txt
has been successfully submitted by Remous-Aris Koutsiamanis and posted to t= he
IETF repository.

Name: draft-ietf-roll-nsa-extension
Revision: 06
Title: Common Ancestor Objective Function and Parent Set DAG M= etric Container Extension
Document date: 2020-02-10
Group: roll
Pages: 15
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-ro= ll-nsa-extension-06.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools= .ietf.org/html/draft-ietf-roll-nsa-extension-06
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-ex= tension-06

Abstract:
=C2=A0=C2=A0Implementing Packet Replication and Elimination from/to the RPL= root
=C2=A0=C2=A0requires the ability to forward copies of packets over differen= t
=C2=A0=C2=A0paths via different RPL parents.=C2=A0 Selecting the appropriat= e parents
=C2=A0=C2=A0to achieve ultra-low latency and jitter requires information ab= out a
=C2=A0=C2=A0node's parents.=C2=A0 This document details what informatio= n needs to be
=C2=A0=C2=A0transmitted and how it is encoded within RPL control packets to=
=C2=A0=C2=A0enable this functionality.=C2=A0 This document also describes O= bjective
=C2=A0=C2=A0Function which take advantage of this information to implement = multi-
=C2=A0=C2=A0path routing.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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.
--0000000000003d41cb059fabb65c--