Amplification Attacks using Observe

[emanjon]

Achim Kraus @boaks commented on on Nov 9, 2022: EricssonResearch/coap-actuators#21

Amplification factors can be significantly worse when combined with observe {{RFC7641}} and group requests {{I-D.ietf-core-groupcomm-bis}}. As a single request can result in multiple responses from multiple servers, the amplification factors can be very large.

I would prefer, to first list the single observe attack and then extend that with "multicast". Not all belief, that "multicast" is a good attack vector. It may be applied in a "local network", but spoofed external source addresses will not work too easy, if at all.

[emanjon]

Achim Kraus @boaks commented on on Nov 9, 2022: https://github.com/EricssonResearch/coap-actuators/issues/21

requesting notifications at least 10 times every second

AFAIK, the notifications are sent, when the resource is changing. So the attacker has no control of the notifications interval.

"requesting notifications maybe 10 times every second"

[emanjon]

There is alredy a description of observe without multicast. "2.2. Amplification Attacks using Observe"

But that is mixing in other stuff as well. Could expand with a simple observe attack

[emanjon]

Agree that the Foe sending multicast is not an "good" attack vector. I added a gateway to the multicast figures. This is an architecture that has been discussed a lot in CORE. Then the attacker sends unicast, which the GW transforms into multicast.

[emanjon]

AFAIK, the notifications are sent, when the resource is changing. So the attacker has no control of the notifications interval.

"requesting notifications maybe 10 times every second"

My understanding is that Uri-Query: pmax="0.1" changes this, which is a reason Klaus Harke does not like that draft. My understanding is that with Uri-Query: pmax="0.1" the server will send notifications 10 times per second even if the resource has not changed. I commented on that draft in CORE and that it has DoS problems. Will update based on the outcome of that discussion in CORE.

[boaks]

Uri-Query: pmax="0.1"

Maybe you add the RFC ? Anyway, that will be a brilliant "honey-pot". Each cloud server SHOULD then just block a client, which request that for about 10 min ;-).

[emanjon]

Fixed in master. Link to conditional attributes also in the multicast+observe section.

[boaks]

"By using conditional attributes {{I-D.ietf-core-conditional-attributes}} an attacker may increase the frequency of notifications and therefore the amplification factor. "

Would it be not more precise to point out, that this only applies:

If that draft is implemented and supported at all. And the support doesn't limit the values range in a system specific way?

[emanjon]

Added text similar to the one suggested above to the observe section. Removed conditional attributributes from the multicast section, enough to mention them once.