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

mohamed.boucadair@orange.com Wed, 08 April 2020 09:56 UTC

Return-Path: <mohamed.boucadair@orange.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 96A223A0FE5; Wed, 8 Apr 2020 02:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 C67rlb0-Ugoo; Wed, 8 Apr 2020 02:56:17 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2EC3A0FE4; Wed, 8 Apr 2020 02:56:16 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48y0663tZNz5vdm; Wed, 8 Apr 2020 11:56:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586339774; bh=iHbYQjpslX5s7pGcTMA04lnQcW5heQhj96FyHxcUN4o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=o20XXuT1ChSeC3SS1oilAelf6cDJYFvsxRWVd2K5MNje2llffQZC12yvqNLl8sd9V VyUL0ikNizMXTLgn0695MnYWVQ+7UJLdHNSbOkPebOEkVvVe+4NKsUZg9RdTnp6SxQ iV2zPKhjtNtIykFrM6dIGfqXhONGsihG754LZpDIhuumVsWbbwQo1DfEfZNGBTgW8m Lr0MrR1aG6DXXByYcGsVj0rGerz5P687rlAIN941BqORQDF7JY6L01TrXTMM1XYO8y X3S0UcrRCDcfwwBdhHJ41TWzpuPUwhaX95uNBJB3C/E/El8y+eqHnO8qCz0DB4Odeh lvgvtIIT6tPsg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48y0662nVxz8sZj; Wed, 8 Apr 2020 11:56:14 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Jon Shallow <supjps-ietf@jpshallow.com>, core <core@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option?
Thread-Index: AQHWDYvwpy/bxUigK0iz1rVnLiHoRg==
Date: Wed, 8 Apr 2020 09:56:13 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org>
In-Reply-To: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/RZgQi-g74sATBvgM-mJlFZKnJkU>
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: Wed, 08 Apr 2020 09:56:19 -0000

Hi Carsten,

We are also considering how to solve the issue at the DOTS level. The good news is that we are not blindly overriding pieces of data that are received in distinct responses. We have some checks to update an active record. But as mentioned by Jon, there are some challenges as well. 

With regards to the network environment, the direction of the attack is the same as the one from servers to clients. That’s said, telemetry data can be exchanged in both directions:

* from client to servers: using a dedicated telemetry message or in an efficacy update shared with the server when a mitigation is active. This is done using PUT messages.
* from servers to clients: telemetry data can be sent in dedicated notification messages or as part of the mitigation status update. Both rely upon GET+Observe. Having a mechanism to ask for gaps would thus be helpful.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:cabo@tzi.org]
> Envoyé : mardi 7 avril 2020 23:19
> À : Achim Kraus
> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org
> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> 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