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

[Achim Kraus <[e-mail]>]

Hi Carsten,

 > 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…

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


Am 02.02.22 um 18:57 schrieb Carsten Bormann:
> Just picking one paragraph here:
>
>> On 2022-02-02, at 18:52, Achim Kraus <[e-mail]> wrote:
>>
>> 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.
>
> 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
>