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

Jon Shallow <supjps-ietf@jpshallow.com> Thu, 09 April 2020 09:20 UTC

Return-Path: <supjps-ietf@jpshallow.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 B8A7B3A0FAE; Thu, 9 Apr 2020 02:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ow2Ts_g4OOi4; Thu, 9 Apr 2020 02:20:08 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8B13A0FAC; Thu, 9 Apr 2020 02:20:07 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1jMTLt-00088T-U6; Thu, 09 Apr 2020 10:20:02 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: 'Carsten Bormann' <cabo@tzi.org>, 'Achim Kraus' <achimkraus@gmx.net>, 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> <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>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 09 Apr 2020 10:20:06 +0100
Message-ID: <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hARxTHZMC0HZFVAKjGHtxAlevT3QCBQxhygLPG8JrqDvpP+A=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FqtTrwXsHC3h1ESUMblpEr2INh8>
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 09:20:11 -0000

Hi Achim,

Some clarifications on your excellent comments - I now understand the thinking behind the Token usage.

Please see inline Jon>

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
> Sent: 09 April 2020 08:02
> To: Achim Kraus; Carsten Bormann
> Cc: Jon Shallow; dots@ietf.org; core@ietf.org
> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> 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.

Jon> With the new nonblock2 option, the non-head blocks can have no token, so no assumptions need to be made about the token.  Etag however will need to be used for association of the nonblock2 chunk with the correct data set.
> >
> > => 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.

Jon> Again, by not having a token for the non-head blocks, this issue is resolved I believe.

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

Jon> Yes, certainly the server can initiate a PUT/POST back to the client (I like this outside of the box thinking).  

Jon> However, for me this breaks the spirit of Observe in that whenever a resource changes, all the subscribers are currently notified with a unsolicited response - here it is using a POST/PUT instead.

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

Jon> So, if the principals of Tokens is solved (by not having them!) then this may work.

Jon> On further reflection, as this sending all the blocks stuff can also be done in the other direction, I think a better name for nonblock2 would be block4 (server to client aka block2) and block3 (client to server - aka block1).  Bloc4 and block3 can be NON-Confirmable or CONfirmable.

~jon

> >
> > ---------------------------------------------------------------------
> >
> >  > 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
> > >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots