IETF Logo Mail Archive

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

Achim Kraus <achimkraus@gmx.net> Thu, 09 April 2020 11:02 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE63A079E; Thu, 9 Apr 2020 04:02:41 -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 mEsKI7Ya9AQ9; Thu, 9 Apr 2020 04:02:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 EE64F3A079D; Thu, 9 Apr 2020 04:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586430146; bh=h1P50Hvtv9ADJsSJ/VxXUDORZDMBOHalIDCxrMeJZUU=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=YBhrsOAXUQ/4xkOdXfyEHojUs2haA5vryqLV3jKGLJLJLFYgwXfsjxt0xw2kZsY8I d8reproSYuj+zj3NAcylHrpnxTw6sek/3BL+zLSV5z/E/JgovGaMkAKu6DqrGrKUon uiLHtERBsT9rsk39eiH+wTmMyaLaIkHQ5Lqvhf1U=
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 1MoO2E-1iyUsk0cCu-00op0p; Thu, 09 Apr 2020 13:02:26 +0200
To: Jon Shallow <supjps-ietf@jpshallow.com>, 'Carsten Bormann' <cabo@tzi.org>, mohamed.boucadair@orange.com, dots@ietf.org, core@ietf.org
References: <787AE7BB302AE849A7480A190F8B933031490173@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> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.org> <031401d60e51$19baca20$4d305e60$@jpshallow.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <690a94f3-d50f-c5c6-da3b-a95c2d32e756@gmx.net>
Date: Thu, 09 Apr 2020 13:02:24 +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: <031401d60e51$19baca20$4d305e60$@jpshallow.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Ze/vsvsYxT+LNNK+++9/aGvSDNXJrNqaG9nu6If64oehfJVWRSq xTLXVU59DkE3v0JuGB4hpw7NdSqT/O/Z6jOCnDAyQZdxxM7g6E72KeJ198U9haHna+hewZZ VMRxsyzB+Fo++DxiTJXqrY+Vd9a1KK9TMcseV1KDMRFocV8eiSF7Wnto+NIYdr8tFmbuQCc amITnYOvL1SmJMHWEVgBw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2/x+jGJtVeI=:6LPY5eW4FaefwaZ9hLTHDl C7Sp5iX8F7az7yOb84Y5gIhTkrx4GFynIEYwCP3mFja/pRAJM/D/j5mvQk5HNIMZ3hA8SamA7 rZDZtyCnLsuyvCINjT/yhKTadRmNt+N/pG8O0UcmvMg87+9igUK1CvelbffmO/7Z4xEzt7RcV Jzz5H8RjFggWe9p/YIYNy8ghOkFC+tEdemtRz1O/WJyQQs2+6Psg2ppH5LdVGt67FYOvClhd6 HnFv6Z93S1yctxFTJKXv4Otr4n8foKgIxccYE1NseOCHm8UuUIXiLCt22K5fSpm9Ldhumrlbg BwOjLyvc/aF+VoCNffd+gm3WOu8GcwMYZKZU7YFKBpdOt/HljNzCBuW4KiK5Ymc/Hambj1Bdq /y4IoqXiEI4rgY6sFj343bZbnxRA6NsUsnix9DYFlLHk6u5rbXE6eZsP/tUMmWV4LvavPEnf5 CZMOpsfFbgUJwoFnLFXKPvmqvge7COX270feY1Lnn2/LIgLeFSn32tnKHMGQHk3PuwGMz9o+7 jhOt3nzOQuEUX/PnR4gT/6Ej1UDvwWDSSfyvzgL/GROgJX6MkwFfKpqJZuS9yt95t4h+tn8DO frfMOszWWLPkGxzsAnRhi2Tv1k34NkUoIR/4illvz2otHbwySL/TvWFmnMat7ZX4kc7K3IV/I oSFtyE4WO++2rAFp6YwVo1oLBqIArKKQy+VBW4LdAZQnSFDSXxekxakAAjILqfsc757XUahZF fGGGkfxaYnRBJHcwD7qnwyMYXI96BNpu1p/wu/8zf/+9yYIIPT93bEFzgDpuB3khWW9p+95NX /WPdyWRFQXgXNpzbLxe+lfC4pYmTIbHo4tXL1dceaYFxZC6qKt9G4eAC6V7fzvOPktEyvIJTW v5vknbL6zPLDp7LKStdlt1+QRoByXuWJzVtp0fSli14TaaNnRSFGnWl+LKuoiaQMnTcwHFtHZ GlWxJ0IOuFJJkmzifDDfEzJ5gqqYgvGItVDcqLhuwi0p4FEAoTkPlzR4kz7RiOPCU0TBcIG5N v8G75wpcz1gy1dJfGiQlJE+q3zUnEowezY7tVZ+H9DsOWIMgpL2jvqKSu97rGT8P/5OfoC23i gILdzulKXIy02Avu3aUvmjAhhOyU16i7GWImbD7R3MjjzAQsQukX9fY65xlimYznn1JkM1Cwj eu0FEr9m6KJyJ4x4ng7gvZO+SGCo3zf04vrLJJtjdDafuZh9yHow7k8/cgnMzuH6rosoqa2ga ptwRU6EFfBqGW4+x3
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/OlhDXZPOH6x_LWOgs-w8Jpc8yDs>
Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option?
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 11:02:41 -0000

Hi Jon,
Hi Med,

 > (1) The use of nonblock2 option with a "relax" of the behavior at the
server to send the fragments with the same token and without waiting for
GETs.

The point will be, how this relaxation actually looks like.
FMPOV, the hard thing will be:
The server MUST not make assumptions about the token, except that it is
copied from the clients request into the response.

Currently the followup blocks considered to have a empty token (Jon's
last note). That will hit any pending client requests with such a empty
token. The matching is considered to be done via the etag. But RFC 7252
defines the etag with:
"An entity-tag is intended for use as a resource-local identifier".
Though it's an resource local identifier, in my opinion, you can't use
that to relate your blocks. The right blocks may have that etag, but
others responses may have it as well (therefore "resource-local
identifier").
So, in my opinion, to know, to which resource the etags belongs to, the
related request is required. Usually matched by the token, but that
token is missing, because the client's request is missing.


best regards
Achim

Am 09.04.20 um 11:27 schrieb Jon Shallow:
> Hi Carsten,
>
> I stand corrected - a token with 0 length.
>
> Regards
>
> Jon
>
>> -----Original Message-----
>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Carsten Bormann
>> Sent: 09 April 2020 10:23
>> To: Jon Shallow
>> Cc: mohamed.boucadair@orange.com; dots@ietf.org; core@ietf.org; Achim
>> Kraus
>> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
>> New BLOCK Option?
>>
>> On 2020-04-09, at 11:20, Jon Shallow <supjps-ietf@jpshallow.com> wrote:
>>>
>>> With the new nonblock2 option, the non-head blocks can have no token
>>
>> CoAP messages always have a token.
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> Dots mailing list
>> Dots@ietf.org
>> https://www.ietf.org/mailman/listinfo/dots
>

v2.23.0 | Report a Bug | By Email