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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: secdir <[e-mail]> On Behalf Of Michael Richardson
> Sent: Sunday, September 6, 2020 10:05 PM
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [secdir] [Roll] Secdir last call review of draft-ietf-roll-turnon-
> rfc8138-12
> 
> 
> Thank you for the review.
> 
> 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.

Got it. A reference to RFC7416 will be helpful to understand the threat model.

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

Please add a reference to the techniques that can be used to detect mis-behaving routers.

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

I think a proprietary way can also be discussed to showcase the current practices for troubleshooting.

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

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

Okay, you may want to expand "subDAG".

-Tiru

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