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

Christian Amsüss <> Tue, 07 April 2020 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D33B3A092A; Tue, 7 Apr 2020 06:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GlrVmfyFze7k; Tue, 7 Apr 2020 06:09:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AA963A0928; Tue, 7 Apr 2020 06:09:48 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id A7D8640142; Tue, 7 Apr 2020 15:09:46 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id 43CC914B; Tue, 7 Apr 2020 15:09:45 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by (Postfix) with ESMTPSA id 08DBF381; Tue, 7 Apr 2020 15:09:45 +0200 (CEST)
Received: (nullmailer pid 2764034 invoked by uid 1000); Tue, 07 Apr 2020 13:09:44 -0000
Date: Tue, 07 Apr 2020 15:09:44 +0200
From: Christian Amsüss <>
Cc: "" <>, "Jon Shallow (" <>, "" <>
Message-ID: <>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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 13:09:52 -0000

Hello Jon, hello Med,

I don't have full answers, but some data points (also pulling in the
cited mail):

> and a response (may need new code) that says status is too large to
> fit into a packet or has been truncated).

That an observation with blockwise would already do: If the observed
resource changes to have its representation larger than the block size
or MTU, it'd send the first block.

> The observer will follow a SACK-like approach to request
> retransmission of missing fragments.

There was a draft around on non-traditional responses[1] some time ago
that would provide building blocks from which a server could send
follow-up blocks in an unsolicited fashion: The second block would be a
message in the style of "This is a 2.05 Content response, which you
would have received as a response had you requested block2 of /path".

Those messages would not be ack'ed if they are NON, and the client can
selectively request blocks it thinks it missed (but, in such a setup,
would do that after a suitable timeout to not request something that is
already in flight).

That draft was not followed up on directly, but some of its ideas wound
up in [2] where observe notifications are sent to a multicast group. In
particular, the topic of which tokens would be usable for unsolicited
responses to unicast addresses has not received the discussion it'd
probably need.

Kind regards


The detailed semantics of CoAP methods are "almost, but not entirely
unlike" [HHGTTG] those of HTTP methods.
[HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
  -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP)