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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 5 Sep 2020 10:43:48 +0000

Reviewer: Tirumaleswar Reddy
Review result: Ready with nits

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Ready with nits

[1] You may want to clarify how the attacker manages to modify a protected configuration including the "T" flag introduced in this spec.
[2] Is it possible to identify the attacker (or compromised router) who set the "T" flag to remediation measures ?
[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.
[4] What do you mean by "subDAG" (I don't see any definition in this spec and RFC8138) ?

Cheers,
-Tiru

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Sep 2020 12:34:52 -0400

Thank you for the review.

Konda, Tirumaleswar Reddy <[email-masked]> 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.

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

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

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

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 7 Sep 2020 06:24:17 +0000

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

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

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

> likely can't send an ICMP to a relevant router, just one hop in the direction it
> came from.

> It's a sub-portion of a DAG. A sub-tree.

Okay, you may want to expand "subDAG".

-Tiru

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Sep 2020 08:21:36 +0000

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.

> RFC7416 lays out all of these threats: they are no different for the T-bit than

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

"

> There are few things we can do within any routing protocol to identify mis-

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.

> likely can't send an ICMP to a relevant router, just one hop in the direction it

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.

> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 9 Sep 2020 07:22:09 +0000

Thanks Pascal, update looks good.

-Tiru

> From: secdir <[email-masked]> On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, September 7, 2020 1:52 PM
> To: Michael Richardson <[email-masked]>; Routing Over Low power
> and Lossy networks <[email-masked]>
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hello Tiru and Michael:
> 
> > 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.
> >
> > RFC7416 lays out all of these threats: they are no different for the
> > T-bit than other bits.
> >
> 
> > mis- behaving routers.
> > 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.
> 
> 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.
> 
> 
> 
> >
> The diffs are visible here: https://github.com/roll-wg/roll-turnon-
> rfc8138/commit/889faccec19038b2b68685bb0e31e9cb91d4da62
> 
> Again, many thanks!
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview