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 ---
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.
Does it make sense ? What do you think ? How do you suggest to handle
this aspect ? Probably I did not understand well what you have in
mind... so, please, clarify this aspect.
All the best,
Giuseppe
On Fri, Sep 11, 2015 at 1:05 PM, Malisa Vucinic <[email protected]> wrote:
> It seems that this would trigger the exchange of:
>
> (1) 6 packets between JN and JA,
> (2) 4 packets between JA and JCE on a multi hop path.
>
> Communication of (1) happens in the shared slot so collisions are likely.
> Communication of (2) happens over multiple hops so it affects the network.
>
> I am skeptical how this would look like in terms of delay for the initial
> formation of a large network and in your example bellow JA learns that JN is
> valid only in step (6) at the end of the exchange, when 4 packets have
> already traversed the whole network. In that sense, I don’t see any benefit
> from JA there, except that we can get rid of one packet, EAP identity
> request… Am I missing something?
>
> What do we loose in terms of security if JN simply uses its PSK to generate
> a MAC protected COSE object that can fit in one radio frame that JA forwards
> to JCE? We said that we can protect from replay either using ASN or a
> monotonic counter local to JN. In that case, it would suffice that JCE
> verifies the object and creates a new one that JN can accept, encapsulating
> whatever domain-specific keys are necessary…
>
> This would result in:
>
> (1) 2 packets between JN and JA,
> (2) 2 packets between JA and JCE on a multi hop path.
>
> This roughly reduces the latency by a factor of 3 for the most critical
> stochastic part, and by a factor of 2 for the deterministic part…
> I realize that we are not doing challenge-response there but I am not clear
> what do we really loose since JCE takes care of replay protection from a
> rogue JN, and JN can make sure that it does not use the PSK with the same IV
> more than once?
--
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email protected]
phone: +39 080 5963301
web: giuseppepiro.com
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
