Giuseppe Piro <[email protected]> wrote: > I'm just thinking to a mechanism that may help JA to authenticate > locally JN. I've called this mechanism "pre-join" scheme. The name > could be not correct at all, let's just try to understand if it could > be useful or not :-)
It would be valuable if the JA had a way to either recognize potentially
legitimate nodes (and prioritize their traffic), or alternately, could find a
way to stop talking to malicious nodes.
> JN sends its certificate to JA ... and other fields that demonstrates
> the posses of the private key associate to the certificate, like the
> sign of the (ASN + Mac address).. or something like that.
So there is a tension between a number of factors:
1) how much work can we insist that a JN do before joining?
(signing the ASN implies freshness, but if can do that, then maybe
you can sign some other challenge that comes from the JCE)
2) how much work can the JA be asked to do in order to validate this pre-join
token?
3) how expensive is bandwidth at various depths of the tree vs computation
power?
4) given that we are going to bandwidth (energy-limit) the joining process,
how long does the process take even in the absense of attackers?
This problem is very much like what the IPSECME WG has been discussing
in http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/
An attacker are able to leverage significant amounts of computational power
From a relative point of view, and usually has an unlimited power budget.
That's why I felt that the JA should do as little as possible (and have as
little custom code for the join processing: i.e. reuse existing mechanisms).
That the join process should be driven/managed by the JCE as it potentially
has resources similar to the attacker.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
