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

[Jim Schaad <[e-mail]>]

I do not believe that there is anything today that says the observer is
required to do a GET to receive the next fragment in the event that it does
not care about what it says.   The question that sprints to mind is how
should the server/client decide that it does or does not want to retrieve
the entire content?

 

Jim

 

 

From: core <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, April 7, 2020 4:11 AM
To: [e-mail]
Cc: Jon Shallow ([e-mail]) <[e-mail]>;
[e-mail]
Subject: [core] Large asynchronous notifications under DDoS: New BLOCK
Option?

 

Hi all,

 

We are using Observe to receive notifications during attack events. These
notifications are set as NON messages for reasons specific to DDoS
conditions. 

 

With DDoS telemetry information included (see draft-ietf-dots-telemetry), a
notification may not fit one single message. The use of BLOCK2 is not
convenient during attack times. A full description of the issue is described
here:
<https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/>
https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ 

 

We are considering some mechanisms to solve this issue. One of them is to
define a new BLOCK option (similar to BLOCK2) that does not require the
observer to send a GET to receive the next fragment. The server will send
all the fragments. The observer will follow a SACK-like approach to request
retransmission of missing fragments. 

 

Please let us know whether you think this is a generic issue that should be
solved at the CoAP or not. Suggestions are welcome.

 

Thank you. 

 

Cheers,

Jon & Med