Thanks, One item I forgot to include which was also on my mind - a security consideration. If an autonomous bootstrap method like BRSKI is left "always-on" in a mesh network, it means that at any time an off-mesh attacker can contact its nearby Join Proxies and flood them with traffic. E.g. using different LL addresses to pretend it is multiple Pledges. This will cause relayed traffic on the mesh, potentially overloading it.
* One solution component is clearly rate-limiting of relayed traffic. But, this is not even mentioned in the security considerations. And not in 8995 as far as I can tell. * Another solution component is being able (by an admin) to "turn on" and "turn off" the entire option of BRSKI bootstrapping. This could also be mentioned as a security advice: turn it off when not needed i.e. when the operator knows for sure there are no new Pledges to be bootstrapped. The method of "turning on/off" could be implementation-specific as we don't define any APIs for control of Join Proxies. The intended behavior of any Join Proxy is then as follows: 1. If BRSKI is "on", respond to discovery requests by Pledges as usual and do relay any (DTLS) records they may send to the join-port. 2. If BRSKI is "off" , don't respond to discovery requests by Pledges and don't relay any data sent to the join-port. (Effectively, close it.) Some networks may have a "BRSKI always on" policy because it's needed for their application and for convenience, but for a majority of networks I expect that isn't needed. Maybe such practical security related solutions are already described in other documents e.g. 6TiSCH joining or GRASP documents but unfortunately I didn't read enough of those documents to know this. If so we can also refer to it as security consideration. For a mesh network, avoiding an outsider to be able to "load" the mesh links with random data is especially important. Regards Esko -----Original Message----- From: Michael Richardson <m...@sandelman.ca> Sent: Wednesday, September 21, 2022 12:31 To: Esko Dijk <esko.d...@iotconsultancy.nl> Cc: Anima WG <anima@ietf.org>; anima-cha...@ietf.org; stokcons <stokc...@bbhmail.nl> Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022 Okay, thank you. I'll crunch through your comments on Friday. _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
