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

[[e-mail]]

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:[e-mail]]
> Envoyé : mardi 7 avril 2020 23:19
> À : Achim Kraus
> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; [e-mail]
> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> Hi Achim,
> 
> On 2020-04-07, at 21:04, Achim Kraus <[e-mail]> 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