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

Achim Kraus <achimkraus@gmx.net> Wed, 08 April 2020 18:55 UTC

Return-Path: <achimkraus@gmx.net>
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 601CE3A159A; Wed, 8 Apr 2020 11:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 ruaTMxiHblU4; Wed, 8 Apr 2020 11:55:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5E73A1591; Wed, 8 Apr 2020 11:55:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586372142; bh=+TzULiD74WI8wkxBqsYv0FmnN2kwxxrujy32RSlBzPY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=AbpoYRzjuFhHgw7NyhMqFI8OtE/E46hSVGtsm97A61ii9G4NSBQlDIMDb3F8VZeCE EK8++KM4SDW97hqILoucyG7lIpg0JNg+jvb78iY0ReIiYjaH/5dtalBv+g6wfxhIXQ 0n0eTesGansDi8V1tTpVK27BA4pRHHnfNvfgkp8U=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M8QS2-1jQdaA1vPc-004X5Q; Wed, 08 Apr 2020 20:55:42 +0200
To: Jon Shallow <supjps-ietf@jpshallow.com>, 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>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <f105cf6a-da87-d8da-35db-07975f064a94@gmx.net>
Date: Wed, 8 Apr 2020 20:55:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:4k/xm6lt2zUB7W70blU/VMByqCsYPeYkm0oy2+Oha9FafG/x2JT /du1fhh1qMwUorqqHSgmeQp9kgsqYLs3b9wrjnmTivgvvksD1JG4q2eJQo3H+A+BPNSdQSj Z9+9QTq3v4AC+9OjnW3S67F0rR/5tlTL4Ly0g2mQIzW0eHNvWdwbqMgHpAGYxnGiHlBAqYZ PVXCk3VN15QOKuLOb/LBg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4W4smXEaV7k=:2BF8nafOVKttV+BikgPx6w fyRVksXL0eEypllR7aZh7OeAX3Hd63dt3l0WDoo0GI8IdVYOeJwof2PzRNpoYuCa5kWx0yxf6 kePtG8dTcVeoZjIwULFFBHfm6apbch1d2+wS7FzyDIx7u+cwd6ffO7mL4qJZglIIaXaC0za4h 81V7jhiEMpzadbQPWpB51Ht2ux2W85RJ31NcJhOcsog6IXAI442VL3JlKgojRqvL8AVjY8vk0 5TnV/4u53fiZSbWvk79Pw+BhAjiWB4F9obonGSRUi20Y+fmkSK3IugVkDiObR/+v7VR9INKIL lDrl0OhXwOPp4FlSsDDbF/TaxSW3dAC61kR22wkaekFL4TkWifi9RNnUID/opQka1LwDqQ3Je 54TKYNGCrBxVz/Z6IgQoCXpMphsC/ZXW9I3tpH3hhIzubPyLnQpi8RhysVjt+j9tblFMlahkd dJfeGT2JSKPAYCvNk829LTaogsc+C/YvItC1ygjAOAD7mzL5ok2cb8c0E5JBInBsv4NecviNU wNoLcR1GeOembuhux/VaIotZjlDjax5+CVOuBBzo6as6IsqyfAy4AL7/2vrQ661YazW1z4BXa 3o8rrAQM3DHSuKsbQc/2PkUTuPBHqqhJQif4+IUTEOahZ2Tk/KGMnRzVnwf5fe7UpeNebJc6c IJFZzB3Hl7hwu+KNinLsAXZVD626QopDFdvgIlvWEDiJwcCBi01WNF4GFbAzi2vGvozEvhFAa mN0Vyv0vvpKYyVXBaaC9jJSYelb+69Id30ImgRH66jjUijJllUY2kRdQdIE2IdrLHwOW1Papj IIwscO7fS2WgX0boa1HlvBgmPQ+mG3HpC3JJzTZHn3u1KbTZvu9i6SSxsBrdG73o3MDQKlXaZ 9H3aU7K0ltsXIho7L+5FeF35SuLAU7E/IWKmd5aL+d+ghMKQ1NV5Ou+zDbw7VpbC06IYkWNTO 1URTEdRIWIpDh2BXouau8KdobTUVzNgBN8PMGZueL2T1w8L5gGsU2iL+B/sv0aUHuC4gNsFdI OF2Le+c4ySpXCWsacslyIzdfoyM3Ojx5zWkn2YMYVt1SIYc0GjHJRKfGUe8+U254WgEAKYTrx BkXaP3tLr7YiQPiYx0yIxz0RiJClX7W9lrFPvyiclEcw3sZC1pnaLU49vOShTCLJ/1BALge4i vOFHJrNus54z5LHGF0gIqm5FUch2ULHaNi+ulXwu7DqBvOv+RzKlJm6eaPwcwHDSoulAHJiEs O6wS3yLX1XLpG6T1C
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/_X2Lvp4yEif3XdfJNZK8vVsPEdE>
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 18:55:57 -0000

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