Re: [T2TRG] [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt

[John Mattsson <[e-mail]>]

Achim Kraus wrote:
>Is there any newer or more concrete information about that then
>https://www.netscout.com/blog/asert/coap-attacks-wild ?

I know that Achim already saw this info on Github, but It might be interesting for the rest of the list as well.

Looking for newer information on CoAP amplification attacks I found a report from Radware. One of their figures show that CoAP was behind a significant part (around 15% maybe) of global DDoS attacks in Q4 2020 and Q1 2021, but not at all in Q2 and Q3 of 2021.
https://www.radware.com/2021q3-ddos-report/

Seems unclear how the attacks was done, why they stopped, and if CoAP DDoS are likely to come back.

Cheers,
John

From: Achim Kraus <[e-mail]>
Date: Wednesday, 2 February 2022 at 18:52
To: Carsten Bormann <[e-mail]>, John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt
Hi John,
Hi Carsten,
Hi List,

about the amplification attacks:

Is there any newer or more concrete information about that then
https://www.netscout.com/blog/asert/coap-attacks-wild ?

(My impression is, that others mainly refer to the same.
You may check my list on
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f151667455ba3294&q=1&e=ba594369-81be-478d-ad1c-c54a4aece9d1&u=https%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki%2FLinks-to-CoAP-or-DTLS-1.2-research-information%23security---dtls--coap
).

I'm not sure, if there is a common, realistic understanding of the
"nature" of such an attack. At least I have much more questions than
answers. E.g. is amplification only relevant above some threshold?
Means, if a request with 80 bytes is used and the response has 160, is
that relevant? Or must the response be above 400 bytes in order to get
relevant? So, in theory there may be a lot of rules, but I'm afraid,
that these rules stay theoretical, complicated, and maybe practically wrong.

best regards
Achim Kraus

P.S.:
The number of unencrypted coap devices is currently declining.
It's now about 270.000 to 330.000. My own scan showed
an average response size of 338 bytes, and a median of 143 bytes.

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6ff451ba6e3cd1ef&q=1&e=ba594369-81be-478d-ad1c-c54a4aece9d1&u=https%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki%2FLinks-to-CoAP-or-DTLS-1.2-research-information%23research-sites---current-scans

Am 02.02.22 um 18:03 schrieb John Mattsson:
> Conclusion (at least my understanding) from todays interim:
>
>     Split the current document in two different documents:
>
> 1. Attacks on CoAP
>
> 2. Attacks using CoAP (aplification attacks)
>
> CORE will have an adoption call on the first document.
>
> We will discuss where to work on the second part.
>
> Carsten suggested to work on amplification attacks purely in T2TRG. I
> think I would be ok with that approach as long as we have a plan for
> what to do in the mean time. I think all future IETF document (not only
> IoT and not only CoAP) need to have much stricter requirements on
> denial-of-service mitigation.If IETF does not have a good DoS hygiene,
> likely nobody else will.
>
> As a security person, I would like to start with hard requirements like
> QUIC and then soften the requirements when we have more knowledge, but I
> agree that this is problematic for constrained IoT and not optimal at
> all. But DoS mitigation do cost, and devices need to take that cost. The
> alternative is that somebody else (services and infrastructure) has to
> take the cost, which is unacceptable.
>
> *From: *Carsten Bormann <[e-mail]>
> *Date: *Wednesday, 2 February 2022 at 15:49
> *To: *John Mattsson <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [core] New Version Notification for
> draft-mattsson-core-coap-attacks-02.txt
>
> On 2022-02-02, at 15:43, John Mattsson <[e-mail]> wrote:
>>
>> Publish
>
> I think we need to discuss what this means.
>
> In order of effort/time needed:
>
> 1 Publishing as a BCP >
> 2 Publishing as a (WG consensus) informational RFC >
> 3 Publishing as an (RG consensus) informational RFC >
> 4 Publishing as an (RG-sponsored) informational RFC >
> 5 Publishing as an Internet-Draft
>
> We already have (5); this could be improved by separating the DoS part
> (attacking using CoAP) from the attacking CoAP part.
> Further improved by adopting (in RG or WG, depending on next step).
>
> Obviously, we also want to move forward on the attacking CoAP part.
> Similar considerations apply, but I think these should be run separately.
>
> Grüße, Carsten
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core