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

Carsten Bormann <cabo@tzi.org> Wed, 02 February 2022 17:57 UTC

Return-Path: <cabo@tzi.org>
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 A2A9F3A183B for <t2trg@ietfa.amsl.com>; Wed, 2 Feb 2022 09:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 brZ4LbNknGh5 for <t2trg@ietfa.amsl.com>; Wed, 2 Feb 2022 09:57:50 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A41B3A1812 for <t2trg@irtf.org>; Wed, 2 Feb 2022 09:57:50 -0800 (PST)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JpqJn5yvLzDCcR; Wed, 2 Feb 2022 18:57:45 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <bd50b93f-4ecf-f367-0de9-eb49b90c0c15@gmx.net>
Date: Wed, 02 Feb 2022 18:57:45 +0100
Cc: John Mattsson <john.mattsson@ericsson.com>, "t2trg@irtf.org" <t2trg@irtf.org>, "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 665517465.321314-014d68d7dbb1e9436fc5bcd6bb119577
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E1DE32A-1762-46D0-B535-730E66FB2714@tzi.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> <bd50b93f-4ecf-f367-0de9-eb49b90c0c15@gmx.net>
To: Achim Kraus <achimkraus@gmx.net>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/4DKhJyZJGXzyB1iwMD31uhVBxiY>
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:57:53 -0000

Just picking one paragraph here:

> On 2022-02-02, at 18:52, Achim Kraus <achimkraus@gmx.net> 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