Subject: [6tisch-security] Fwd: question on draft-kumar-dice-dtls-relay-01

From: Rene Struik <[email-masked]>
Date: Tue, 27 May 2014 17:05:27 -0400

Of potential interest to 6TiSCH security people as well.

-------- Original Message --------
Subject: 	question on draft-kumar-dice-dtls-relay-01
Date: 	Tue, 27 May 2014 16:55:12 -0400
From: 	Rene Struik <[email-masked]>
To: 	[email-masked] <[email-masked]>

Dear Sandeep, Oscar, Sye Loong:

I read draft-kumar-dice-dtls-relay-01 a few days ago. In the security
considerations section of that draft, you allude to potential denial of
services attacks in the context where a one-hop neighbor of a joining
node facilitates messaging between that joining node and the network
manager potentially many hops away, where the joining node and the
network manager act as DTLS Client and DTLS Server, respectively, and
where the one-hop neighbor acts as DTLS Relay. You also suggest some
measures to thwart/limit denial of service attack risk.

I would be curious as to whether you could provide some more insight as
to what type of denial of service attack you counter and how the DTLS
Relay "on/off switch" would work in practice. How would one detect a
potential DoS attack and turn on the "DTLS Relay on/off" knobs to
counter an influx of bogus join protocol messages that could be
amplified if this would travel to the network manager (in a scenario
where both are many hops away from each other)? Since with DTLS, client
authentication only happens in the third protocol flow, it seems that by
necessity one has to allow three subsequent message flows (key
establishment messages from client to server and back, key confirmation
message from client to server), without the DTLS Relay element having a
mechanism (except for throttling) to cryptographically arbitrage these
flows.

When does the newbee device get configuration info and, e.g., a routable
address assigned?

If you could expand on this scenario, that would be great.

Best regards, Rene

[excerpt from draft-kumar-dice-dtls-relay-01]
5. Security Considerations
Additional security considerations need to be taken into account about
forwarding of messages from devices through a network to which it has
not yet been admitted. This can lead to denial-of-service attacks or
misuse of network resources without proper authentication. One way to
overcome any large scale misuse of the network is to have a management
message from the Controller that initiates already authenticated devices
in the network to enter into a DTLS Relay mode. The devices can stay
such a Relay mode for a fixed period of time or until the Controller
sends a new management message blocking the DTLS Relay mode in all
devices in the network. This is often possible since the administrator
of the network can be aware when new devices join the network either
because of the "Introduction" phase or commissioning phase. Other
mechanisms based on IP destination filtering can be applied by the
controller to all Relay nodes to avoid misuse of the network resources.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363