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

Achim Kraus <> Tue, 07 April 2020 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A1433A0770; Tue, 7 Apr 2020 12:04:29 -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 cvtIhkSkEgaz; Tue, 7 Apr 2020 12:04:26 -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 8D1393A0EEE; Tue, 7 Apr 2020 12:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1586286242; bh=GpXgLsGVG8ZrsqgNB4ishmasepQ84fcJoQLLfKPvv1c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=WPEqGYii1y+cBhMTBxLo19dG7YlaGY6tReLoVTE2YLPrGt2t1HZZZP8PLx3/6G4P4 wUCHWr4NxLUsmloBTlq9A/HbslXUT352o+Emh1mmAG3LMrvQhkAzCRZ/rc/MPFdMKb Y2vbHvLSBcAVnsUy1xjfjPRBnNN2FzBwE14ZJIKY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1M3DO3-1jIrFM2o9d-003gjp; Tue, 07 Apr 2020 21:04:01 +0200
To: Jon Shallow <>,,,
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$>
From: Achim Kraus <>
Message-ID: <>
Date: Tue, 7 Apr 2020 21:04:00 +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: <019301d60d05$d87fcca0$897f65e0$>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ReQsGiKjogqOLdcmututzFiDaI6m87yVxp4GLMLZ48fSJG85GKU yFHCwrBzAYjkR4VAdyK7SdrIYJQXxW7sLerNfeg3NM1BWsCmXr+AmaNai99xr10iOmg5j6E mu2B7mTTM1odU5gHnzw1/o6tFjXB5eFdquYutOr/bkeh71CplYTT/hezHhzjs3Lw18nkIgV 34wEig3KzBhuIT/TyCamA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Sh5UeQIoZwE=:///5Wlj0wKbtU1XgVnPAm5 5fzsIQUSEYwVX2fjjUKdHIhkV9gC7x8/ILngyteAMRGl+9eZU70+RTdQf93GOIIZB7yMZB4o3 wY6uc7hI5CaMcpJqwk21iF5zhIFIu+LxI17P5U5RhixVyPppjRt1bm+vgqmhCSONuEEc/QUDl 1HIX/9CNqkq9IjWK7nrnPP6t//I6HjdLANlmlWExUn6GVnc9fgFRFX9JRiNBCA1qpNnov0hLI 3A8aqzCicT3EcMw2kO00EBbH4AQ00iLM+h/DC7ZtDvABsVlJJ3OffKHrpuWd1+Ri5fluuUlbg MIh2Aa4bbakshQ8r7GY/OlWDAhKq5z5viDjHfd7T9uw1z6uqZjShvXZy7KQwhZpc+gdGBxdSx RbrTCOU3akU5wF/cTH3vd4Qtsx6A18m46kP2ztl/P3JD9SMpBk0rj6hKZRZoRKkMO6ufMADr5 AXqDR5WRGE4dN82VKrWilnAzUG/7RWfrLZdv+hOJmoUKxwI/pO3N0hIrx3oFtp4BiSwdlcIcD cqp0AvI/ztBVwEXwTsioZiIO5qzEFPamNvQFMRKfDaph3K+qYVdT9F3TSAsYgn2lWrPW7LD/j oRhWq4XKrSAww3ZXBpkmm3zkKQuzhsqOBltU/wOgp4BN6maskTDMvGdaQGnXUawAtxMLVi1wN bKyYXgwNGy/sgvPjqyocYbNrEQjV/B8HlOcSMAwycNB+MtvrfbIm4ExjHRn5jSXIzw4CZnxMN EHmZeRSTz/V1HigXbQuJtkZi9wT923YkhKbXTGMszQfehT+AIlVuOk+XFrusdll+cYWue0qO7 G1canXuIbZ++/lbVjCiuuYtuCTC0y1ZB7GjJrAzeRvK53v+7U87Nz9dUoUF70zXhz8rUQjREg wGI7OpOoBEIsdBNRTeQeJh+2fXfmiC0jofgYa68P+8tr12lVdhUKUwVM9cJ9NleIq86m5jC3L CvWFZXWZOfeE4D6YE7IjHJPm0qjfrvghUG6jDOz9vVJOwHZxkCOF5Awwri9av+vkcP0MM1yHF tn6otzpnYM3BdIcqBeOtmoi7FZwFuf9iVJAUtX3WhDiVclrTaHysxPF+bA2xCuNkedHzDnPeM 1W0cZPkpRMZSchcX+VVvAkcnHANuYwliCD/SrwUQpRswn/ohu/1gCapsCOAgs9Fx27FPl54zD Xis5ykVb6+L6JPM5sn4tXeRiKxQjk9G0RyiJLkvKKonOTw8fEj+vpq/WAIsUNv4s8rTxQt8Ds lJCQ2hnziteOfXG56
Archived-At: <>
Subject: Re: [core] [Dots] 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 19:04:30 -0000

Hi Jon,

I'm still not sure, if such an approach would make sense:
- if multiple blocks are required without gaps
- the package loss is high
=> that ends up in not receiving any "large payload" at all.

FMPOV, the first thing to ensure is, that the "large payload" gets split
into "application blocks", which could be processed even when other
application blocks are missing.

I would also not assume, that a "in between proxies" will be able to
process blockwise resources with gaps. So I'm not sure, why
observer/notify is used. If it should be used, (and a proxy will not
work,) then you may consider to "misuse" the notifies and send your
"application blocks" just in multiple notifies (each application block
in one notify, without droping "old" notifies, because they are not old
:-) ). In my opinion that would require less changes to existing
implementations than introduce a "blockwise without next".

In the end, it would be interesting, if such a improvement really pays
off. Using some nodes with standard blockwise and others with the new
one should show the benefit. It would be great, if you then report your

best regards

Am 07.04.20 um 19:56 schrieb Jon Shallow:
> Hi Achim,
> To add to Med's inline comments, the use case that we are trying to solve is
> as follows.
> We are trying to send telemetry information from a server to a unicast
> client which has the potential to exceed the size of IP packet (possibly
> multiple times too large).
> The environment that this telemetry information is going to be transmitted
> in will be where Distributed Denial of Service (DDoS) attacks are taking
> place and so there is a high chance that network pipes will be running at or
> near capacity and hence there is likely to be high packet loss.  It is
> likely that the direction of the telemetry data is the same as that of the
> packet loss.
> This telemetry is an additional tool for passing information about how
> mitigations of these DDoS attacks are being effective so that decisions can
> be taken as to how better to mitigate the DDoS situation.  This is making
> use of the DDoS Open Threat Signaling protocol (DOTS) described in RFC8612
> with other drafts for components of this protocol in the final stages of
> becoming RFCs ( ).
> While not desirable, it is acceptable if the client is unable to receive the
> telemetry data (out of band mechanisms such as phone calls can be used in
> slow time if needed for tuning against attacks) but we would like to
> maximize the possibility of the telemetry data getting through.
> Currently with other data and small amounts of telemetry, the GET response
> or Observe data can safely be sent off from the server and the client may or
> may not get it as we are using NON-confirmable.  PUT (which has small
> amounts of data) and DELETE are also sent as NON-confirmable - and the
> client handles things if there is not seen a 2.XX etc. response to the
> This issue is when the data is too large to fit into a single packet - we
> currently use the CoAP BLOCK2 option which works fine under normal traffic
> conditions, but relies on the client synchronously requesting the next block
> of data.  We currently are doing this as NON-confirmable so a loss of a
> block of data causes the transfer to stall with the need to do garbage
> collection at a later point in time ion the server.  Using CONfirmable
> causes everything to slow right down with the lossy network and prevents the
> next CON transmission for a long time as NSTART is 1.
> The data is CBOR based on YANG with the YANG parameters two-way mapped into
> integers to give as much CBOR data reduction as possible, so cannot save any
> space there.  It is theoretically possible to reduce the amount of telemetry
> data by only asking for subsets of information as Med has referred to in
> this email trail.
> It is possible to solve the issue using IP fragmentation and let the client
> re-assemble everything, but this is not ideal in a lossy network and there
> is no way to ask for a particular IP fragment to be re-transmitted.
> If there was a new CoAP option - let's call it NONBLOCK2, which the server
> uses to send the all the data packets without waiting for the GET request of
> the next block (only difference compared with BLOCK2).  If the client does
> not see all the blocks after a timeout, it can then request the missing
> blocks by using one or more of the NONBLOCK2 options in a new GET request -
> or just wait until the next GET / Observe response.  This may be a way to
> move forward if we cannot solve the issue in another way.
> Regards
> Jon
>> -----Original Message-----
>> From: Dots [mailto:] On Behalf Of
>> Sent: 07 April 2020 18:42
>> To: Achim Kraus;
>> Cc: Jon Shallow (;
>> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
>> New BLOCK Option?
>> Hi Achim,
>> Please see inline.
>> Cheers,
>> Med
>>> -----Message d'origine-----
>>> De : Achim Kraus []
>>> Envoyé : mardi 7 avril 2020 18:50
>>> À : BOUCADAIR Mohamed TGI/OLN;
>>> Cc : Jon Shallow (;
>>> 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
>>>> 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:
>> eP4
>>> /
>>>> 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
>> _______________________________________________
>> Dots mailing list