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

[[e-mail]]

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]<mailto:[e-mail]>>
Date : Saturday 29 February 2020 01:05
À : Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Georgios Z. Papadopoulos" <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> on behalf of "Georgios Z. Papadopoulos" <[e-mail]<mailto:[e-mail]>>
Répondre à : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date : Monday 10 February 2020 16:51
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>, "Pascal Thubert" <[e-mail]<mailto:[e-mail]>>, "Georgios Papadopoulos" <[e-mail]<mailto:[e-mail]>>, "Remous-Aris Koutsiamanis" <[e-mail]<mailto:[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<http://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.