Re: [core] Consensus on using Echo to mitigate NoSec amplification?

Hello Carsten
Hello List,

 > There are now people out there that believe CoAP ranks with DNS and
NTP in the DDoS threat generated.

It seems to be indeed important to have such security mechanisms at a
prominent place. Otherwise researchers may fail to read it.

For example, the document "The Fragility of Industrial IoT's Data
Backbone" from late 2018, cites on page 24, the RFC 7959, page 6, with
"Both sides have a say in the block size that actually will be used."
and concludes "This means that the attacker could craft a request packet
asking for the maximum block size.". That conclusion is not according
RFC7959. The researcher would have to read through page 10-11 to find
"(The effect is that, if the server uses the smaller of (1) its
preferred block size and (2) the block size requested, all blocks for a
body use the same block size.)"

So, have it in a prominent place, will really pay off.

best regards
Achim Kraus

Am 25.02.20 um 14:19 schrieb Carsten Bormann:
> In draft-ietf-core-echo-request-tag-08.txt, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure.
>
> draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing.  The SHOULD in Section 2.4 item 3 is a bit hidden for my taste.  My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior.  There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated.
>
> <chair hat>
> Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation?  If you have a position on this, please reply to the list (or to the chairs) by March 2nd.
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>