> On 11 Sep 2015, at 14:28, Giuseppe Piro <[email protected]> wrote: > > Hello Malisa, > > The traffic load generated during the join process could be an > important aspect to consider. Thanks for the mail. > > However, if you use only PSK + COSE, you are imposing that a message > received by the JA must be forwarded towards the JCE. Is the network > vulnerable against DoS and DDoS attacks (same comment discussed during > the last phone conf) ? > > Please, have a look to the following examples. > > > If you have a legitimate JN, the exchange of messages is simple: > > legitimate JN ---(1)--> JA ---(2)--> X ---(2) --> JCE > > legitimate JN <---(4)-- JA <---(3)-- X <---(3) -- JCE > > where > X is a generic intermediate node (we have a multihop network) > (1) join request message containing COSE object and processed at the > MAC layer through K1 > (2) join request message forwarded by JA or intermediate node X > towards JCE. It can be protected at the MAC layer through network-wide > keys or unicast layer-2 keys. > (3) join response message forwarded by JCE or intermediate node X > towards JN. It can be protected at the MAC layer through network-wide > keys or unicast layer-2 keys. It contains network-wide keys or any > other key materials (in a COSE object, I guess) > (4) join response message sent by JA to JN. It is processed at the mac > layer through K1. It contains network-wide keys or any other key > materials (in a COSE object, I guess) > > > If you have a malicious JN (or more malicious JNs), the exchange of > messages could be: > > malicious JN ---(1)--> JA ---(2)--> X ---(2) --> JCE > > malicious JN JA <---(3)-- X <---(3) -- JCE > > where > (1) malicious join request message containing malicious COSE object > and processed at the MAC layer through K1 > (2) malicious join request message forwarded by JA or intermediate > node X towards JCE. It can be protected at the MAC layer through > network-wide keys or unicast layer-2 keys. > > --- in the middle time JCE verifies that the request is not legitimate > and stores somethings in its database and announces this to the JA --- > > (3) join response message forwarded by JCE to _only_ JA. It can be > protected at the MAC layer through network-wide keys or unicast > layer-2 keys. IMPORTANT: It contains details about the fail of the > join process. > > -- details stored in (3) are used by JA for avoid to accept any other > packets from that malicious JN —
Malicious JN can always change its address for the new request and there’s nothing in (3) that can prevent this. More importantly, there is nothing we can do about that - it will no matter what result in DoS as JA will be unavailable to handle requests from legitimate JNs. Tero detailed on this in one of his previous emails. The question is whether we will exchange 1 packet between JA and JCE or 4. This exchange *has* to end up at JCE as JA does not have any means to authenticate JN at that point. We are talking about the case where each JN has a different PSK imprinted, and only JCE knows the corresponding address/PSK binding. Intermediate nodes, i.e. JAs do *not* know the key of JN and thus cannot authenticate it… > Now, what happens if you have many malicious JNs ? What happens if JS > moves and try to join from different JAs ? Therefore, PSK +COSE > reduces the number of messages... but makes the network vulnerable > against DoS and DDoS. See above, I think you are assuming that JA can authenticate JN by some means. This may not be possible even with certificates as JN and JA may not share the CA when they first join. Imagine two devices from two different manufacturers, each one has a certificate signed with manufacturer’s CA. How will JA verify the certificate issued by JN’s CA that it has never heard of… Even if devices share the common CA, JA would need to communicate with JCE for every JN in order to decide if node XYZ should be allowed to join the network, and then you have a similar problem of DoS as above. Note that although JN is authenticated, it is not yet authorized to join. JA is just one of the nodes in the network, it cannot decide which devices should be allowed to join and which shouldn’t. JCE will likely have an ACL with all the nodes it physically owns but you cannot expect each potential JA in the network to have the same list… Once JCE admits JN to the network, it shares with it some locally significant material, like a new certificate from network’s CA or a symmetric key. This locally-significant material can be an input for the following phases and just then we can assume that JN, JA and other JN’s radio neighbors can mutually authenticate themselves, derive keys, negotiate keys, etc... Does that make sense? Mališa _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
