Re: [Dots] New Version Notification for draft-reddy-dots-telemetry-02.txt

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Wei,

Thanks for the detailed review. Please see inline

From: Panwei (William) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 30, 2019 8:04 AM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: New Version Notification for draft-reddy-dots-telemetry-02.txt


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Tiru,

I’ve read the new version, and I have some thoughts, please see below.

In Section 2, at the end of the definition of ‘DOTS Telemetry’, it says ‘The DOTS Telemetry is an optional set of attributes that can be signaled in the DOTS signal channel protocol’, I think DOTS data channel protocol is also a suitable candidate for conveying DOTS Telemetry in some cases. For example, you can use DOTS data channel to convey the “normal traffic baseline” information during peace time. And if there is an out-of-band link between DOTS agents, you can use DOTS data channel without problems like packet loss.

[TR] We would want to avoid two protocols to convey the same telemetry details. DOTS signal channel can used to signal the telemetry both during peace and attack times. The pre-mitigation telemetry attributes can be sent in a Confirmable CoAP request for reliable transmission.

About the “normal traffic baseline”, in Section 3, it describes learning the normal behavior by using the machine learning approaches and distinguishing the anomaly behavior deviated from the normal behavior. I assume the normal traffic pattern needs many characteristics to be profiled so that machine learning techniques are needed, but for now in the draft, the normal traffic baseline attributes are only 10%/50%/90% percentile and peak value of the whole traffic to the target, are those values enough for the anomaly detection?

[TR] Yes, these values provide normal baseline the mitigator needs to achieve during the attack mitigation.

Does the traffic baseline need to be categorized by protocol type?

[TR] Yes, will update draft.

Does some other attributes are needed, like the average and variance of the packet length?

Percentile is better than average, see https://www.elastic.co/blog/averages-can-dangerous-use-percentile and https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/

I think conveying normal baseline from the DOTS client to the DOTS server is used for the case that the DOTS server can proactively detect the attack in case it fails receiving the Mitigation Request. That is, when the DOTS server fails to receive the Mitigation Request sent by the DOTS client because the link is saturated by the attack traffic, but the DOTS server can still detect the attack by using this normal traffic baseline information sent by the
DOTS client during peace time. Based on this purpose, I think sending the alarm threshold is also a reasonable and optional way to achieve this purpose, and it can be more direct for using. The DOTS client can continuously and automatically calculate the alarm threshold by using the machine learning techniques, then it can send this alarm threshold to the DOTS server periodically or after the threshold changes. When the attack occurs and the DOTS server fails receiving the Mitigation Request, it can still recognize the attack if the traffic to the target exceeds the threshold for a period of time. The alarm threshold also can be protocol specific, so that it can be more accurate.

[TR] I don’t get the above comment, DOTS server will propagate the DOTS telemetry to the DDoS mitigator, and the mitigator can use telemetry to tune the mitigation resources and mitigation strategy.

About the ‘Total Attack Traffic’ and ‘Total Traffic’, for now the draft requires them to be statistical attributes. I think the statistical values are fine but shouldn’t be mandatory. For the case that the DOTS client immediately sends the Mitigation Request and the Pre-mitigation Telemetry together to the DOTS server once it realizes an attack has occurred, it can send the instantaneous ‘Total Attack Traffic’ and ‘Total Traffic’ without waiting some time to do the statistics. So I suggest making the statistical values and current values all available and optional, to let different DOTS clients choose what to send.

[TR] All the percentile values are optional. The DDoS attack typically evolves over time, signaling only the current value of attack traffic looks less useful to derive any meaningful hint on the nature of the attack to the attacker. If statistical data is not available, the current value becomes the peak value.

Section 4.1.5, Total Connections Characteristics, is designed for the resource-based DDoS attacks. But compared to the volume-based DDoS attacks, I think some other kinds of attribute are also needed.

[TR] Please suggest the other attributes.

The DOTS Telemetry attributes used for volume-based DDoS attacks can be categorized for 3 types: 1) The normal baseline (or the alarm threshold), which now is Section 4.1.1; 2) The capability information, which now is Section 4.1.2; 3) The current situation, which now is Section 4.1.3 and 4.1.4. But for the resource-based attacks, the ‘Total Connections Characteristics’ is just the capability information, I think the baseline information and the current situation can also be defined.

[TR] 4.1.2 is the total pipe capacity, which is the level of traffic the DOTS client domain can absorb from the upstream network. Resource-based DDoS attacks do not have any equivalent to pipe capacity. I think percentile values will be more useful than the current value for representing the attack characteristics, will update the draft.

For the attributes now in the ‘Total Connections Characteristics’, I think the ‘per client’ attributes should also support protocol specific, this support can be optional for the DOTS clients.

[TR] Agreed, updated draft.

Besides, what are the ‘partial requests’?

[TR] It means incomplete requests, see https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/

Cheers,
-Tiru

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

From: Dots [mailto:[e-mail]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: Thursday, September 12, 2019 12:55 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Dots] FW: New Version Notification for draft-reddy-dots-telemetry-02.txt

This revision https://tools.ietf.org/html/draft-reddy-dots-telemetry-02 addresses comments from Kaname, Jon, Wei Pan and Yuuhei Hayashi.

Major changes are listed below:

a.  Added path-suffix ‘telemetry’ to from the URI to signal DOTS telemetry
b.  Added attributes useful to detect resource-based DDoS attacks
c.  Attack details can be signaled from the DOTS client to server and vice-versa.
d.  Added several new attributes for attack details including top talkers.


Comments and suggestions are welcome.



-Tiru

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Thu, 12 Sep 2019 at 09:58
Subject: New Version Notification for draft-reddy-dots-telemetry-02.txt
To: Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>, Ehud Doron <[e-mail]<mailto:[e-mail]>>, Mohamed Boucadair <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-reddy-dots-telemetry-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-dots-telemetry
Revision:       02
Title:          Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
Document date:  2019-09-12
Group:          Individual Submission
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-telemetry-02.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-telemetry/
Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-telemetry-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-dots-telemetry
Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-telemetry-02

Abstract:
   This document aims to enrich DOTS signal channel protocol with
   various telemetry attributes allowing optimal DDoS attack mitigation.
   This document specifies the normal traffic baseline and attack
   traffic telemetry attributes a DOTS client can convey to its DOTS
   server in the mitigation request, the mitigation status telemetry
   attributes a DOTS server can communicate to a DOTS client, and the
   mitigation efficacy telemetry attributes a DOTS client can
   communicate to a DOTS server.  The telemetry attributes can assist
   the mitigator to choose the DDoS mitigation techniques and perform
   optimal DDoS attack mitigation.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat