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

mohamed.boucadair@orange.com Thu, 09 April 2020 11:26 UTC

Return-Path: <mohamed.boucadair@orange.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 168CB3A0878; Thu, 9 Apr 2020 04:26:11 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 yYXCYuuNuvr7; Thu, 9 Apr 2020 04:26:10 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1243A0873; Thu, 9 Apr 2020 04:26:09 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48yf3M6Qbwz7trf; Thu, 9 Apr 2020 13:26:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586431567; bh=gu9+tMqXpZbTqRYxt5n/LCfz6WnW61OC3B9F54tv5bU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GBBNtw2ZZ0Q1aS9FrBOrSvRUZjYKi/KSLQEYmBxcDql7BxE78ubR+cVK8CpMKPPUT MRslqZu5cRA2SLm8gp9hbQ4gKWBAPxui6I9f0WwE5R9qFTyb+uDIbgz0k0PxvxmjnS OnDig0PmCgydzJI6l4JUBxf3WcmDrnY84dXeZlHHFqi77o6XsTtFGYeMrB7E+vJd43 WjQ8K0mRyvtLcEZPFo3VmgozDPBiY8fnUEQOLLyyWx9ibo158SpKSuqrythplPx/tP MdUSvVZl9fCp+o00yUflR/Sh+00BhGSYDX5BBp1v9/99C7R2vOv95dDEXvd/OOnfpU NblJhIsLECXew==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 48yf3M59qtz3wbY; Thu, 9 Apr 2020 13:26:07 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Achim Kraus <achimkraus@gmx.net>, Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option?
Thread-Index: AQHWDmGp8pB8W/bxlka28WEpcZ+N6A==
Date: Thu, 9 Apr 2020 11:26:07 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303149236D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9B3883A4-9662-4E04-8FC3-00864928E801@tzi.org>
In-Reply-To: <9B3883A4-9662-4E04-8FC3-00864928E801@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ZUIExMfl6O5bFZnXbTHYPnwgEI8>
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 11:26:11 -0000

Re,

(1)

We don't have an issue with other CoAP proxies as we use a distinct port number for DOTS.

(2)

For the pure CoAP case, the newBlock options will be marked as critical and unsafe to forward. There is no caching issue for a proxy that does not understand the option. GET with this option will be rejected by the proxy. The server will reject requests with the newBlock if it does not understand it. This is simple. 

For a proxy that supports block options, the blockwise spec does not impose to have all fragments. The spec leaves it open to implementations: if we don't have a loss, all fragments will be present. The proxy can be serve clients with individual blocks. 

We won't require all fragments to be reassembled at the proxy. We just need individual blocks. For example, if the client-proxy leg is lossy, the proxy can serve immediately the client with missing blocks. This will be part of the new behavior (which is fine given that these proxies are assumed to support the option).

Clients can determine the initial block size in initial newBlock. If the server does not like it and wants to send back a reduced size, that would be fine and the client would see one of the newBlock with smaller size and know to ask for the smaller sizes. 

I agree that we need to further assess this carefully but we are not sure yet there is an issue with regards to caching.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:cabo@tzi.org]
> Envoyé : jeudi 9 avril 2020 11:27
> À : 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?
> 
> Hi Med,
> 
> thank you for updating me on this information!
> 
> On 2020-04-09, at 09:56, <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com> wrote:
> >
> >> (b) the semantics of observe is that a notification is the whole
> new
> >> state of the resource.  Proxies will implement it that way.  Of
> course
> >> block2 modifies this semantics a bit, so nonblock2 might do that
> too.
> >> Still, I think we need to consider what proxies (or client caches)
> >> will make out of the mechanism we devise.
> >
> > [Med] Agree for the generic CoAP case.
> >
> > For the particular case of DOTS, sessions are established hop-by-hp
> when a proxy (we called it, gateway) is involved. We have the full
> visibility on what happens.
> 
> So you have application-aware proxies (which may not even be CoAP
> proxies).
> 
> But that doesn’t mean other proxies aren’t involved; there is also the
> matter of client caches, which have similar properties (caching, but
> no multiplexing).  So far, we have tried to keep the proxy/client-
> caching concept valid with extensions on CoAP; this would be the first
> one where we would have to say “no CoAP proxies can be used”.  I was
> wondering whether we can avoid this situation (can = don’t make the
> solution too complex).
> 
> Grüße, Carsten