Hi Rene

The security considerations section is not completely baked yet. But to answer your questions, we were considering the following two threats:
- DoS where a large number of joining messages are sent by  rogue nodes either to flood the lowpan or drain the network manager
- misuse of the relay functionality to allow a rogue node to setup a DTLS session with a server which is not the network manager

The "on/off switch" is just one option for the DoS where the network manager can detect too many failed requests and issue a multicast management message (e.g. a CoAP request to a resource) to stop or further throttle joining messages being accepted by relay nodes for a limited time. Of course as you mentioned, this will be delayed until the third flow of the DTLS protocol, but the DTLS cookie should provide some additional resistance initially. In other scenarios, the timing of a joining device is known (e.g. within a home) and the relays can be asked to switched on and later switched off to restrict the window of opportunity to the attacker.

The idea is that the new device gets the configuration info within the DTLS session that is created (e.g. as a CoAP request to a resource). How and format needs to be defined (either here or somewhere else more generally).

There could be more threats and possible countermeasures, let me know if you have more ideas.

Regards
Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Rene Struik
> Sent: Tuesday, May 27, 2014 10:55 PM
> To: dtls-iot@ietf.org
> Subject: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01
>
> 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: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
>
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.