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

Carsten Bormann <cabo@tzi.org> Tue, 25 February 2020 13:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBC3A09AA for <core@ietfa.amsl.com>; Tue, 25 Feb 2020 05:19:37 -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 XdQl-i67nk_0 for <core@ietfa.amsl.com>; Tue, 25 Feb 2020 05:19:35 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B193A0C2C for <core@ietf.org>; Tue, 25 Feb 2020 05:19:35 -0800 (PST)
Received: from [192.168.217.147] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48RffY3JyRz1006; Tue, 25 Feb 2020 14:19:33 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 604329572.953993-62417ffff4a07333dfa909ed9107d1ce
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Tue, 25 Feb 2020 14:19:33 +0100
Message-Id: <2554B0B8-1C32-453E-AB28-90AB61242450@tzi.org>
To: Core <core@ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wy5bOuXaupfSY9u_hY99U9BDLZ0>
Subject: [core] Consensus on using Echo to mitigate NoSec amplification?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 13:19:38 -0000

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