Subject: [core] The CoAP protocol is the next big thing for DDoS attacks | ZDNet

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Dec 2018 00:26:15 +0100

CoAP is making some waves in a not so nice way:

> https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-ddos-attacks/ <https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-ddos-attacks/>

The potential for amplification in a UDP-based protocol of course is not news.  
We wrote about that in the RFC:

https://tools.ietf.org/html/rfc7252#section-11.3

Still, the attention this is getting may be a good occasion to examine how CoAP has been implemented by the platforms that make themselves exploitable as DDoS amplifiers.

(And the amplification issue will be exploited by outlets that claim that it can be used to “remotely control IoT endpoints by leveraging security issues”, as e.g.:
https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-flaws-warns-trend-micro/
Of course, if it becomes the fashion to make CoAP servers without security available to the Internet at large, this might even be true.)

Grüße, Carsten

---

From: Robert Quattlebaum <[email-masked]>
Date: Mon, 10 Dec 2018 15:15:41 -0800

If NoSec modes become (remain?) popular, it may be warranted to develop some sort of stateless handshake to be used only for NoSec modes, in order to nullify the amplification factor. What I'm imagining would look something like this:
A client sends a normal request to a server.
The server responds with "4.01 UNAUTHORIZED" along with a single new required/no-cache-key option "Handshake" with a two-byte value which is opaque to the client. The response would have no token or body, in order to make the response as small as possible.
The client re-sends the request to the server with the same "Handshake" option and value.
The server verifies the handshake value is correct for the client's ip/port and handles the request normally.
Note that in the above scenario, the handshake happens per-hop rather than end-to-end.

This seems like it would be fairly easy to implement. It wouldn't reduce the packet count, but it would eliminate the amplification factor. Client implementations would remain fully compatible with servers that don't implement this handshake.

Thoughts?

-- RQ

> On Dec 6, 2018, at 3:26 PM, Carsten Bormann <[email-masked]> wrote:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Dec 2018 00:44:21 +0100

On Dec 11, 2018, at 00:15, Robert Quattlebaum <[email-masked]> wrote:
> option "Handshake" 

Hi Robert,

you might want to have a look at

	https://tools.ietf.org/html/draft-ietf-core-echo-request-tag#section-2

which defines a similar “Echo” option.
This could indeed be used for validating IP address ownership of the requester.

I still think that

tells a server implementer what to do, but if that cannot be done, “Echo” may be another way to reduce amplification factors.  Of course, it means that the state machine of all clients now needs to be more complicated.

Grüße, Carsten