Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

[Ines Robles <[e-mail]>]

Hi Pascal,

I agree with your suggestions, thank you very much for your fast response.

I mentioned sybil attack just an example of a possible threat, just
thinking, e.g. In a sybil attack, a malicious node might utilizes uses
several RPL Instances to compromise the whole network. (I might be wrong).

Anyway, I agree to stick with the security modes that you proposed.

Have a great weekend and thanks,

Ines.



On Fri, Apr 17, 2020 at 7:13 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Dear Ines
>
> Many thanks for your comments and for shepherding this document!
>
> Please see below:
>
> > Since the document includes double RPL Instance scenario. Do you think
> that security considerations should mention what security aspects involve
> RPL multi-instance operation (e.g. sybil attacks, etc.)?. Maybe it would be
> worthy to reminder that the security modes preinstalled or authenticated is
> applicable also on multi-instances scenarios.?
>
> I'm unclear how sybil attacks would play there, please help me out if you
> think that there's a relevant case here beyond the security mode
> discussion. For that I suggest to add:
> "
>    The 2 instances MUST be operated with the same security guarantees,
>    e.g., both "unsecured" with a lower layer security of a same
>    strength, both "preinstalled" or both "authenticated" security mode
>    (see section 3.2.3 of [RFC6550] for more details on those modes).
>    The latter mode could be use to enforce the segregation of updated
>    and non-updated nodes, by providing the keys for joining as routers
>    to the updated nodes only.
> "
>
>
> > Nits: The abstract does not mention explicitly that this draft updates
> RFC6550 and RFC8138. It would be nice to state that on the abstract.
>
> Yes, what about:
> "
>    This document updates RFC 8138 and RFC 6550 by defining a bit in the
>    RPL configuration option to indicate whether RFC 8138 compression is
>    used within the RPL Instance, and specify the behavior of RFC
>    8138-capable nodes when the bit is set and reset.
>
> "
>
> Will that work? I'll publish as soon you give me your green light.
>
>
> Many thanks again... keep safe and take care;
>
>
> Pascal
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/shepherdwriteup/
>
> On Fri, Apr 17, 2020 at 5:38 PM <mailto:[e-mail]>
> wrote:
> Hello all,
>
> The WGLC for draft-ietf-roll-turnon-rfc8138 has been open since Feb 20th.
> Since then, the draft has received reviews from Rahul and myself, which
> lead the authors to publish –05 and –06.
> We believe all the actionable comments have been addressed.
> Therefore, the WGLC is now officially closed.
> Inès has kindly volunteered to be the shepherd for this draft, and is
> going to do her write-up before we release the document to our AD.
> Thanks to her for taking up that role, and thanks to all of you for your
> contributions!
>
> Dominique & Ines & Michael
>
> De : Roll <mailto:[e-mail]> on behalf of Dominique Barthel
> <mailto:[e-mail]>
> Répondre à : "mailto:[e-mail]" <mailto:[e-mail]>
> Date : Friday 6 March 2020 12:08
> À : "mailto:[e-mail]" <mailto:[e-mail]>
> Cc : "mailto:[e-mail]" <mailto:
> [e-mail]>
> Objet : Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04
>
> Working Group,
>
> The WGLC for draft-ietf-roll-turnon-rfc8138-04 was due to expire yesterday.
> No comment was received so far.
> Before we equate silence with agreement, please take some time to reflect
> on this draft, maybe even review it and most importantly send your thoughts.
> Simple responses like "yes", "I approve it" are valid, too.
> As chairs, we need to gauge consensus. Please help us serving the
> community.
> Best regards
>
> Inès & Dominique
>
> De : "mailto:[e-mail]" <mailto:
> [e-mail]>
> Date : Thursday 20 February 2020 10:16
> À : "mailto:[e-mail]" <mailto:[e-mail]>
> Cc : Dominique Barthel <mailto:[e-mail]>
> Objet : WGLC on draft-ietf-roll-turnon-rfc8138-04
>
> Dear all,
>
> This is a Working Group Last call for draft-ietf-roll-turnon-rfc8138-04
>
> Please send your comments by 5th March 2020
>
> Thank you very much in advance,
>
> Ines and Dominique.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>