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

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Feb 2022 14:02:27 +0100

Hi John,

> On 2022-02-01, at 10:30, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> I think this would be a good time to have an adoption call for the document. Echo, Request-Tag, and Token Processing will soon be published as RFC 9175. It would be good to publish the informational “CoAP Attacks” as a companion document in the not-too-distant future as suggested by the security AD.

I think we need to open up this discussion a little bit before we converge on a good way forward.

We already have elements of solutions standardized, e.g., echo-request-tag (RFC 9175-to-be).  This is a standards-track document, done in the CoRE WG.
This document provides the implementer with a set of tools, but doesn’t provide actionable guidelines as to when these tools should be used.

We obviously need more documentation.

We could go ahead and do a BCP now, but somehow that might work approximately as well as the hand-washing mandates that are trying to prevent the spread of COVID-19 — we don’t actually know very well what works and what doesn’t (*).

To really do a BCP that works in a sustainable way, we need to do a bit more research:

— what attacks do occur in practice
— what solutions [mitigations] (RFC 7252, RFC 9175-to-be, others) actually do work against these attacks
— are there workarounds against those solutions that an attacker could use
— would certain solutions just shift around the attacks to a different vulnerability
— what is the design space for potential additional solutions that have fewer work-arounds
— if there are several solutions that one could choose from, how do they compare in
  — effectiveness
  — onus on the communication partners and the network in between
— can we come up metrics that actually allow an implementer to make decisions in this complex space

That information should not all go into the BCP, as this should focus on the actionable advice.  Instead, there should be a document that can be referenced from the BCP to provide more detailed explanation and rationale.

That other document (“research document”) would be a natural thing to work on in T2TRG.  We already have had some off-list discussions that indicate that we might have critical mass for that.

Grüße, Carsten

(*) Spoiler: Hand-washing does little against the spread of COVID-19.  But a general increase of handwashing is not bad at all, and it may be hard to retract mandates until it is proven that handwashing never helps (which you essentially can’t prove), so handwashing will stay on as a ritual that started with COVID-19.
One of my objectives is to minimize the number of rituals that we infect our ecosystem with…

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Feb 2022 14:43:41 +0000

> We obviously need more documentation.

I agree that we obviously need more research and documentation regarding amplification attacks. I also agree that we need more discussion. I think it would be very good if T2TRG do research on the topic.

echo-request-tag (RFC 9175-to-be) will soon be published which provides mechanisms and guidance to mitigate some of the attacks described in draft-mattsson-core-coap-attacks.

Regarding BCP, I agree with you that we don't have all the knowledge. On the other hand we need to make sure that amplification attacks using IoT devices do net get worse. They cause significant and costly damage. Right now CoAP is used in DDoS attacks, and it is not even clear that the devices used are violating IETF requirements.

I think a minumum right now is to publish descriptions on how CoAP can be used in amplification attacks (draft-mattsson-core-coap-attacks) and to make the amplification mitigation requirements in new RFCs (group communicaiton, conditional attributes) stricter then CORE has done in the past.

I agree that an BCP would likely be much better if written later. But one could also arguee that if we know so little on how to mitigate IoT amplification attacks, publishing more IoT RFCs is unethical.

I think a reasonable way forward would be
-               Soon: Publish descriptions on how CoAP can be used in amplification attacks.
-               Soon: Discuss how to make the amplification mitigation requirements in new RFCs stricter between now and when the BCP is published.
-               Later: Publish T2TRG research document on denial-of-service and amplification attacks.
-               Later: Publish BCP referencing the research document.

For T2TRG, here are links to the last two presentation on the topic.

https://datatracker.ietf.org/meeting/111/materials/slides-111-core-coap-attacks-00

https://datatracker.ietf.org/meeting/interim-2022-core-02/materials/slides-interim-2022-core-02-sessa-coap-attacks-draft-mattsson-core-coap-attacks-02-00

Cheers,
John

From: Carsten Bormann <[email-masked]>
Date: Wednesday, 2 February 2022 at 14:03
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt
Hi John,

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Feb 2022 15:49:47 +0100

On 2022-02-02, at 15:43, John Mattsson <[email-masked]> 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

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Feb 2022 17:03:06 +0000

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.

Date: Wednesday, 2 February 2022 at 15:49

1 Publishing as a BCP >

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Wed, 2 Feb 2022 18:52:29 +0100

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://github.com/eclipse/californium/wiki/Links-to-CoAP-or-DTLS-1.2-research-information#security---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://github.com/eclipse/californium/wiki/Links-to-CoAP-or-DTLS-1.2-research-information#research-sites---current-scans

Am 02.02.22 um 18:03 schrieb John Mattsson:
> 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 <[email-masked]>
> *Date: *Wednesday, 2 February 2022 at 15:49
> *To: *John Mattsson <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: [core] New Version Notification for
> draft-mattsson-core-coap-attacks-02.txt
>
> We already have (5); this could be improved by separating the DoS part
> (attacking using CoAP) from the attacking CoAP part.
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Feb 2022 18:57:45 +0100

Just picking one paragraph here:

> On 2022-02-02, at 18:52, Achim Kraus <[email-masked]> wrote:
> 

That is exactly the issue that makes this so hard.
We need to factor in how attackers are going to behave, so the answers are neither exact nor stable.
If there are better amplification sources, there will be much fewer attacks using public CoAP servers.
But once these go away, CoAP server suddenly seem interesting again.
So the fixes in other protocols and implementations are our enemy here…

It seems you have data, and that is what I’d like to collect in the T2TRG effort, together with what went wrong in the specific instances.

Then we need to forge these data into an assessment of the situation and finally rules with a bit harder boundaries than the ones we already have.  That will be the BCP.

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Fri, 4 Feb 2022 09:09:21 +0100

Hi Carsten,

 > So the fixes in other protocols and implementations are our enemy here…

For the future there may be several ways to go.

Amplification attacks:
AFAIK requires address spoofing and that seems to get harder.
One way is to try to give guidance to use "plain" CoAP in a saver way,
the other is to give the guidance to use CoAP over DTLS, which reduces
such amplification as well. I'm unfortunately not common with OSCORE, so
I don't know, if that changes something in that scope or not.

Attacks by "captured" devices:
Such attacks don't require spoofing, but the protection against
capturing a device have a larger scope than just the protocols. What is
required according the protocols, is to harden the implementations.
FMPOV, it's again a difference, to focus on CoAP or DTLS. AFAIK,
hardening DTLS makes progress, seems that many researches have put an
eye on it. At least the open source project received a lot of input to
improve (e.g. californium, tinydtls, pion/dtls).

In the past years I missed some guidance about protecting the "systems
under attack". Years ago, the major general recommendation seems to have
been "block UDP at all at the very first firewall".
That obviously doesn't work for CoAP over UDP or DTLS. In the scope of
Eclipse/Californium I added therefore instruction to use firewall rules
for DTLS (see
https://github.com/eclipse/californium/wiki/DTLS-1.2-based-firewall), if
that is possible (obvious, that mostly isn't possible at the very first
firewall, but later on the own machines).
For plain CoAP, I don't see, how malicious traffic can be filtered out
at that level.
(And yes, that protects only from non-DTLS traffic, as explained in the
wiki.)

For me the question is therefore more:
Stick to try to give guidance to use plain CoAP,
or start to stronger recommend DTLS.

 > It seems you have data, and that is what I’d like to collect in the
T2TRG effort, together with what went wrong in the specific instances.

I setup some time ago https://github.com/eclipse/californium/wiki and
update the information there.

best regards
Achim Kraus

---

From: John Mattsson <[email-masked]>
Date: Wed, 9 Feb 2022 13:29:03 +0000

>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 <[email-masked]>
Date: Wednesday, 2 February 2022 at 18:52
To: Carsten Bormann <[email-masked]>, John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt
Hi John,
Hi Carsten,
Hi List,

(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
).

best regards
Achim Kraus

P.S.:

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