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

Achim Kraus <achimkraus@gmx.net> Wed, 02 February 2022 17:52 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0D33A16E6; Wed, 2 Feb 2022 09:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.81
X-Spam-Level:
X-Spam-Status: No, score=-7.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMAFx1BvmLI9; Wed, 2 Feb 2022 09:52:44 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7707F3A1833; Wed, 2 Feb 2022 09:52:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643824350; bh=aSYnm/bnu0EcL1U3Q5NJGnhHMd09nxsYzgyW4yUYaVc=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=VBCN2+Lt/t4ZIcvSIJBb9cmo9Ri6d96fC6+nUJUBdPJi0uAOXrLhaXs7xg5s3V0uC GI9t2Gj2MIhZtbVRezQki3U9BQYO4LlyulOg/7GzjxRkDrvF8nRxm8E3o7+nSU0Pf4 CHKj0XiygJ6n1/4WyZ3B9xT4iB+cXBtZu8K9aTwc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1My32F-1mIZ4j32rP-00zXBE; Wed, 02 Feb 2022 18:52:30 +0100
Message-ID: <bd50b93f-4ecf-f367-0de9-eb49b90c0c15@gmx.net>
Date: Wed, 02 Feb 2022 18:52:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>, john.mattsson@ericsson.com
Cc: "t2trg@irtf.org" <t2trg@irtf.org>, "core@ietf.org" <core@ietf.org>
References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <HE1PR0701MB30500AA57A7DD6F3170BB60F89269@HE1PR0701MB3050.eurprd07.prod.outlook.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <HE1PR0701MB3050F758474CC029B932112F89279@HE1PR0701MB3050.eurprd07.prod.outlook.com> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> <HE1PR0701MB3050423B37F408F2C9F8B98689279@HE1PR0701MB3050.eurprd07.prod.outlook.com>
From: Achim Kraus <achimkraus@gmx.net>
In-Reply-To: <HE1PR0701MB3050423B37F408F2C9F8B98689279@HE1PR0701MB3050.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:8TCdd1WKt7kFGOtf1f7aNgFvUK1FoH2VtcstqbSxOgbeIxU5dH9 j/8F6nl+xx65epBLNcJ3gku5iXddy0cjGvxkyRZaIxIjiD4kAvva1ll6UZco96PKbZa6Sow YE8k2jx6+JzGcz0zr9rk0prJx8ks8+SXotf/IlTt6GU08Mc3c5H4lPMZelAuBk1XHKOvxJR aUdMdIbvsMSLVaxTMYUSA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dmrm3eojS3Q=:9QExgqS4nl3aUtmijak6nB aVms810OWIAgdaq3J3diVizIR7PoznoTuReMqhjDg46AyVt8sPjSt91/g35a8TUaYE/+rwKrF pSpHZxwkNj51WHaHc6j9rmIKGxJwyMXf5l8ZXK1j5ULXIQcTUtq4hcdKTW8eqp96lhGHjGmYK 2QjA2UwosXXbt+JkgxiuNXvuflJhVeFqhOSwHFbpnbOLkF+Ll792W96GHG5t1N9SugqXygmFp xxDBTin4vR6Xj1oqKV6Iw5ufgS3GMGIsVbN0vtfJk/6EJq6NWWQMhJzcYUwLa7J8F+TBJ4bco u/aHbINDO9kxusoqh5r+7/J3wChUj2lJ9Rd1LfpvgSCeDrPBwS2b1N/l+Op93X/Lm43qoSOHt exO7/r/h0uNamHboAqfyvGMR7ahwYyqPbtLIWDZGi5GgkGkoAFoRVh/AnC9s05evrCf2184vk WwUDBL3bU41vsZZpw4jRAKwnO0Hw/OPKSt6RZhC9Z2uPIFkBvO5C/s9rFu/sX2kBTZbZ+cz9V 7D9ItAlzgceqCZHeRbFu/v5fAAHo+RbLe3D/XTc229/QwTmcG16xVzyL3px37oGq9sYciNpfQ /aL7U4Te874rAJQ3BFAPTnMtyQLBIGPYSSrD1ZZRpehyPuEPrVdPdKwmEObVfiKzwHYJ9rYXU sfZqURZfkcq1h1KNw87qQzANMllAO+Loxq6xdBsp83b/YoC5i94X/9rrkKUJuE6JVgUnrBMXF QXTFeiNa5BkayIxpCF3NfeFOO2/g+rx6CHqGq4EuwoRV3hfrYOF25FXY8F9MGXgp3m5/iG8nM kKVi4EP1AcnoYZVTgypuEZcSs1hC3de/0X3ciqipXgazuOYCrm0MElCG078P5XCMyPMz6WA4c 5nrlr2nUsVBTpCw1rSfxtWJ5s5hLieJee3502bZAj2pRUB8+1ubh8oc/9Ts8X58cEcTF4EqNB Ivk+cpXOne8zuWA8RG7iGeOBWImZrloCAcyBAbnkp78A+D7MEh9gDA5THsSwI3vXuOMr1EcJv iUMjbJW8Df8FUm5WsF7t809t+Zwzz0di4hKhjd0X4Goj6QRFrGHcm9WTOmED3Xt40MfxOasH6 CY+9aLG56OxufY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/8C7XG_f-Q4XtSieQ2ppy63eKzug>
Subject: Re: [T2TRG] [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2022 17:52:49 -0000

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:
> 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 <cabo@tzi.org>
> *Date: *Wednesday, 2 February 2022 at 15:49
> *To: *John Mattsson <john.mattsson@ericsson.com>
> *Cc: *core@ietf.org <core@ietf.org>, t2trg@irtf.org <t2trg@irtf.org>
> *Subject: *Re: [core] New Version Notification for
> draft-mattsson-core-coap-attacks-02.txt
>
> On 2022-02-02, at 15:43, John Mattsson <john.mattsson@ericsson.com> 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
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core