DDoS Open Threat Signaling (DOTS) WG Agenda
IETF 106

Friday, November 22, 2019
12:20-13:50, Morning session II
Room: VIP A

Co-Chairs: Liang Xia and Valery Smyslov

1. Note well, logistics and WG & individual drafts progress (10 min)
- presenters: chairs
Chairs: Clarify the WG Drafts status.

2. DOTS telemetry related Hackathon activity report (10 min)
- presenter: Kaname Nishizuka
# About the normal traffic baseline
Kaname: Propose to use DOTS to send normal traffic metrics.
Tiru: IPFIX Telemetry is designed to convey traffic metrics and most devices support IPFIX, so there is no need to re-invent.
Kaname: Partial agreed. But by using DOTS, the information can be easily combined into the context of DOTS.
Tiru: IPFIX can use a template for defining the telemetry attributes and the template can be easily changed. IPFIX has many advantages.
Frank Xia: Agree with Tiru. To Kaname, do you want to use DOTS to do the things that IPFIX can already do?
Kaname: Yes.
Frank Xia: If the information is related to DDoS, it may be conveyed in DOTS. We need to consider carefully the information.

# About the S-to-C pre-mitigation telemetry
Tiru: We have updated the draft to accommodate the S-to-C pre-mitigation telemetry.

# About the percentile calculation
Kaname: The percentile calculation needs to consider the period of time and time granularity.
Tiru: This's a good question. You should raise a comment and we'll fix it as an issue. Time granularity is useful for Flash Attacks, Period of time is for normal traffic baseline.

# About the terminology "request"
Tiru: We'll update the draft to give definitions of the terminology.

# About the machine learning approach
Wei Pan: For the machine learning (ML) approach page, do you mean the Client does the ML, sends data to the Server and Server does the ML again?
Kaname: No, the Client sends the raw data and the Server does the ML to calculate the baseline.
Wei Pan: Make sense to me. Please send more background information about the ML and what data to be transmitted on the mailing list.
Tiru: Raw data can be collected by using IPFIX etc., no need for DOTS to do that.
Kaname: Will discuss more on the mailing list.

3. Update on active WG drafts (15 min)
- presenter: Tiru Reddy
- drafts: draft-ietf-dots-multihoming-02, draft-ietf-dots-server-discovery-05, draft-ietf-dots-signal-call-home-06
draft-ietf-dots-server-discovery-05: WGLC is over, the draft is waiting for the write-up
draft-ietf-dots-signal-call-home-06: WGLC is over, the draft is waiting for the write-up
draft-ietf-dots-multihoming-02: No update since IETF 105, have a list of pending changes proposed by Wei Pan, Next is going to integrate the above inputs

4. DOTS Signal Channel Heartbeat mechanism update (15 min)
- presenter: Tiru Reddy
- drafts: draft-ietf-dots-signal-channel-38
Ben: Double-check the text of the 'alternative approach'.
Tiru: It's already in the draft. It's a normative text saying that we must follow the transmission guidelines.

Chairs: Does the new heartbeat mechanism have some introduction about using reliable channels.
Tiru: Yes. For the reliable channel, we also use the same DOTS heartbeat message, the TCP transport will take care of retransmissions.
Chairs: Is it written in the draft?
Tiru: Yes.

Chairs: To AD, what to do next for this draft?
Ben: Just do a one-week WGLC about the changes.

5. Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry (15 min)
- presenter: Tiru Reddy
- draft: draft-reddy-dots-telemetry-04
Wei Pan: I've asked whether to use Data Channel for Telemetry, your answer was to just use Signal Channel. Now, do you change the design?
Tiru: Prefer just using Signal Channel, but I'd like to discuss more on the mailing list.
Valery: By using Signal Channel, more content may cause the message more difficult to be received by the Server at attack time.
Tiru: Right, but we assume Data Channel won't work at attack time. So at peacetime, both are OK. But at attack time only Signal Channel can be used. We can separate the DOTS telemetry and the mitigation request into two messages.

Hum for adopting this draft:
   Strong Hum + Jon from Jabber
Hum for not adopting this draft:
   Week Hum (Silence)
Chair: Will confirm on the mailing list.

6. Assessment of DOTS Telemetry Spec (10 min)
- presenter: Yuhei Hayashi
Kaname: Attack-detail module and pre-mitigation module need to be used together because the attack-detail contains the source IP and the pre-mitigation contains the target IP.
Tiru: DOTS Telemetry includes both the target IP and source IP/prefix.
Kaname: Target IP, source IP, and bandwidth are in different groups or containers.
Tiru: You can send mitigation requests separately rather than grouping them.
Ben: Source IP addresses may be a large amount, source prefix is better. How much coalescing there is?
Yuhei: Only send top-talkers, maybe 100 or 1000 attackers.
Tiru: For the large scale of DDoS attacks, it would be a group of source prefixes to be the top-talkers.

Wei Pan: The use case for telemetry is useful. One more use case: The normal traffic baseline sent in pre-mitigation telemetry can be used by the DOTS server to judge whether attack happens at the DOTS client side, and the Server can actively notify the attack and arrange the mitigation actions when the mitigation request failed to reach the Server.
Tiru: Normal traffic baseline and bandwidth can be sent during peacetime. Only attack-details need to be sent at attack time.
Wei Pan: Do you want to write a DOTS telemetry use case draft?
Yuhei: Yes, we have some use cases to write.
Chairs: It's a good direction to go. Be quick.
Tiru: Agreed. We need a DOTS telemetry use case draft.
Chairs: It's better for reading to put the use case into the telemetry draft.
Tiru: Works for me. But it depends on how large the use case draft is.

7. WG next steps & recharter discussion (5 min)
Chairs: Clarify the recharter text.
Ben: It's worth going forward with the recharter.
Chairs: Will send the new charter on the mailing group for discussion.

8. Closing (5 min)
- presenters: chairs