Subject: [Last-Call] Iotdir last call review of draft-ietf-roll-turnon-rfc8138-09

From: Carles Gomez via Datatracker <[email-masked]>
Date: Wed, 05 Aug 2020 00:26:33 -0700

Reviewer: Carles Gomez
Review result: Ready with Nits

The document is generally clear and well written. No issue was found from a
"6lo" perspective.

Some nits/questions/comments follow:

- Section 2.1, 1st paragraph:  s/The Terminology/The terminology

- Section 2.1, 2nd paragraph, first line: s/"RPL Instance”/and “RPL Instance”

- Section 2.1, 3rd paragraph: s/RPL Aware Leaf/RPL-Aware Leaf

- Section 2.2: note that the use of hyphens in the expanded forms of RAL and
RUL are different from those in draft-ietf-roll-useofrplinfo. (I think the
correct form is the one in the turnon-rfc8138 document, but I guess this will
be confirmed at subsequent stages…)

- Section 3: “A MOP value of 7 and above”. If the MOP is a 3-bit field, the
highest MOP value is 7 (assuming that the lowest value is 0). Why state here
"and above"? Are there plans to extend the MOP field size?

- Section 3, after “A MOP value of 7 and above”. s/MUST use
compression/indicates that compression MUST be used

- Section 4, 1st paragraph: “if and only if the "T" flag is set.” Should we
perhaps append “or if the MOP value is 7.”  ?

- Section 4, 1st paragraph: s/implementations/implementation

- Section 4, 3rd paragraph: What is the "RPL border router"? I couldn't find a
definition in the Terminology section or in other documents...  May the "RPL
border router" and the Root run in the same physical device? May the "RPL
border router" and the Root run in different physical devices?

- Section 4, 3rd paragraph: the last sentence is written only from the “from”
perspective, whereas the previous one is keeps the double "from/to" perspective.

- Section 4, last paragraph, 1st sentence. Please remove the blank space at the
end of the sentence.

- Section 5, 1st paragraph, 2nd sentence. Perhaps prepend the following:
“Without this specification, ”

- Section 7, last sentence. Might this still be exploited as an attack (e.g. to
battery-operated devices) based on depleting energy at a faster rate? If
appropriate, please briefly discuss whether this might be significant or not.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 11:34:32 +0000

Many thanks for your review Carles!

> - Section 2.1, 3rd paragraph: s/RPL Aware Leaf/RPL-Aware Leaf

Done

> RUL are different from those in draft-ietf-roll-useofrplinfo. (I think the correct

> form is the one in the turnon-rfc8138 document, but I guess this will be

> confirmed at subsequent stages…)

See also https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-18

We need to converge and I agree that the hyphened version is correct.

Let us start here 😊

> "and above"? Are there plans to extend the MOP field size?

Yes, there is. See https://tools.ietf.org/html/draft-ietf-roll-mopex-01. This is why. Yet what you are saying makes sense, as written it cannot go beyond 7. I can change to "(and above when extended)"

> compression/indicates that compression MUST be used

The following text

"

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP)

   in the DIO Base Object.  For MOP values 0 to 6, the use of compression is

   as specified in this document.  A MOP value of 7 MUST use compression by

   default and ignore the setting of the “T” flag.

"

was suggested by Alvaro during his A-D review. But I believe that your proposal does not alter the meaning so I'm picking it.

Resulting sentence:

"

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in

   the DIO Base Object.  This specification applies to MOP values 0 to

   6.  For a MOP value of 7 (and above when extended), the compression

   MUST be used by default regardless of the setting of the "T" flag."

> perhaps append “or if the MOP value is 7.”  ?

With the change above, I believe that we are good.

> - Section 4, 1st paragraph: s/implementations/implementation

Done

> border router" and the Root run in different physical devices?

Here we mean by border router the 6LR that serves the external route at the leaf edge.

Proposed Clarification:

"

   An external target [USEofRPLinfo] is not expected to support

   [RFC8138].  In most cases, packets from and to an external target are

   tunneled back and forth between the border router (referred to as

   6LR) that serves the external target and the Root, regardless of the

   MOP used in the RPL DODAG.  The inner packet is typically not

   compressed with [RFC8138], so for outgoing packets, the border router

   just needs to decapsulate the (compressed) outer header and forward

   the (uncompressed) inner packet towards the external target.

"

> perspective, whereas the previous one is keeps the double "from/to"

> perspective.

True

> end of the sentence.

Done

> “Without this specification, ”

Generalizing to any signaling:

"

                                    Enabling the [RFC8138] compression

   without a turn-on signaling requires a "flag day"; all nodes must be

   upgraded, and then the network can be rebooted with the [RFC8138]

   compression turned on.

"

"

> appropriate, please briefly discuss whether this might be significant or not.

Added

"

    An attacker in the middle of the network may reset the "T" flag to cause

    extra energy spending in its subDAG. Conversely it may set the "T" flag, so

    that nodes located downstream would compress when that it is not desired,

    potentially resulting in the loss of packets. In a tree structure, the

    attacker would be in position to drop the packets from and to the attacked

    nodes. So the attacks above would be more complex and more visible than

    simply dropping selected packets. The downstream node may have other

    parents and see both settings, which could raise attention.

"

Does that work?

I pushed the diffs here:

https://github.com/roll-wg/roll-turnon-rfc8138/commit/9f5b90e44c45f2a5003e50cf927c2047ee6fbdbf

Again, many thanks Carles!

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 5 Aug 2020 08:45:56 -0700

Pascal:

Hi!

The MOP currently has a value up to 7…let’s avoid more questions/confusion;
please take the "(and above when extended)” part out.

Thanks!

Alvaro.

> "and above"? Are there plans to extend the MOP field size?

Yes, there is. See https://tools.ietf.org/html/draft-ietf-roll-mopex-01.
This is why. Yet what you are saying makes sense, as written it cannot go
beyond 7. I can change to "(and above when extended)"

The following text

"

"

was suggested by Alvaro during his A-D review. But I believe that your
proposal does not alter the meaning so I'm picking it.

Resulting sentence:

"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 15:56:14 +0000

Cool, will do.
Many thanks Alvaro!

Pascal

Le 5 août 2020 à 17:46, Alvaro Retana <[email-masked]> a écrit :

Pascal:

Hi!

The MOP currently has a value up to 7…let’s avoid more questions/confusion; please take the "(and above when extended)” part out.

Thanks!

Alvaro.

The following text

"

"

Resulting sentence:

"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 16:08:57 +0000

Hello Alvaro and Carles

I published this new change as https://github.com/roll-wg/roll-turnon-rfc8138/commit/945b0aeaa63fb1b9b8320badc9215615bf8055fa
Are we good to publish v10?

Take care,

Pascal

From: Alvaro Retana <[email-masked]>
Sent: mercredi 5 août 2020 17:46
To: [email-masked]; Pascal Thubert (pthubert) <[email-masked]>; Carles Gomez <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Iotdir last call review of draft-ietf-roll-turnon-rfc8138-09

Pascal:

Hi!

Thanks!

Alvaro.

The following text

"

"

Resulting sentence:

"

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 5 Aug 2020 18:18:40 +0200

Hello Pascal,

Thanks for addressing my comments!

Answering to your subsequent email, I believe that the document is now
ready for revision -10.

All the best,

Carles

> --
> Iot-directorate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-directorate
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 16:24:26 +0000

Submitted!

URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-turnon-rfc8138-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-10

Many thanks to both of you 😊

Pascal

> -----Original Message-----
> From: Carles Gomez Montenegro <[email-masked]>
> Sent: mercredi 5 août 2020 18:19
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-roll-
> [email-masked]
> Subject: Re: [Iot-directorate] Iotdir last call review of draft-ietf-roll-turnon-
> rfc8138-09
> 
> Hello Pascal,
> 
> Answering to your subsequent email, I believe that the document is now ready
> for revision -10.
> 
> All the best,
> 
> Carles
> 
> 
> >> - Section 2.1, 2nd paragraph, first line: s/"RPL Instanceâ€/and
> >> â€œRPL Instanceâ€
> >
> >>
> >
> >> confirmed at subsequent stagesâ€¦)
> >
> >
> >
> > Let us start here ðŸ˜Š
> >> - Section 3: â€œA MOP value of 7 and aboveâ€. If the MOP is a 3-bit
> >> field, the
> >
> > This is why. Yet what you are saying makes sense, as written it cannot
> > go beyond 7. I can change to "(and above when extended)"
> >
> >
> >
> >
> >
> >> - Section 3, after â€œA MOP value of 7 and aboveâ€. s/MUST use
> >
> >    default and ignore the setting of the â€œTâ€ flag.
> >
> >
> >
> > "
> >
> > in
> >> - Section 4, 1st paragraph: â€œif and only if the "T" flag is set.â€
> >> Should we
> >
> >> perhaps append â€œor if the MOP value is 7.â€  ?
> >
> >
> >
> >> - Section 4, 3rd paragraph: the last sentence is written only from
> >> the â€œfromâ€
> >
> >> â€œWithout this specification, â€
> >
> >
> >