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

Achim Kraus <achimkraus@gmx.net> Thu, 09 April 2020 05:59 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 F19503A0BCC; Wed, 8 Apr 2020 22:59:49 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1TL6C_rQ1Pxq; Wed, 8 Apr 2020 22:59:48 -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 2DA453A0BC9; Wed, 8 Apr 2020 22:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586411973; bh=aXFWUQ0Cr6fxk0IGCpDmkoQWM5981h3kBu7yCNoRQMA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LQbbfh36o5LVWE+zV+SIS6wlLuV4dkS96kLiwz9ml+Y8MTjmzpsWkO8ya2UsloLso 40UxqYKcWNeDWciiKHhoKup8QY+RH6V16v2rPDFTrDMaDGcgfw9HtjXpKJ+eUIsGQf JiCg+j5zbrfMu8TiZrjzrOxsrsDIfNWzxGVkL9Fg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([94.216.236.121]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N17UW-1jAlKx0SEM-012UrP; Thu, 09 Apr 2020 07:59:33 +0200
To: mohamed.boucadair@orange.com, Carsten Bormann <cabo@tzi.org>
Cc: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>, "core@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> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net>
Date: Thu, 9 Apr 2020 07:59:32 +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: <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:9XDp1UYzXrQfeaF+LvqFzOFzZd5Dn9Vy/MPB+Lm2Oye3ysxl6tf 45bImYiY1Tmoz1XniOsIBB+9uuo7oxn7XfvbaSV1xT+EMuernutthuEXKmozcifO4turuBM aaJeTkYPwA1HANlEwO1EXLPRlQHov0hb6fuF5s10opn8VJjfFl7kRsoMK1inEWH8hPWBUzo a6AGKIrPUvplCiBGEQexQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ynX/RHIi/kc=:Teu0umPj0Ezj/CqYH0CDDc 53w4SfosFEjPfM08xb4pRFl/V5DXVX4U3de3rmZZjM4dOeU1dxAwC/XlmfKc/5YnqVwbo9cgb xRKtrloXkIDQrKg77+IFGYMG7T8jbKhgN17QroXS3GtTgK1mUtWzVzYGfIJKA1Z45fgJ2kGgf T52IrWunW5LFYGaPq1xZs0U6uFYHtWAenmx4n/xOPuHM/BP+m06vyJANyR9KjYLmwXxybgPLv D34xAPGdzmnPozczfcDfaoRV+jcDs/xMeMe7f0DvqI+phqL+YLg7OmJqoSG/2eBpBUlq2v66B AdDzWbOG64VZg5nBX4vnvoebyneXyNS4k3FfKdD5OVO283SLo+ZMr4R6xlN+6HGc1n3OtWotz Z4UdyuBrIzOHWgJX4SUrY1HJWyYMg9vWZZyAUQd1gBZL8i4vbbKKFdC12sYPbN1gQTyx3YTok KAnGFbkqJntwTgV46ja4vUIjhO+efUG8P/8p1ji2eAKH4k6qEMi7lnxBmotHQ4H5g3uFUVfWd iwnHrJSSnfoEg5HkKxk1+cC/O6b9WH7EWnsCXCEnTjC2uP+vblkZifvjCzGXg8JPzP/g6cFrh paZehMaeJqOuyIb8pm9b3pDYKrxTlLuucEonG4K7XD2f10xbSOj8KC2/l74OEusbMckfKIIni mh5Y03+xOB7NZKN2PMgYhqWaojBSqGWmZ+P4yNdADlGl89kbqKVjQI5xwA8QgDK59lzVi747y 5fqy8GQePWtm0bFf9hOwp7KlU/hI/ElGBdS+NQXYMaU45TA2sng+Sku/1BNii6lB9J004p/Qy 7gxHU5S0vpAlBpTeFKFH9TpyS/8aB/Tl0la9RC5ftOwm2w2yFJ+JKCjC/YAJ5msjCEJ8WM5D9 9gYqV78hI3BB4T/ANWbVZMAWhhL0WYebvOTPRyn8RWtsttW22iMGkYB6+XmcAxjgdQLPoggjO zi0KK18HmzoXKrkJeo0lrZjCh25CzlvzfDEdFVz4x1ZmnA2FJ2AlZX2Lqd34dytL1KjC8DEoR S06UzrIHbVtyLOJvPwR3x0jHrvjhVsN+KGoqV2q3zCXwth1nM75aDRZ+xKF0XAssqNh12fxf2 +MANLa4QnITDdrGuhGlrTLmfEGZprOXohBEdrzQkrz2mZJK5qi2A5k+SxAmGGiM3t1IMHye2l qsqS5aa6mz2e01q9nBJ4hzWzEDTSFJOq8j2vW1PO/5xD2hNehekdaLkJc1pvakXRArwHVzZjr 31jEG//xi/yDOioMU
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/njx1q-XaCqTJRsn__-mq7ZRRRPE>
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: Thu, 09 Apr 2020 05:59:50 -0000

Hi Med,

maybe, we have a different understanding of the CoAP principles.

RFC 7252:
single request-responses are matched by their tokens, chosen by the
client. The server must include that token in it's response and must not
make assumptions about it.

RFC 7641:
single request - multiple responses are matched by their tokens, chosen
by the client. The server must include that token in all responses and
must not make assumptions about it.

RFC 7959:
multiple request - multiple responses are used to transmit a large
resource using the principals of RFC 7252/7641.
RFC 7252 each single block transfer matches the single block request
with it's single block response by a token chosen by the client. The
server can not assume, that the tokens of several block-requests are
related.
RFC 7641 "single request - multiple responses" applies only to the head.
the download of the left blocks doesn't reuse the token, nor is the
server allowed, to make assumptions about the token.

=> you can't send the follow up blocks, because the token to do so is
not defined. It would have been defined by the (missing) client request.
If the token of the observe is used, the server makes a assumption and
relate request of RFC7959, which are not related by the token.

Therefore I asked also about the usage of observer/notify. If a PUT/POST
is used, then your transfer looks just pretty much as a blockwise with
NSTART-X. The drawback there will be the missing "blocksize" negotiation
at the head. If that is acceptable, it should have a chance comparable
to the proposal.

The NonBlock2 solution is not bad on it's own, but it disrupt the
principals for the tokens on the server side, at least in my understanding.

---------------------------------------------------------------------

 > One clarification question:

 >>             +--------->|   GET /path/ctrl Token 0xf1 { NonBlock2
 >> 1/0/1024 NonBlock2 2/0/1024 }

 > Do existing CoAP implementations (libcoap, for example) support GETs
with a payload?


I know, it looks a little unfair to point on single items of other
example and then make buggy examples on my own :-). But I already admit
"That should be not considered as "precise description of the
application layer framing"".
In fact, there is no outer GET required. The outer request could also be
POST.

              +--------->|   POST /path/ctrl Token 0xf1 { GET /path
Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 }


Just to mention, that this request triggers the notifies with the
missing block is "application layer convention". You may use whatever
definition you want to tell the server to (re-)send notifies with
blocks, there is no need of that inner GET request.

---------------------------------------------------------------------

best regards
Achim

Am 08.04.20 um 23:22 schrieb mohamed.boucadair@orange.com:
> Re-,
>
> Thanks, Carsten.
>
> This would mean that legacy CoAP implems do not support the coap-in-coap proposal without modification (given that rfc8132 support will be required).
>
> Actually, I'm struggling to understand what problem is solved by defining the NonBlock2 option but use it only with an extra coap layering.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Carsten Bormann [mailto:cabo@tzi.org]
>> Envoyé : mercredi 8 avril 2020 23:08
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Achim Kraus; Jon Shallow; dots@ietf.org; core@ietf.org
>> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
>> New BLOCK Option?
>>
>> On 2020-04-08, at 23:04, <mohamed.boucadair@orange.com>
>> <mohamed.boucadair@orange.com> wrote:
>>>
>>> Do existing CoAP implementations (libcoap, for example) support GETs
>> with a payload?
>>
>> That is what FETCH is for.
>>
>> Grüße, Carsten
>