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

[[e-mail]]

Hi all,

Here is an update for this work conducted in core WG:


·         A second core interim meeting dedicated to the DOTS use case was organized last week. The minutes can be a seen at: https://datatracker.ietf.org/doc/minutes-interim-2020-core-06-202006101600/

·         The slides are available at: https://datatracker.ietf.org/meeting/interim-2020-core-06/materials/slides-interim-2020-core-06-sessa-coap-block-wise-transfer-options-for-faster-transmission

·         The plan is to target a call for adoption right after the IETF meeting.

·         The updated version of the block-wise spec was released early this week: https://tools.ietf.org/html/draft-bosh-core-new-block-04

·         As mentioned last time, we don't plan to add any normative text to this draft to avoid blocking the publication of the telemetry spec.

FWIW, we do use the following language in the draft. Note also, that we have considered other means to minimize the size of the messages (e.g. attack mapping).

======
4.5.  Block-wise Transfer

   DOTS clients can use Block-wise transfer [RFC7959] with the
   recommendation detailed in Section 4.4.2 of [RFC8782] to control the
   size of a response when the data to be returned does not fit within a
   single datagram.

   DOTS clients can also use CoAP Block1 Option in a PUT request (see
   Section 2.5 of [RFC7959]) to initiate large transfers, but these
   Block1 transfers will fail if the inbound "pipe" is running full, so
   consideration needs to be made to try to fit this PUT into a single
   transfer, or to separate out the PUT into several discrete PUTs where
   each of them fits into a single packet.

   Block3 and Block 4 Options that are similar to the CoAP Block1 and
   Block2 Options, but enable faster transmissions of big blocks of data
   with less packet interchanges, are defined in
   [I-D.bosh-core-new-block].  DOTS implementations can consider the use
   of Block3 and Block 4 Options.
======

Cheers,
Jon & Med

De : Dots [mailto:[e-mail]] De la part de [e-mail]
Envoyé : vendredi 29 mai 2020 15:13
À : [e-mail]
Cc : Jon Shallow ([e-mail])
Objet : Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option?

Hi all,

Please find below an update about this DOTS telemetry issue:


·         A proposal to handle the issue was made: https://tools.ietf.org/html/draft-bosh-core-new-block-00.

·         The core wg dedicated an interim meeting to discuss the proposal (May, 13).

o   The slides presented in the meeting ca be seen here: https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-interim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-core-new-block.

o   The minutes can be seen at: https://datatracker.ietf.org/doc/minutes-interim-2020-core-04-202005131600/.

·         An updated version to address the comments received from the core wg (and especially during the interim) is available at: https://tools.ietf.org/html/draft-bosh-core-new-block-01.

·         The current plan is to avoid adding a normative dependency to the telemetry spec.


We will report back to the WG as appropriate.

Cheers,
Jon & Med

De : core [mailto:[e-mail]] De la part de [e-mail]
Envoyé : mardi 7 avril 2020 13:11
À : [e-mail]
Cc : Jon Shallow ([e-mail]); [e-mail]
Objet : [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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.