Re: [Roll] Border router failure detection

[Konrad Iwanicki <[e-mail]>]

Hi Michael,

Below, you can find my replies to your detailed comments, which I 
promised in my previous e-mail.

> It seems that you might want a term for the LBR's children.
> That is, the devices at rank "1", that hear the LBR's DIOs.

That would be useful. However, I am really bad at inventing names. Any 
ideas for a fitting one-word term?

Also, if you have better names for the two node roles, they may be worth 
considering because I am not perfectly satisfied with "sentinel" and 
"acceptor".

> I think that I would move some of section 3.2 further forward in the
> document.  I think that I need a gentler introduction to CFRCs here, and I
> don't really need to know the properties, rather I need a higher-level idea
> of things.    Since section 4 goes over the operations again, I would leave
> it for that spot, and make it a section 4.1.

True. Will do that.

> Having gone forward and back a bit, I'm still a bit uncertain how nodes
> assign themselves a bit... oh, self() in section 4 says "random".
> Why not make this a function (hash?) of the short-IPv6 address or something?

Hash could work. However, the choice of the random function allows a 
node to become sentinel, then give up, then become sentinel again, and 
so on, possibly multiple times. Having a hash based on the short-IPv6 
address would allow for only one such transition, unless for instance 
the node kept an additional counter that was hashed together with the 
address.

> Not every media has ACK frames at the L2 to establish that there are
> failures.  It might be worth putting the Detecting and the Verifying into
> separate sections.  Aside from the ANIMA case (which is usually pure ethernet),
> there are also situations where there is an ethernet backbone connecting a
> few 6LBRs (RFC8929), and your protocol would sensibly run on both the
> wireless and the wired side of the 6LBRs.

Indeed, RNFD can work with other link layers. L2 ACKs are only given as 
an example of an event that can be relevant to RNFD. In link-layers 
without ACKs, results from probing or other relevant events can be used 
(e.g., medium disconnection event). I tried to keep the example list 
brief, but perhaps more examples could be given for other underlying 
technologies?

Likewise, I was actually considering separating detection from 
verification but they are related as the same mechanisms can be used for 
both purposes. Therefore, ultimately they ended up in a single section.

> I also wonder if the RNFD could be included in DAOs (particularly storing
> mode ones) sent to the DODAG root.
> I know that probably seems senseless: why tell the root that you are
> observing it to be dying....  But, it acts as interesting telemetry about
> what the nodes are seeing, and might serve as a useful indication of imminent
> failure, or some kind of systematic long-cycle pathology.

Actually, the RNFD Option can be embedded into any control/data messages 
for which the DODAG ID and DODAG Version can be inferred unambiguously. 
In particular, in multi-hop messages, the option could even be updated 
and acted upon at each hop, which would speed up information 
propagation. The draft focuses on DIOs and DISs as they are basic 
messages that are exchanged irrespective of the current DODAG condition 
and existence of particular paths. Do you think this should be mentioned 
somewhere?

BTW. The root, if alive, sees that it is being observed and what the 
outcome of this observation is based on its local CFRCs.

> Your IANA considerations are how the document will look after IANA has
> processed it.  Prior to that point, you need to write it as a request.
>
> Something like:
>
>    IANA is requested to allocate the value TBD1 from the "RPL Control Message
>    Options" sub-registry of the "Routing Protocol for Low Power and Lossy
>    Networks (RPL)" registry.
>
> I like to include the URL of the registry in my request to be really really
> clear, and to save everyone else the time to find it.

Thanks, I did not know how to formulate this. I will correct the section.

> Your security considerations will want to cite RFC7416.
> In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant.

Thanks for the pointer. I was not aware that such a RPL-oriented 
document exists. Gathering all major threats and possible 
counter-measures, which would otherwise had to be picked from various 
works in the literature, it seems extremely valuable for prospective 
RPL's adopters.

As to the particular sections you mentioned, RNFD essentially relies of 
DIO and DIS messages. Since these messages are broadcast, sinkhole 
attacks (7.3.4) are of limited threat (to the RNFD itself): for any two 
nodes, if there exists any path in the network (comprising L2-induced 
communication links and non-compromised nodes), then eventually CFRCs 
from one of the nodes will reach (indirectly, through merging) the other 
node, irrespective of the sinkholes that may attract routed L3 traffic. 
Wormhole attacks (7.3.5) in turn would speed up the propagation of CFRC 
updates, so they actually can help RNFD.

Therefore, in my view, the major threats are indeed those already 
mentioned in the draft, which are referred to as 
overclaiming/misclaiming in the RFC you pointed at (7.2.4). Looking 
again at the security section of the RNFD draft, I am leaning toward 
expanding it a bit. In any case, an advantage of RNFD is that its 
construction allows for detecting such attacks to some extent and 
disabling the algorithm if necessary (though under such attacks, RPL 
would likely have more problems on its own).

The preferred means of disabling and enabling the algorithm at runtime 
is actually one of the issues I would like to discuss with the WG but 
probably after I have addressed all other issues that you and Pascal 
have raised (I think Pascal's last e-mail is next).

Best regards,
-- 
- Konrad Iwanicki.