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

[John Mattsson <[e-mail]>]

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