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

Jon Shallow <supjps-ietf@jpshallow.com> Wed, 08 April 2020 19:25 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 1266B3A0C73; Wed, 8 Apr 2020 12:25:33 -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 ytJWUFKROziv; Wed, 8 Apr 2020 12:25:30 -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 6703D3A1615; Wed, 8 Apr 2020 12:25:29 -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 1jMGK8-0007To-5f; Wed, 08 Apr 2020 20:25:20 +0100
From: "Jon Shallow" <supjps-ietf@jpshallow.com>
To: "'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> <1cdc0e70-7e72-ef52-66e7-1d2056367fbf@gmx.net>
In-Reply-To: <1cdc0e70-7e72-ef52-66e7-1d2056367fbf@gmx.net>
Date: Wed, 8 Apr 2020 20:25:25 +0100
Message-ID: <02ae01d60ddb$74255190$5c6ff4b0$@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+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hAZCEAcyonF/o4A==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/NuIz7QoQLUaD_9dzYF7JHIFmOEY>
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: Wed, 08 Apr 2020 19:25:33 -0000

Hi Achim

Thanks for this good feedback.  Please see inline Jon>
[I have just seen you sent an update which I will look at shortly]

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus
> Sent: 08 April 2020 17:00
> To: Jon Shallow; mohamed.boucadair@orange.com; cabo@tzi.org;
> dots@ietf.org; core@ietf.org
> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> Hi Jon,
> 
> a "clear" answer will be hard to give, without actual experience of such
> special communication situations. FMPOV it would require some
> experiments under your assumed conditions to find answers.
> 
>  From your diagrams, I would conclude:
> - best, if the transfer works without sending messages back
> - to fill gaps, sending messages will be acceptable
> - both together, should then provide a "good enough" solution.
> Yes, experiments may show, that it works "good enough", or withdraw it
> (because the drops are too high).

Jon> Yes
> 
> To some details of your sequences.
> Observe/Notify is defined in
> https://tools.ietf.org/html/rfc7959#section-3.4
> 
> - the follow up / next block transfers usually don't contain the observe
> option, only the "head".

Jon> My mistake - only head should have the observe option.

> - the follow up / next block transfer don't need to share the token with
> the head, they use the tokens defined by each requests.

Jon> Fair enough.  I was just using the 0xfc in Figure 13.

> 
> In your scenario, there will be no "next block" request, and so you
> reuse the observer "token". There maybe implementations, which fail
> receiving follow up blocks, with observe options and the token of the
> observer request.

Jon> Is this still true if Observe option is only in the head?  I would be using Etag.  The head observe triggered block is the same as with BLOCK2.

Jon> The GET for the missing responses would have Etag so we can be sure we are asking for the right thing.

Jon> The initial GET that sets up the observe subscription deliberately uses NonBlock2 so only client and servers that support nonBLock2 will use it.
> 
> Therefore your approach would require at least a implementation
> according that special interpretation, but will not work with all "RFC
> 7252-7641-7959" compliant implementations, because for me it adds
> special conventions.

Jon> Removing the confusion about Observe option, I am struggling to think of other reasons why it may not work - but I am on a rapid learning curve here.
~Jon

> 
> best regards
> Achim
> 
> Am 08.04.20 um 12:41 schrieb Jon Shallow:
> > Hi All,
> >
> > Thanks for all your input so far.  It has helped my thinking, but I still do not
> have a clear answer yet as how to best do this for the DOTS specific situation
> as well as more general use cases.
> >
> > Below is a more graphical way of trying to describe what is happening and
> how it may be possible to overcome some of the limitations of using
> BLOCK2 in a lossy traffic environment (caused by DDoS attacks).
> >
> > Regards
> >
> > Jon
> >
> > Primary packet loss is from Server to Client
> > [Server is DDoS mitigating out in Internet, Client is on premise, DDoS flood
> against client]
> >
> > GET followed by Observe response - all working - as we would do it today.
> >
> >         CLIENT      SERVER
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Observe 0
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 Block2 0/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Block2 1/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 Block2 1/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Block2 2/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 Block2 2/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Block2 3/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 Block2 3/0/1024
> > Observe triggered
> >           |<---------+   2.05 Token 0xf0 Observe 1235 Block2 0/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf1 Block2 1/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf1 Observe 1235 Block2 1/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf1 Block2 2/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf1 Observe 1235 Block2 2/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf1 Block2 3/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf1 Observe 1235 Block2 3/0/1024
> >
> > Confirmable ACK responses not displayed, nor Etag, Size2 or Maxage.
> >
> > Now with some packet loss.
> > Observe triggered
> >           |<---------+   2.05 Token 0xf0 Observe 1236 Block2 0/1/1024
> >           |          |
> >           +--------->|   GET /path Token 0xf2 Block2 1/1/1024
> >           |          |
> >           |   X<-----+   2.05 Token 0xf2 Observe 1236 Block2 1/1/1024
> >           |          |
> > Timeout
> > Retry if Confirmable
> >           +--------->|   GET /path Token 0xf2 Block2 1/1/1024
> >           |          |
> >           |   X<-----+   2.05 Token 0xf2 Observe 1236 Block2 1/1/1024
> >           |          |
> > Retries continue - eventually timing out and possibly killing CoAP session.
> >
> > Communications can be locked out for 90 seconds as CoAP NSTART is 1.
> >
> > [DOTS uses NON-Confirmable for protocol reliability, not traffic reliability]
> >
> > If not using Confirmable, then the Client needs to time out at the
> application layer and retry, but can only go forward 1 block at a time (does
> not have to be in sequential order).
> > Server may need to garbage collect on resource with Etag.
> >
> > What may help the situation (but client can decide when current
> Etag/Maxage is no longer valid and stop continue requesting, and server
> may still need to garbage collect)
> >
> > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on
> client doing GET to get the next block synchronously.
> >
> >
> >         CLIENT      SERVER
> >           |          |
> >           +--------->|   GET /path Token 0xf0 Observe 0 NonBlock2 0/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024
> > Observe triggered
> >           |<---------+   2.05 Token 0xf0 Observe 1235 NonBlock2 0/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1235 NonBlock2 1/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1235 NonBlock2 2/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1235 NonBlock2 3/0/1024
> > Observe triggered
> >           |<---------+   2.05 Token 0xf0 Observe 1236 NonBlock2 0/1/1024
> >           |          |
> >           |   X<-----+   2.05 Token 0xf0 Observe 1236 NonBlock2 1/1/1024
> >           |          |
> >           |   X<-----+   2.05 Token 0xf0 Observe 1236 NonBlock2 2/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf0 Observe 1236 NonBlock2 3/0/1024
> > Client realises blocks are missing and asks for the missing ones in one go
> >           +--------->|   GET /path Token 0xf1 NonBlock2 1/0/1024 NonBlock2
> 2/0/1024
> >           |          |
> >           |   X<-----+   2.05 Token 0xf1 Observe 1236 NonBlock2 1/1/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf1 Observe 1236 NonBlock2 2/1/1024
> > Get final missing block
> >           +--------->|   GET /path Token 0xf2 NonBlock2 1/0/1024
> >           |          |
> >           |<---------+   2.05 Token 0xf2 Observe 1236 NonBlock2 1/1/1024
> >
> > Obviously the 3 second minimum for RTT calculations needs to be
> maintained so that the Attack situation is not made worse.  However, I think
> it acceptable that all the NonBlock2s for a particular data set are all sent as a
> stream.
> >
> >
> >
> >> -----Original Message-----
> >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange.com
> >> Sent: 08 April 2020 10:56
> >> To: Carsten Bormann
> >> Cc: Jon Shallow; dots@ietf.org; core
> >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> >> New BLOCK Option?
> >>
> >> Hi Carsten,
> >>
> >> We are also considering how to solve the issue at the DOTS level. The
> good
> >> news is that we are not blindly overriding pieces of data that are received
> in
> >> distinct responses. We have some checks to update an active record. But
> as
> >> mentioned by Jon, there are some challenges as well.
> >>
> >> With regards to the network environment, the direction of the attack is
> the
> >> same as the one from servers to clients. That’s said, telemetry data can
> be
> >> exchanged in both directions:
> >>
> >> * from client to servers: using a dedicated telemetry message or in an
> >> efficacy update shared with the server when a mitigation is active. This is
> >> done using PUT messages.
> >> * from servers to clients: telemetry data can be sent in dedicated
> >> notification messages or as part of the mitigation status update. Both rely
> >> upon GET+Observe. Having a mechanism to ask for gaps would thus be
> >> helpful.
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Carsten Bormann [mailto:cabo@tzi.org]
> >>> Envoyé : mardi 7 avril 2020 23:19
> >>> À : Achim Kraus
> >>> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org
> >>> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
> >>> New BLOCK Option?
> >>>
> >>> Hi Achim,
> >>>
> >>> On 2020-04-07, at 21:04, Achim Kraus <achimkraus@gmx.net> wrote:
> >>>>
> >>>> FMPOV, the first thing to ensure is, that the "large payload" gets
> >>> split
> >>>> into "application blocks", which could be processed even when other
> >>>> application blocks are missing.
> >>>
> >>> Indeed, “application layer framing” comes to mind here; that is always
> >>> a good idea if it cannot be ensured that all messages make it or if it
> >>> is good to be able to process messages while still waiting for others.
> >>>
> >>>                       .oOo.
> >>>
> >>> I’m trying to understand the very specific network environment that we
> >>> are targeting here.
> >>> Are we assuming packets are way more likely to make it from the server
> >>> to the client than the other way around?
> >>> That indeed would call for additional capabilities that base CoAP does
> >>> not have.
> >>> We also may not really care about congestion control much in a
> >>> situation of massive (attacker-induced) congestion (although that
> >>> might be misdiagnosed, so some care is still required); which would be
> >>> another reason to maybe deviate from base CoAP.
> >>>
> >>> I don’t have a design in mind at the moment.  It would need to cater
> >>> for the fact that sending the other response messages for the request
> >>> would be on the initiative of the server.
> >>> So observe (with non-confirmable responses) is maybe a good model
> >>> indeed; what’s missing is some way to ask for gaps.
> >>>
> >>> I just resubmitted a draft that we have been discussing for a while in
> >>> T2TRG:
> >>> The Series Transfer Pattern (STP)
> >>> https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html
> >>>
> >>> This has some discussion that may be relevant here, although it does
> >>> not address the specific DOTS problem.  I think it would be great if
> >>> whatever we come up with to solve this problem would also be a step
> >>> forward on the larger class of applications needing the series
> >>> transfer pattern.
> >>>
> >>> Grüße, Carsten
> >>
> >> _______________________________________________
> >> Dots mailing list
> >> Dots@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dots
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots