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

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

Return-Path: <mohamed.boucadair@orange.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 1D8403A09D4; Tue, 7 Apr 2020 10:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugjAWRvEyuTn; Tue, 7 Apr 2020 10:41:33 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619B03A09C5; Tue, 7 Apr 2020 10:41:33 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR44GRz8slB; Tue, 7 Apr 2020 19:41:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586281291; bh=NnTKUNempGvh7z/MhbD9tS/0qCskKu2X5UPkotvZgIs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=eVz/KFEf+d5yBtYUdHD6YO7v7GeZCGd3D9iRFkQwmtxD4/JczoFhSaRPj9RbTLg6d uYOGLMFXC+YdeCx7hKGlEH8p3TKYb8xlG8v6EVTzIGZ/Of6i/5PT60IVyNOC8jMK7R 4sMkHQ4zKTpvDUS0zGtU/n7KLpcj2O9HMTx2/GrF4BHAx7QkxGrqt50tk33tmBJi8G hyLOvgV/8/r6+42ajV47bmplmmeZGJZcCMlwqhjLvJ7lDjbWW6Xwk7QLmvgo9ijljo +aoj8jsLbLn2WDRYs2UKB41DXnuSBqxQQ5OMofGBAYGazyev18ZNk2yeTY2XCsIz5P Q55Dj+CgaqYtQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR2nvfzCqkn; Tue, 7 Apr 2020 19:41:31 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Achim Kraus <achimkraus@gmx.net>, "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: [core] Large asynchronous notifications under DDoS: New BLOCK Option?
Thread-Index: AQHWDQPFc2Cf8aWOkUeEiB2evm8ivQ==
Date: Tue, 7 Apr 2020 17:41:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net>
In-Reply-To: <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/bdrnIQMiDa3VQ0_GXWSFUrKWkD8>
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 17:41:35 -0000

Hi Achim,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Achim Kraus [mailto:achimkraus@gmx.net]
> Envoyé : mardi 7 avril 2020 18:50
> À : BOUCADAIR Mohamed TGI/OLN; core@ietf.org
> Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org
> Objet : Re: [core] Large asynchronous notifications under DDoS: New
> BLOCK Option?
> 
> Hi Med,
> 
> I think, not all assumption and requirements are clear to everyone.
> 

[Med] We are using CoAP for signaling DDoS attacks and for seeking help from a DDoS mitigator. The mitigation signal itself is compact as we do have a requirement that the signal channel survive under extreme DDoS conditions. We do have a mechanism to maintain the signal alive, to detect when it is lost and then to recover asap. 

We are now designing an extension to the base signaling that allows to share knowledge of attacks for better coordination and efficient mitigation. To that aim, we need to signal DDoS telemetry data between our DOTS agents (CoAP endpoints).  

> I guess, your mission is to send a couple of "block" messages, but
> without getting requested for the next-blocks, because the node is
> under
> attack and already receiving too much. Therefore the SACK will be used
> a
> little later as "cleanup"/"collect lefts".

[Med] Yes.  

> 
> My first idea about that was, that sending the "block-flush" just
> creates the next attack. But, if you sure, that this doesn't happen,
> then such an approach may help in that special situation.

[Med] Yes. 

> 
> I'm not sure, if you assume, that in the most cases all blocks will
> make
> it to the destination when sending them. That may also depend on the
> assumed number of blocks. If it's not assumed, that all block will be
> received, your payload should be encoded in a way, that you could
> decode
> the received blocks, even if some blocks are missing.

[Med] This is will be nice to have. This might be managed at the application (DOTS) level but there are some challenges as well (make sure that the crafted data will fit a single DTLS packet).

> 
> If that number is not too large, maybe a "blockwise with NSTART-X"
> will
> also do it. Especially if DTLS is used, it may be possible to concat
> the
> "ACK/next blocks" into one package (with multiple records). AFAIK,
> that
> would require changes in implementations, which optimizes the
> deduplication base on a strict sequence of blocks, but the difference
> should be not too large.
> 
> best regards
> Achim
> 
> 
> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com:
> > 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.
> >
> > Cheers,
> >
> > Jon & Med
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> >