Subject: [6tisch] shepherd review of draft-ietf-6tisch-minimal-security

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Jun 2019 09:54:53 +0000

Dear authors;

As part of shepherding the draft for publication, please find review comments below:

Very well written draft altogether! A few things still:

Section 4.2:

"                 The pledge MAY perform the Neighbor

   Solicitation / Neighbor Advertisement exchange with the JP, as per

   Section 5.5.1 of [RFC6775]<https://tools.ietf.org/html/rfc6775#section-5.5.1>.

"

This reference is outdated. I suggest referring to section 5.6.  of [RFC8505].

Section 6:

Again a ref to RFC 6775. In  a general manner please use RFC 8505.

   "The JRC can be co-located on the 6LBR.  In this special case, the

   IPv6 address of the JRC can be omitted from the Join Response message

   for space optimization.  The 6LBR then MUST set the DODAGID field in

   the RPL DIOs [RFC6550<https://tools.ietf.org/html/rfc6550>] to its IPv6 address.  The pledge learns the

   address of the JRC once joined and upon the reception of the first

   RPL DIO message, and uses it to operate as a JP."

Note that the expectation is that the 6LBR is the RPL root as suggested in the 6TiSCH architecture.
When they are not the same box I expect the all the text about 6LBR throughout this doc is really about the RPL root.
This should be indicated somewhere.

Section 6.1:
There are a number of SHOULD there, but no explanation of what happens if the SHOULD is not respected.
Maybe a sentence that says that the SHOULDs are about protecting the network against the threats discussed in the section and that failing to follow the recommendation may create congestion and more sensitivity to attacks?

Otherwise all good for me!

Pascal

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 13 Jun 2019 14:44:59 +0200

Hello Pascal,

Thanks for the review. See resolutions and some comments inline.

Mališa

> On 12 Jun 2019, at 11:54, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear authors;
>  
> “                 The pledge MAY perform the Neighbor
>    Section 5.5.1 of [RFC6775] <https://tools.ietf.org/html/rfc6775#section-5.5.1>. 
> “
>  

Fixed, see resolution at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/c9bbe0efbe4 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/c9bbe0efbe4>

> Again a ref to RFC 6775. In  a general manner please use RFC 8505.

See above.

>  
>  
>    “The JRC can be co-located on the 6LBR.  In this special case, the
>    the RPL DIOs [RFC6550 <https://tools.ietf.org/html/rfc6550>] to its IPv6 address.  The pledge learns the
>    RPL DIO message, and uses it to operate as a JP.”
>  

In Section 2, there is a sentence stating:

> The term "6LBR" is used interchangeably with the term "DODAG root"
>    defined in [RFC6550 <https://tools.ietf.org/html/rfc6550>], assuming the two entities are co-located, as
>    recommended by [I-D.ietf-6tisch-architecture <https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-10#ref-I-D.ietf-6tisch-architecture>].

IMO this makes it clear that we assume they are the same box but let me know if this is not the case for you.

> Maybe a sentence that says that the SHOULDs are about protecting the network against the threats discussed in the section and that failing to follow the recommendation may create congestion and mor…

You are right, the SHOULDs are poorly elaborated, mostly due to the fact that the attack they protect against is explained beforehand. As suggested, I added a sentence to reference the attack description:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/91830c80f0cc <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/91830c80f0cc> 

I also fixed a couple of nits in the IANA considerations, the commit is at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/673105a5e4 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/673105a5e4>

The overall diff is available at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-11#diff <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-11#diff> 

Let me know if these resolutions work for you and I will publish -11.

Mališa

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Jun 2019 12:59:28 +0000

Works perfectly.

Please publish -11. This is an excellent document, congratulations.

All the best,

Pascal

From: Mališa Vučinić <[email-masked]>
Sent: jeudi 13 juin 2019 14:45
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] shepherd review of draft-ietf-6tisch-minimal-security

Hello Pascal,

Mališa

On 12 Jun 2019, at 11:54, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors;

Section 4.2:

“

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/c9bbe0efbe4

Section 6:

See above.

   defined in [RFC6550<https://tools.ietf.org/html/rfc6550>], assuming the two entities are co-located, as

   recommended by [I-D.ietf-6tisch-architecture<https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-10#ref-I-D.ietf-6tisch-architecture>].

Section 6.1:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/91830c80f0cc

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/673105a5e4

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-11#diff

Mališa