[core] Large asynchronous notifications under DDoS: New BLOCK Option?

mohamed.boucadair@orange.com Tue, 07 April 2020 11:11 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1E0383A0C69; Tue, 7 Apr 2020 04:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DGeA9ogT11BZ; Tue, 7 Apr 2020 04:11:31 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788943A0C68; Tue, 7 Apr 2020 04:11:31 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP0d0tzCqvg; Tue, 7 Apr 2020 13:11:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586257889; bh=XLmWoNokFlCJkYyTt/BI5qtSXAUXqbizdfhpknnz+UE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=xBRTYmU9OWPIqnhjXdQrSiiZSktRksPP/kxtJlI7C7AZGGtLj6k94JWmOMWGEXtpp P3QF522YIs9rotIxNngfqMt1JZPSGvWO1PnB/BSKTHlK1XaOPCAnFBN3gYjRhZlDIt x0tkcrjs/qwffKbfvNp4NFpZYnMHwwKSTdJkdDfNRUBvG9EzDUvnVYoSw+Kf/f4TmN Sik/u3/wSqUNTibwpXwhBmPTObvOb+sLVEFt04fW/e9YqRH8ctTGTpbbqDw91F4snr 5tuK4OJsiTM3kSF4Y70S90YTl9GNKkHA3ibG4AA/5xfIwftMR1tqI7Rr1zMCMfwOuX EHwntLQRTho7w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP1KfPzDq7k; Tue, 7 Apr 2020 13:11:29 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "core@ietf.org" <core@ietf.org>
CC: "Jon Shallow (supjps-ietf@jpshallow.com)" <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Large asynchronous notifications under DDoS: New BLOCK Option?
Thread-Index: AdYMzUH7Od/A8MMEToW8zPzszV9XuQ==
Date: Tue, 07 Apr 2020 11:11:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/H4NM0doO_ZzaHdkm5Op9UukP3-4>
Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Option?
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, 07 Apr 2020 11:11:33 -0000

Hi all,

We are using Observe to receive notifications during attack events. These notifications are set as NON messages for reasons specific to DDoS conditions.

With DDoS telemetry information included (see draft-ietf-dots-telemetry), a notification may not fit one single message. The use of BLOCK2 is not convenient during attack times. A full description of the issue is described here: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/

We are considering some mechanisms to solve this issue. One of them is to define a new BLOCK option (similar to BLOCK2) that does not require the observer to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-like approach to request retransmission of missing fragments.

Please let us know whether you think this is a generic issue that should be solved at the CoAP or not. Suggestions are welcome.

Thank you.

Jon & Med