Re: [secdir] [Roll] Secdir last call review of draft-ietf-roll-turnon-rfc8138-12

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

Hello Tiru and Michael:

Many thanks for your time, your review and your help.

Let's explore how we can improve the text to reduce the reader's puzzlements.


> 
> Konda, Tirumaleswar Reddy <[e-mail]>
> wrote:
>     > [1] You may want to clarify how the attacker manages to modify a
>     > protected configuration including the "T" flag introduced in this
>     > spec.
> 
> Every router within every routing protocol can do wrong things :-) RPL is an
> IGP, so all routers are within the same security control, and at the same level.
> 
> An attacker would have to introduce malware into the device to modify data.
> RFC7416 lays out all of these threats: they are no different for the T-bit than
> other bits.
> 

Good point, I will add an informative ref to RFC7416:
"
   It is worth noting that in RPL [RFC6550], every node in the LLN that
   is RPL-aware and has access to the RPL domain can inject any RPL-
   based attack in the network, more in [RFC7416].  

"


>     > [2] Is it possible to identify the attacker (or compromised router) who
>     > set the "T" flag to remediation measures ?
> 
> Maybe. Probably not.
> There are few things we can do within any routing protocol to identify mis-
> behaving routers.

And during a transition there will be parents that advertise a different setting. 
As Michael said, this is true for any other information as well, so the art of debunking applies.

>     > [3] If due to an human error one or more of the on-path routers are not
>     > upgraded or if the router sees both settings, I presume an alert could
>     > be sent to the network management for troubleshooting. You may want to
>     > add text to discuss the same.
> 
> At present, RPL does not include a standard off-path alerting mechanism.
> This remains a todo item for the WG.
> Some use NETCONF or HTTP to collect statistics in a proprietary way.
> We can send ICMPs, but since the affects how the packets are encoded, we
> likely can't send an ICMP to a relevant router, just one hop in the direction it
> came from.

Agreed. In addition, I would not add code in a constrained router to detect this mistake, though. 
Either you know your network (through management) and you can do the live upgrade, or, for a small network you do the flag day alternative and check everything is back up.



> 
>     > [4] What do you mean by "subDAG" (I don't see any definition in this spec
> and RFC8138) ?
> 
> It's a sub-portion of a DAG. A sub-tree.

I made a small clarifying change:
"
   An attacker in the middle of the network may reset the "T" flag to
   cause extra energy spending in the subset of the DODAG formed by its
   descendants (its subDAG).
"

The diffs are visible here: https://github.com/roll-wg/roll-turnon-rfc8138/commit/889faccec19038b2b68685bb0e31e9cb91d4da62

Again, many thanks!

Please let us know if you see we need to do more.

Keep safe

Pascal