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

Jim Schaad <ietf@augustcellars.com> Tue, 07 April 2020 15:18 UTC

Return-Path: <ietf@augustcellars.com>
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 1B33D3A0C42; Tue, 7 Apr 2020 08:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r-oAboI2pnJa; Tue, 7 Apr 2020 08:18:45 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2203A0C46; Tue, 7 Apr 2020 08:18:44 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Apr 2020 08:18:38 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <mohamed.boucadair@orange.com>, <core@ietf.org>
CC: 'Jon Shallow' <supjps-ietf@jpshallow.com>, <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Tue, 7 Apr 2020 08:18:36 -0700
Message-ID: <049201d60cef$d1299a50$737ccef0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0493_01D60CB5.24CB3780"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKc6kPPIrA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tUSPYX2dxSmI5lSwFfaRyp27-bY>
Subject: Re: [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 15:18:47 -0000

I do not believe that there is anything today that says the observer is
required to do a GET to receive the next fragment in the event that it does
not care about what it says.   The question that sprints to mind is how
should the server/client decide that it does or does not want to retrieve
the entire content?

 

Jim

 

 

From: core <core-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, April 7, 2020 4:11 AM
To: core@ietf.org
Cc: Jon Shallow (supjps-ietf@jpshallow.com) <supjps-ietf@jpshallow.com>om>;
dots@ietf.org
Subject: [core] Large asynchronous notifications under DDoS: New BLOCK
Option?

 

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/>
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. 

 

Cheers,

Jon & Med