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

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

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 <[e-mail]>
> Sent: lundi 9 novembre 2020 19:57
> To: [e-mail]
> Cc: Peter van der Stok <[e-mail]>; [e-mail];
> Routing Over Low power and Lossy networks <[e-mail]>
> Subject: AD Review of draft-ietf-roll-useofrplinfo-41
> 
> 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