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

Achim Kraus <> Tue, 07 April 2020 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 083043A0EC1; Tue, 7 Apr 2020 09:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ohPWqocywtQi; Tue, 7 Apr 2020 09:50:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE1A23A0EBD; Tue, 7 Apr 2020 09:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1586278203; bh=ILiRS55BpU55sdLJLxrv12R+4F2XOmjFKm8b0WuGy30=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cSVbzKT/1/U2duaPQaZFKgrY2UV3uR90khbT88YgB2zhFU5D1tSUVpsnmw89o/a8l DciqxlP3TC15UONSMsvovC9dfiiJUHf8U2IRd7gNQylsOXkyTsLTISuzp9qeInevJt no3EBKzLhxWA4IS8aB4UDd44s44sD8lJammM49eI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MD9X9-1jUtpa1skj-0099n6; Tue, 07 Apr 2020 18:50:03 +0200
To:, "" <>
Cc: "Jon Shallow (" <>, "" <>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Achim Kraus <>
Message-ID: <>
Date: Tue, 7 Apr 2020 18:50:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:mPFjpV4HB6bc1Em4PJbRRTBjDTwakg/BFkx3yMW1Tb7ObxrRM/g HmTpNZzdIPeiBg08PJQZKkaUzFS1BGcEXxu1wRnZrSzzswwmYCs6KIjQxDD3ToIJE1yqZfq Vk732vhUmidCsMubMvdY9hU8UffYggX6zXKHppp+GvSgbXm/B7FKnYdb7g8Q3Sqsc/HnR94 HiHyjNROn8BmV3Iis5gGw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zO8W3e4ORhY=:P0GBs1ZNtHBgbPxHDHFXIW 1ri3/7nfeqEgPFbmzGAwJUAcSgh7d4Eleqkhz1wBY8zs7vgVKCBTkxPwwCMMZnVM0xzP8k70a QUJu1SeDhCSysIgT/RUsG3asUFkMLV38Bobq7E7Ff7qznCLfvuEeYtdbivmxWKbqG6GR2UgPM 7KNsd0xa4gBi+8+V3aWMn5k47RadhrMGDeIQnXJfazn9fKp8jDml/VaCrbB1cHLvOqW51jviN 5yp8bwyudzA10C9ih/MysARe0Oa488X04zFkTn9AONK3VcqDqYOdLFpOjyVDR/kZ5uF+1mSA1 AfBKxhqYZ4N+NMvkDM0qMCuDR+kFRrAtrObr1HcnPGMFYV7mP4Bnppjl+zv9PSDn8M+gvQMrF zNohcEZYUb/snx15HnJm3HR0sR/VZ4J701vSwvcNPxyTkRQvrJGW3gAGWnvh8zN9fOx1dg5WA AthQDxc/sFCYJWdzNKgIxGNI/0Tt7OinBU4XahogVZlHqDC7elmQoAy3+qiTqu2GkSbWXz3Qt r24oXy51WtE9fl8lGjO4lmwGAC6aGm043k4gUGRQPf3IwbV600wKDVQDOmBK38YLFV4lDO79s TqEcqlevJOc1mFW0nJqEA/4xhVcXUZHK9YIfM/gFKdbmPTsxsRADXzfCacfKepHZoiV3BWQUK L2yjLh+u74tmiv598hVIcbVGMM6WbxLu82F8DwETZXAweXu3q/RvfXjFOa5SvSyFrjrsxnwqy BqITQz+jSCCvhDI1papz653ya20781w8aTE9yZXEC08CP8SKQLy1fjZ6VjvBOfCYIa5gqvm/4 3a6bUSrvrOJqH66vnEGCs+6w9t+gbug7jBOk1egIY4pEpNUhMOq8A8kyoUW/c6fMnMSf5Q+rO dX4cm4a+7trisIS9dKO3Mc0kwGJYKBY6WEDRwCWgGyI16BdlqXI2i5updMvVgkbKoF0jsixwO yreURufRCTotWLwzt3TTNQDspfC1l35dtjFZrzY8dkNjEZwXl7n28mFSbunAJZD7v6nlaCSbW 4/hLojUCGJkgNVM90L8WXO1HZELpIEgNq1fxdFo+okiP5ew+KBFbYXnvYurogchw/PsKVjrxm Rvk6J0YAabSJCXaxjbpbzN9evF39yQHIWK+x7TYWYUENW00+NJygIuWWjJUuyPGIExXVYh6OP GdkcByP1fsSNsL0L2Sjv7AwF5D5Dz87XHtQTOYG3NMjXIHIEyywFbOxAqyAmuzesNzL3GosT3 5rPgEBOfETYWktdys
Archived-At: <>
Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Apr 2020 16:50:12 -0000

Hi Med,

I think, not all assumption and requirements are clear to everyone.

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

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.

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.

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

Am 07.04.20 um 13:11 schrieb
> 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:
> 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