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

[[e-mail]]

Hi Jim,

That can be policy based at the client side + some signal to the server.

For our DOTS application, clients indicate to servers that they are (not) willing to receive all the content (below an excerpt of our spec):

   DOTS clients that are interested to receive pre- or ongoing mitigation
   telemetry (pre-or-ongoing-mitigation) information from a DOTS server
   (Section 8.2<https://tools.ietf.org/html/draft-ietf-dots-telemetry-06#section-8.2>) MUST set 'server-originated-telemetry' to 'true'.

And


   In order to signal telemetry data in a mitigation efficacy update, it

   is RECOMMENDED that the DOTS client has already established a DOTS

   telemetry setup session with the server in 'idle' time.


Clients can filter out data they are interested in (Uri-Query), e.g.,.


   Header: GET (Code=0.01)

   Uri-Path: ".well-known"

   Uri-Path: "dots"

   Uri-Path: "mitigate"

   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

   Uri-Path: "mid=12332"

   Uri-Query: "target-alias=https1"

   Observe: 0

If not filter is included, all the content has to be returned to the client:


   Header: GET (Code=0.01)

   Uri-Path: ".well-known"

   Uri-Path: "dots"

   Uri-Path: "tm"

   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

   Uri-Path: "tmid=123"

   Observe: 0



    Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications

                           for a Specific 'tmid'

What is missing for us is a "BLOCK2"-Like option to send all fragments without waiting for a GET + retrieval of missing fragments (if any).

Cheers,
Med

De : Jim Schaad [mailto:[e-mail]]
Envoyé : mardi 7 avril 2020 17:19
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Cc : 'Jon Shallow'; [e-mail]
Objet : RE: [core] Large asynchronous notifications under DDoS: New BLOCK Option?

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/

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