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

Christian Amsüss <christian@amsuess.com> Tue, 07 April 2020 13:09 UTC

Return-Path: <christian@amsuess.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 8D33B3A092A; Tue, 7 Apr 2020 06:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlrVmfyFze7k; Tue, 7 Apr 2020 06:09:49 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA963A0928; Tue, 7 Apr 2020 06:09:48 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A7D8640142; Tue, 7 Apr 2020 15:09:46 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 43CC914B; Tue, 7 Apr 2020 15:09:45 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (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, 7 Apr 2020 15:09:44 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: mohamed.boucadair@orange.com
Cc: "core@ietf.org" <core@ietf.org>, "Jon Shallow (supjps-ietf@jpshallow.com)" <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Message-ID: <20200407130944.GA2738832@hephaistos.amsuess.com>
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: <https://mailarchive.ietf.org/arch/msg/core/ISlQTOOKp1tROKgUYo3z-D4AB9I>
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 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
Christian

[1]: https://tools.ietf.org/html/draft-bormann-core-responses-00
[2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifications-02


-- 
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)