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

[Remous-Aris Koutsiamanis <[e-mail]>]

Thanks!

I'll go through it an use it.

Best,
Aris

On Tue, Mar 3, 2020 at 3:13 PM <[e-mail]> wrote:

> Hello Aris,
>
> Here is a pointer to an IETF tutorial on writing Security Considerations
> section.
>
> https://datatracker.ietf.org/meeting/105/materials/slides-105-edu-sessb-writing-security-considerations-01.pdf
>
> https://www.youtube.com/watch?v=Jpbfy3QeerU
> See for example slide 23 that pertains to drafts extending prior protocols.
> I'll review and respond to your comments below later.
> Cheers,
>
> Dominique
>
> De : Remous-Aris Koutsiamanis <[e-mail]>
> Date : Saturday 29 February 2020 01:05
> À : Dominique Barthel <[e-mail]>
> Cc : "[e-mail]" <[e-mail]>, "Georgios Z. Papadopoulos" <
> [e-mail]>
> Objet : Re: [Roll] Fwd: New Version Notification for
> draft-ietf-roll-nsa-extension-06.txt
>
> Hello Dominique,
>
> thank you very much for the thorough review.
> Comments inline.
>
> On Wed, Feb 26, 2020 at 12:15 PM <[e-mail]> 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.
>
> Best,
> Aris
>
>
>>
>> De : Roll <[e-mail]> on behalf of "Georgios Z.
>> Papadopoulos" <[e-mail]>
>> Répondre à : "[e-mail]" <[e-mail]>
>> Date : Monday 10 February 2020 16:51
>> À : "[e-mail]" <[e-mail]>
>> 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: *[e-mail]
>> *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" <[e-mail]>, "Pascal
>> Thubert" <[e-mail]>, "Georgios Papadopoulos" <
>> [e-mail]>, "Remous-Aris Koutsiamanis" <
>> [e-mail]>
>>
>>
>> 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=draft-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 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.
>>
>> _________________________________________________________________________________________________________________________
>
> 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.
>
>