Re: [Iot-directorate] Iotdir last call review of draft-ietf-roll-turnon-rfc8138-09

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
> Sent: mercredi 5 août 2020 18:19
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-roll-
> [e-mail]
> Subject: Re: [Iot-directorate] Iotdir last call review of draft-ietf-roll-turnon-
> rfc8138-09
> 
> 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
> 
> 
> > Many thanks for your review Carles!
> >
> >
> >
> > Please see below:
> >
> >
> >
> >> 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
> >
> >
> >
> > Done
> >
> >
> >
> >>
> >
> >> - 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…)
> >
> >
> >
> > 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 😊
> >
> >
> >
> >
> >
> >> - 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?
> >
> >
> >
> > 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)"
> >
> >
> >
> >
> >
> >> - Section 3, after “A MOP value of 7 and above”. s/MUST use
> >
> >> 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."
> >
> >
> >
> >
> >
> >> - Section 4, 1st paragraph: “if and only if the "T" flag is set.”
> >> Should we
> >
> >> 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
> >
> >
> >
> >> - 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?
> >
> >
> >
> > 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.
> >
> > "
> >
> >
> >
> >
> >
> >> - 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.
> >
> >
> >
> > True
> >
> >
> >
> >>
> >
> >> - Section 4, last paragraph, 1st sentence. Please remove the blank
> >> space at the
> >
> >> end of the sentence.
> >
> >
> >
> > Done
> >
> >
> >
> >>
> >
> >> - Section 5, 1st paragraph, 2nd sentence. Perhaps prepend the
> >> following:
> >
> >> “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.
> >
> > "
> >
> >
> >
> >
> >
> > "
> >
> >>
> >
> >> - 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.
> >
> >
> >
> > 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/9f5b90e44c45f2a5
> > 003e50cf927c2047ee6fbdbf
> >
> >
> >
> > Again, many thanks Carles!
> >
> >
> >
> > Pascal
> > --
> > Iot-directorate mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/iot-directorate
> >
>