Subject: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41

From: Alvaro Retana <[email-masked]>
Date: Mon, 9 Nov 2020 10:57:08 -0800

Dear authors:

Thank you for all the work on this draft.

I have a couple of comments in-line -- nothing hard to address.  I
mostly looked at the diffs (wrt -31) and so my comments are just on
new text.

I want to progress this draft with unaware-leaves -- to make it easier
on the IESG.  I'll start the IETF LC when both are ready.

Thanks!

Alvaro.

>From idnits:

  ** The abstract seems to contain references ([RFC8138]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

[Line numbers from idnits.]

...
66	   4.  Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . .   7
67	     4.1.  Updates to RFC6550: Advertising External Routes with Non-
68	           Storing Mode Signaling. . . . . . . . . . . . . . . . . .   7
69	     4.2.  Updates to RFC6553: Indicating the new RPI Option Type. .   8
70	     4.3.  Updates to RFC6550:
71	           Configuration Options and Mode
72	           of Operation  . . . . . . . . . . . . . . . . . . . . . .  11
73	     4.4.  Updates to RFC6550: Indicating the new RPI in the
74	           DODAG Configuration option Flag.  . . . . . . . . . . . .  12
75	     4.5.  Updates to RFC8138: Indicating the way to decompress with
76	           the new RPI Option Type.  . . . . . . . . . . . . . . . .  13

[nit - no action needed, just a suggestion] Group all the updates to
rfc6550: either in one sub-section or in consecutive ones.

...
493	4.3.  Updates to RFC6550: Configuration Options and Mode of Operation

495	   RFC6550 section 6.7.6 describes the DODAG Configuration Option.  In
496	   this option are a series of Flags in the first octet of the payload.
497	   These flags are described by the DODAG Configuration Option Flags
498	   registry [dodagcfg], in section 20.14 of RFC6550.

500	   Anticipating future work to revise RPL relating to how the LLN and
501	   DODAG is configured, this document changes the interpretation of the
502	   [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
503	   specific.  The MOP is described in [RFC6550] section 6.3.1.  The
504	   Options Flags Registry is renamed, and applies to MOP values zero (0)
505	   to six (6) only, leaving the flags reserved for MOP value seven (7).

507	   In addition, this document reserves MOP value 7 for future expansion.

[] NEW>
   Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as
   containing a series of Flags in the first octet of the payload.

   Anticipating future work to revise RPL relating to how the LLN and DODAG
   are configured, this document renames the DODAG Configuration Option
   Flags registry so that it applies to Mode of Operation (MOP) values zero
   (0) to six (6) only, leaving the flags unassigned for MOP value seven
   (7).  The MOP is described in [RFC6550] section 6.3.1.

   In addition, this document reserves MOP value 7 for future expansion.

   See Sections 11.2 and 11.3.

509	4.4.  Updates to RFC6550: Indicating the new RPI in the DODAG
510	      Configuration option Flag.
...
529	   For a MOP value of 7 or above, the flag MAY indicate something
530	   different and MUST NOT be interpreted as "RPI 0x23 enable" unless the
531	   specification of the MOP indicates to do so.  For a MOP value of 7, a
532	   node SHOULD assume that the RPI 0x23 option is enabled.

[major] The text in §4.3 says that the flags for MOP 7 are reserved
(I'm suggesting unassigned -- but that makes no difference in the
context of this comment), but this text seems to want to pre-define
what to do with the reserved/unassigned flags.  Please take the first
sentence out; then MOP 7 is defined it can figure out what to do with
the flags.

[major] How do you normatively enforce "SHOULD assume"?  When is it ok
to not do so?  IOW, why use SHOULD and not MUST?

Suggestion>
   For a MOP value of 7, a node MUST use the RPI 0x23 option is.

...
691	6.  Use cases
...
821	      - In the uses cases, we dont assume that the RUL supports IP-in-IP
822	      encapsulation.

[nit] s/dont/don't

...
993	7.1.3.  SM: Example of Flow from Root to RUL
...
1033	   IP-in-IP encapsulation MAY be avoided for Root to RUL communication.
1034	   In SM, it can be replaced by a loose RH3 header that indicates the
1035	   RUL, in which case the packet is routed to the 6LR as a normal SM
1036	   operation, then the 6LR forwards to the RUL based on the RH3, and the
1037	   RUL ignores both the consumed RH3 and the RPI, as in Non-Storing
1038	   Mode.

[major] s/encapsulation MAY be avoided/encapsulation may be avoided
Not a Normative statement, just a fact.

...
2378	11.2.  Changes to DODAG Configuration Options Flags

[nit] s/.../Change to the DODAG Configuration Options Flags registry

2380	   This document changes the name of the "DODAG Configuration Option
2381	   Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6".

[] NEW>

   This document requests IANA to change the name of the "DODAG
   Configuration Option Flags" registry to "DODAG Configuration Option Flags
   for MOP 0..6".

2383	11.3.  Change MOP value 7 to Reserved

2385	   This document changes the allocation status of the Mode of Operation
2386	   (MOP) [ianamop] from Unassigned to Reserved.  This change is in
2387	   support of future work related to capabilities.

[] NEW>
   This document requests the changing the registration status of value 7 in
   the Mode of Operation registry from Unassigned to Reserved.  This change
   is in support of future work.

...
2564	14.1.  Normative References
...
2571	   [dodagcfg]
2572	              IANA, "DODAG Configuration Option Flags", Sept 2020,
2573	              <https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-
2574	              config-option-flags>.

2576	   [ianamop]  IANA, "Mode Of Operation", Sept 2020,
2577	              <https://www.iana.org/assignments/rpl/rpl.xhtml#mop>.

[minor] These references are not needed.

...
2636	   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
2637	              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
2638	              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[minor] This reference can be Informative.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2020 12:51:29 +0000

Hello Alvaro and all

Just to point out that during Alvaro's review of unaware leaves, we also mentioned the security aspect of injecting an RPI.

There are 3 cases:
- the leaf is an external router that passes a packet that it did not generate and that carries an unrelated RPI - we need to rewrite it
- the leaf is an attacker that tries to inject traffic in a protected instance - we need to rewrite out or drop
- the leaf is aware of the RPL instance and passes a correct RPI - to make the difference, the 6LR needs a configuration that allows that leaf to inject in that instance.

This is why we ended up SHOULDing the rewrite. Do we need more text like the aboce in the security section?

Keep safe;

Pascal

> -----Original Message-----
> From: Alvaro Retana <[email-masked]>
> Sent: lundi 9 novembre 2020 19:57
> To: [email-masked]
> Cc: Peter van der Stok <[email-masked]>; [email-masked];
> Routing Over Low power and Lossy networks <[email-masked]>
> Subject: AD Review of draft-ietf-roll-useofrplinfo-41
> 
> Dear authors:
> 
> I have a couple of comments in-line -- nothing hard to address.  I mostly
> looked at the diffs (wrt -31) and so my comments are just on new text.
> 
> I want to progress this draft with unaware-leaves -- to make it easier on the
> IESG.  I'll start the IETF LC when both are ready.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> >From idnits:
> 
>    containing a series of Flags in the first octet of the payload

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 10 Nov 2020 08:38:57 -0800

Just a quick note:  the second case can also be due to a misconfiguration,
or maybe even old Instance ID at the RUL.  IOW, the general case of the
instant not existing is not always due to an attack.

Thanks!

Alvaro.

On November 10, 2020 at 7:51:46 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Hello Alvaro and all

Just to point out that during Alvaro's review of unaware leaves, we also
mentioned the security aspect of injecting an RPI.

There are 3 cases:
- the leaf is an external router that passes a packet that it did not
generate and that carries an unrelated RPI - we need to rewrite it
- the leaf is an attacker that tries to inject traffic in a protected
instance - we need to rewrite out or drop
- the leaf is aware of the RPL instance and passes a correct RPI - to make
the difference, the 6LR needs a configuration that allows that leaf to
inject in that instance.

This is why we ended up SHOULDing the rewrite. Do we need more text like
the aboce in the security section?

Keep safe;

Pascal

---

From: Ines Robles <[email-masked]>
Date: Thu, 12 Nov 2020 00:09:56 +0200

Hi Alvaro,

Many thanks for your review. We addressed your comments on version 42 (
https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-42.txt
)
Should be do a manual post request or wait until 14th Nov?

Thank you again,

Ines.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 18:18:37 -0500

> context of this comment), but this text seems to want to pre-define

I believe that we got advice from IANA that RESERVED was the right state.
It could be changed by an IESG action, such as publishing an IETF Consensus RFC.

Unassigned, in theory, leaves IANA free to allocate it to the next document
that asks for a MOP value. Of course, in practice, it would come back to the
WG, Expert Review, etc. but...

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 11 Nov 2020 17:34:31 -0800

Ines:

Hi!

Let’s request the manual post so I can start the IETF LC.

Thanks!

Alvaro.

On November 11, 2020 at 5:10:33 PM, Ines Robles (
[email-masked]) wrote:

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 11 Nov 2020 17:35:12 -0800

Either way works...

On November 11, 2020 at 6:19:11 PM, Michael Richardson (
[email-masked]) wrote:

I believe that we got advice from IANA that RESERVED was the right state.
It could be changed by an IESG action, such as publishing an IETF Consensus
RFC.

Unassigned, in theory, leaves IANA free to allocate it to the next document
that asks for a MOP value. Of course, in practice, it would come back to
the
WG, Expert Review, etc. but...

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll