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

Jon Shallow <supjps-ietf@jpshallow.com> Wed, 08 April 2020 19:48 UTC

Return-Path: <supjps-ietf@jpshallow.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 818BD3A0ED7; Wed, 8 Apr 2020 12:48:25 -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 4IccYmFodxqH; Wed, 8 Apr 2020 12:48:23 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54A33A1638; Wed, 8 Apr 2020 12:48:21 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1jMGgK-0007UI-En; Wed, 08 Apr 2020 20:48:16 +0100
From: "Jon Shallow" <supjps-ietf@jpshallow.com>
To: "'Achim Kraus'" <achimkraus@gmx.net>, <mohamed.boucadair@orange.com>, <cabo@tzi.org>, <dots@ietf.org>, <core@ietf.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> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <f105cf6a-da87-d8da-35db-07975f064a94@gmx.net>
In-Reply-To: <f105cf6a-da87-d8da-35db-07975f064a94@gmx.net>
Date: Wed, 8 Apr 2020 20:48:21 +0100
Message-ID: <02b001d60dde$a8772650$f96572f0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hARxTHZOooAydoA==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ZLzaPFIojau_9bQ366hm_I4Y16o>
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 19:48:26 -0000

Hi Achim,

Having the DOTS CBOR data wrapped in CoAP and then wrapped in CoAP is interesting and could be a way forward here as it gives a lot of flexibility.

As mentioned in my previous response, looking at your suggestion, "Observe abc" or "Observe abd" are not really needed and could be replaced "Etag abc" and "Etag abd" respectively. 
Then with the GET to request the missing blocks could also include the appropriate Etag to make sure that the correct blocks for the resource are being asked for.

Then it may be possible to not have the double CoAP layer and just have the NonBlock2 option.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus
> Sent: 08 April 2020 19:56
> To: Jon Shallow; mohamed.boucadair@orange.com; cabo@tzi.org;
> dots@ietf.org; core@ietf.org
> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> Hi Jon,
> 
> let me try to demonstrate, how “application layer framing” could look like:
> 
> > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on
> client doing GET to get the next block synchronously. >
> >
> >         CLIENT      SERVER
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Observe 0 NonBlock2 0/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024
> Do these messages in the application layer -> encode the messages => put
> the encoded message as payload for ordinary notifies:
> 
>           CLIENT      SERVER
>             |          |
>             +--------->|   GET /path Token 0xf0 Observe 0 NonBlock2 0/0/1024
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1234 { 2.05 Token
> 0xf0 Observe abc NonBlock2 0/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1235 { 2.05 Token
> 0xf0 Observe abc NonBlock2 1/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1236 { 2.05 Token
> 0xf0 Observe abc NonBlock2 2/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1237 { 2.05 Token
> 0xf0 Observe abc NonBlock2 3/0/1024 }
> 
> The outer notifies will be processed as usual, the application block
> logic is yours.
> 
> Observe triggered
>             |<---------+   2.05 Token 0xf0 Observe 1238 { 2.05 Token
> 0xf0 Observe abd NonBlock2 0/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1239 { 2.05 Token
> 0xf0 Observe abd NonBlock2 1/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1240 { 2.05 Token
> 0xf0 Observe abd NonBlock2 2/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1241 { 2.05 Token
> 0xf0 Observe abd NonBlock2 3/0/1024 }
> 
> Observe triggered
>             |<---------+   2.05 Token 0xf0 Observe 1238 { 2.05 Token
> 0xf0 Observe abd NonBlock2 0/1/1024 }
>             |          |
>             |  X<------+   2.05 Token 0xf0 Observe 1239 { 2.05 Token
> 0xf0 Observe abd NonBlock2 1/1/1024 }
>             |          |
>             |  X<------+   2.05 Token 0xf0 Observe 1240 { 2.05 Token
> 0xf0 Observe abd NonBlock2 2/1/1024 }
>             |          |
>             |<---------+   2.05 Token 0xf0 Observe 1241 { 2.05 Token
> 0xf0 Observe abd NonBlock2 3/0/1024 }
> 
> 
> Client realises blocks are missing and asks for the missing ones in one go
> 
>             +--------->|   GET /path/ctrl Token 0xf1 { NonBlock2
> 1/0/1024 NonBlock2 2/0/1024 }
>             |          |
>             |  X<------+   2.05 Token 0xf0 Observe 1242 { 2.05 Token
> 0xf0 Observe abd NonBlock2 1/1/1024 }
>             |          |
>             |<...------+   2.05 Token 0xf0 Observe 1243 { 2.05 Token
> 0xf0 Observe abd NonBlock2 2/1/1024 }
> 
> Get final missing block
>             +--------->|   GET /path/ctrl Token 0xf2 { / NonBlock2
> 1/0/1024 }
>             |          |
>             |<...------+   2.05 Token 0xf0 Observe 1244 { 2.05 Token
> 0xf0 Observe abd NonBlock2 1/1/1024 }
> 
> 
> That should be not considered as "precise description of the application
> layer framing". It should just give a first impression, how coap
> standards could be used, and the specific stuff could be move to the
> application layer (reusing coap again).
> 
> best regards
> Achim
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots