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

mohamed.boucadair@orange.com Thu, 09 April 2020 07:56 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 23EFE3A0E49; Thu, 9 Apr 2020 00:56:24 -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 AaFqjLhTmwdA; Thu, 9 Apr 2020 00:56:22 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F203A0E7F; Thu, 9 Apr 2020 00:56:18 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 48yYPD6ChPz2xdY; Thu, 9 Apr 2020 09:56:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586418976; bh=OqvPY1iJf9feuGUREsp4Iyj6RVPKjsqogttI9S1f9zU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b4aAR0z+ZSLMyfA68Go+P2y5Aq4S6kNHSBTq2y/NyUEPg+BqdREIQGDYlj0+xutk+ C/J51QRZA6R0gCEFjHZJuJGnd5c/TNQY5F+1FFsSxQX3+d8bU3e/QXffpyyAR+vIAN Wp04KanzJTUG0w086IsASVvNYpR4ql97o0kAF4G0ywDMs1k1o5RiyQOJReUYqW1um+ c5d0yvHL+SEdVs4DvdGfoGKpAb3QBJXHmWl01eMuVWYzrRcI3eNiKhE/ep4UwztNIz JPaor6FmkOUQIDMElidp6iubrcyO9QxTjDEmtr5wdyTryPbm8NcXwcyGe0FQZwxGta pe7pafuloOzxw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48yYPD4qJMzCqkv; Thu, 9 Apr 2020 09:56:16 +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: AQHWDkRYLU3u6qNWEkiODvNJMBEeOw==
Date: Thu, 9 Apr 2020 07:56:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330314921C3@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>
In-Reply-To: <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@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/aHiuTBIjiRyN_OjV8OOeqM8xRnQ>
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 07:56:26 -0000

Hi Carsten,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:cabo@tzi.org]
> Envoyé : jeudi 9 avril 2020 09:18
> À : 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?
> 
> I apologize in advance for chiming in before having digested the whole
> thread.
> 
> I think that the idea of using observe with a modified block-wise
> protocol (1 below) can work.
> 
> I also think that application-layer framing (3 below) is useful.
> 
> I don’t see a contradiction between the two; they might be used
> together.
> 
> I would like to know how to handle two sub-problems here:
> 
> (a) using non-confirmable responses without additional requests brings
> us into PROBING_RATE territory.  What is actually the rate at which
> this exchange is supposed to happen?  Do we have other ways to manage
> capacity of the response path (a.k.a. congestion control)?  I.e., how
> does the server know which rate (e.g., for pacing) it should use for
> sending further messages?

[Med] 

(1)

Probing rate is negotiated during idle time between the client and server:

      probing-rate:  The average data rate that must not be exceeded by
         a DOTS agent in sending to a peer DOTS agent that does not
         respond (referred to as PROBING_RATE parameter in CoAP).

(2)

The probing-rate used in idle time may not be the same as the one using during at attack time. We do a value for each of them.

(3) in addition, we negotiate this additional "guard":

   DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
   messages to the same peer more frequently than once every 'telemetry-
   notify-interval'

> 
> (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.   

> 
> Grüße, Carsten
> 
> 
> > On 2020-04-09, at 09:01, <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com> wrote:
> >
> > Hi Achim,
> >
> > First, I was not looking to "make your example buggy". I was trying
> to understand how this would work without requiring changes to the
> base specs. Your feedback is highly appreciated and very useful. Thank
> you.
> >
> > So far we have three approaches:
> >
> > (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.
> >
> > (2) The use of a shim application as you suggested, which requires
> an update on the server side but also on how clients on how to fill
> the gaps (use of PUT/FETCH).
> >
> > (3) A DOTS specific approach to build its own chunks and signal
> blocks as part of the CBOR. These blocks are handled as atomic
> notifications. If a block is missing, the client can use GET+Query to
> retrieve the gap. We don't require any modification at the base CoAP
> specs. The issue with this one is to decide what data to put in the
> blocks to avoid that when a block is passed to other layers, the
> overheads won't lead to fragmentation.
> >
> > It seems to me that (2) is a little bit more complex vs (1).
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Achim Kraus [mailto:achimkraus@gmx.net]
> >> Envoyé : jeudi 9 avril 2020 08:00
> >> À : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann
> >> Cc : Jon Shallow; dots@ietf.org; core@ietf.org
> >> Objet : Re: [core] [Dots] Large asynchronous notifications under
> DDoS:
> >> New BLOCK Option?
> >>
> >> 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
> >>>
> >