Minutes IETF106: dots
minutes-106-dots-00

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