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

[Alvaro Retana <[e-mail]>]

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) (
[e-mail]) 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

> -----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