Subject: [Dots] /mitigate RE: New Version Notification for draft-ietf-dots-telemetry-05.txt

From: <[email-masked]>
Date: Fri, 3 Apr 2020 13:39:20 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : vendredi 3 avril 2020 13:51
> À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname
> nishizuka; [email-masked]
> Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> 
> Hi Med,
> 
> Thanks for this.  It looks as if it might be going in the right
> direction - I need to check if it can be sensibly coded up.
> 
> 
> /mitigate
> ========
> 
> The use of Queries would work here for any GET /mitigate (telemetry
> extension) so that the responses can be controlled despite the target
> definitions used for the PUT mitigation request.  Again, (because of
> packet size limitations when under attack) do we need total-traffic-
> protocol etc.?

[Med] Only aggregates are sent to avoid fragmentation. 

> 
> The mitigate augment needs to be the same as for /tm from total-
> traffic onwards (with the CBOR mapping including ietf-dots-
> telemetry:).

[Med] yes.

> 
> If server-originated-telemetry is set and there is an active tmid,
> then responses include telemetry information
> 1- Do the responses get sent out at telemetry-notify-interval
> intervals (assuming Observe active)?

[Med] No, telemetry-notify-interval sets the minimum to be respected to avoid overloading the peer with telemetry updates. 

> 2- Why does this have to be with a tmid active - surely the tmid
> response and telemetry response will be containing the same data?
> 

[Med] Are you referring to the following:

   In order to make use of this feature, DOTS clients MUST establish a
   telemetry setup session with the DOTS server in 'idle' time and MUST
   set the 'server-originated-telemetry' attribute to 'true

This is not about having a tmid active, but configuring the support of telemetry notification to avoid errors during mitigation.

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Apr 2020 15:17:02 +0100

Hi Med,

See inline Jon>

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
> Sent: 03 April 2020 14:39
> To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
> Subject: [Dots] /mitigate RE: New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 

Jon> What about the use of Uri-Queries to filter on what is returned for a GET?
> [Med] No, telemetry-notify-interval sets the minimum to be respected to avoid
> overloading the peer with telemetry updates.

Jon> Hmm - OK.  So we continue with whatever the signal channel logic thinks is  appropriate which is implementation independent as per
   Due to the higher likelihood of packet loss during a DDoS attack, the
   DOTS server periodically sends attack mitigation status to the DOTS
   client and also notifies the DOTS client whenever the status of the
   attack mitigation changes.  If the DOTS server cannot maintain an RTT
   estimate, it MUST NOT send more than one asynchronous notification
   every 3 seconds, and SHOULD use an even less aggressive rate whenever
   possible (case 2 in Section 3.1.3 of [RFC8085]).
> This is not about having a tmid active, but configuring the support of telemetry
> notification to avoid errors during mitigation.

Jon> You are correct - this is the reference, but I had misread it.
~Jon

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots