Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Tue, 07 April 2020 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D23F3A0EAD; Tue, 7 Apr 2020 09:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o_2UQ5pdboFX; Tue, 7 Apr 2020 09:48:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 079F73A0EAA; Tue, 7 Apr 2020 09:48:50 -0700 (PDT)
Received: from (unknown [xx.xx.xx.6]) by (ESMTP service) with ESMTP id 48xYJc5S0Lz7tqZ; Tue, 7 Apr 2020 18:48:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1586278128; bh=PFNUr/DLCWdsL/Urbz4cLj2KnwQxYJyt+osuaCuzje4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=l9oVm/gviZKxWmAWKIChS+lh2m1AQjb0qs7NWCgSDoMscvIbr4RSQL2xmExJmq+ap u02XEpjvg60KtkJcUCBOnwbU/KWkbTmQZoXueJ0u+X2znQ2r6pYKduttW+SoboBpq7 uuj0Fb+x8zacyAxKRu0dzNyMl15ta5OCJVuGxBKylLFDihunLTDOjTFEMDaRkEd57o VKMWp/2uRgwqmoDTEOKpK3PWEnLckkq2ADG//CHGWOIhNk9kJnzyAOvCOtWIPorTXJ XRTCfyAVLPe+EqEgiZDRsnVb4Z1Xeh3E0IeoXSBX3Ge6VrK3XXNMGMLD0OSjEAOhW6 gqm/Wq0jq1New==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by (ESMTP service) with ESMTP id 48xYJc4GM2z1xpK; Tue, 7 Apr 2020 18:48:48 +0200 (CEST)
From: <>
To: Jim Schaad <>, "" <>
CC: 'Jon Shallow' <>, "" <>
Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option?
Thread-Index: AQHWDPxoTyAJ7vdgrkKV3NX2lQCcxw==
Date: Tue, 7 Apr 2020 16:48:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303149082D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <049201d60cef$d1299a50$737ccef0$>
In-Reply-To: <049201d60cef$d1299a50$737ccef0$>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_"
MIME-Version: 1.0
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 16:48:52 -0000

Hi Jim,

That can be policy based at the client side + some signal to the server.

For our DOTS application, clients indicate to servers that they are (not) willing to receive all the content (below an excerpt of our spec):

   DOTS clients that are interested to receive pre- or ongoing mitigation
   telemetry (pre-or-ongoing-mitigation) information from a DOTS server
   (Section 8.2<>) MUST set 'server-originated-telemetry' to 'true'.


   In order to signal telemetry data in a mitigation efficacy update, it

   is RECOMMENDED that the DOTS client has already established a DOTS

   telemetry setup session with the server in 'idle' time.

Clients can filter out data they are interested in (Uri-Query), e.g.,.

   Header: GET (Code=0.01)

   Uri-Path: ".well-known"

   Uri-Path: "dots"

   Uri-Path: "mitigate"

   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

   Uri-Path: "mid=12332"

   Uri-Query: "target-alias=https1"

   Observe: 0

If not filter is included, all the content has to be returned to the client:

   Header: GET (Code=0.01)

   Uri-Path: ".well-known"

   Uri-Path: "dots"

   Uri-Path: "tm"

   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

   Uri-Path: "tmid=123"

   Observe: 0

    Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications

                           for a Specific 'tmid'

What is missing for us is a "BLOCK2"-Like option to send all fragments without waiting for a GET + retrieval of missing fragments (if any).


De : Jim Schaad []
Envoyé : mardi 7 avril 2020 17:19
Cc : 'Jon Shallow';
Objet : RE: [core] Large asynchronous notifications under DDoS: New BLOCK Option?

I do not believe that there is anything today that says the observer is required to do a GET to receive the next fragment in the event that it does not care about what it says.   The question that sprints to mind is how should the server/client decide that it does or does not want to retrieve the entire content?


From: core <> On Behalf Of
Sent: Tuesday, April 7, 2020 4:11 AM
Cc: Jon Shallow ( <>om>;
Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Option?

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:

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.

Jon & Med