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

Thanks Pascal, update looks good.

-Tiru

> -----Original Message-----
> From: secdir <secdir-bounces@ietf.org> On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, September 7, 2020 1:52 PM
> To: Michael Richardson <mcr+ietf@sandelman.ca>; Routing Over Low power
> and Lossy networks <roll@ietf.org>
> Cc: draft-ietf-roll-turnon-rfc8138.all@ietf.org; secdir@ietf.org
> Subject: Re: [secdir] [Roll] Secdir last call review of draft-ietf-roll-turnon-
> rfc8138-12
> 
> 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:
> 
> 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 <TirumaleswarReddy_Konda@McAfee.com>
> > 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
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview