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

Carsten Bormann <cabo@tzi.org> Tue, 07 April 2020 21:19 UTC

Return-Path: <cabo@tzi.org>
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 8A6E13A134C; Tue, 7 Apr 2020 14:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 rQoX3QQ1bvE0; Tue, 7 Apr 2020 14:19:02 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614333A134A; Tue, 7 Apr 2020 14:19:00 -0700 (PDT)
Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xgJL5t8lzySC; Tue, 7 Apr 2020 23:18:58 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <a36c6114-d979-e04a-7806-3ad350208e4a@gmx.net>
Date: Tue, 7 Apr 2020 23:18:58 +0200
Cc: Jon Shallow <supjps-ietf@jpshallow.com>, mohamed.boucadair@orange.com, core <core@ietf.org>, dots@ietf.org
X-Mao-Original-Outgoing-Id: 607987138.268279-c8b953ef6a0c78172142dc3c02ae1b1c
Content-Transfer-Encoding: quoted-printable
Message-Id: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <a36c6114-d979-e04a-7806-3ad350208e4a@gmx.net>
To: Achim Kraus <achimkraus@gmx.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/USP4OaG8W6Deu52pqWljmdtxPxQ>
Subject: Re: [core] [Dots] 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 21:19:05 -0000

Hi Achim,

On 2020-04-07, at 21:04, Achim Kraus <achimkraus@gmx.net> wrote:
> 
> 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.

Indeed, “application layer framing” comes to mind here; that is always a good idea if it cannot be ensured that all messages make it or if it is good to be able to process messages while still waiting for others.

                     .oOo.

I’m trying to understand the very specific network environment that we are targeting here.
Are we assuming packets are way more likely to make it from the server to the client than the other way around?
That indeed would call for additional capabilities that base CoAP does not have.
We also may not really care about congestion control much in a situation of massive (attacker-induced) congestion (although that might be misdiagnosed, so some care is still required); which would be another reason to maybe deviate from base CoAP.

I don’t have a design in mind at the moment.  It would need to cater for the fact that sending the other response messages for the request would be on the initiative of the server.
So observe (with non-confirmable responses) is maybe a good model indeed; what’s missing is some way to ask for gaps.

I just resubmitted a draft that we have been discussing for a while in T2TRG:
The Series Transfer Pattern (STP)
https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html

This has some discussion that may be relevant here, although it does not address the specific DOTS problem.  I think it would be great if whatever we come up with to solve this problem would also be a step forward on the larger class of applications needing the series transfer pattern.

Grüße, Carsten