Minutes IETF105: dots
minutes-105-dots-01

DDoS Open Threat Signaling (DOTS) WG Agenda
IETF 105

Wednesday, July 24, 2019
1000 - 1200, Morning session I
Room: Centre Ville

Co-Chairs: Valery Smyslov and Liang Xia

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

Ben: Med has a signal channel heartbeat mechanism topic, but not listed in the
Agenda. Chair: A little mistake that not updating the slides, already contained
in the actual agenda.

2. Summary of pending DISCUSS issues on the signal channel: HB, ... (10 min)
-presenters: (remote): Mohamed Boucadair/Tiru Reddy
- draft: draft-ietf-dots-signal-channel-36

Ben: Do we need to go through all of the slides for the entire room, they are
more intended for Mirja and me than the WG directly. Med: This tend to clarify
Mirja's concerns, but we also want show WG there is no change of the entire
functionality.

Ben: I talked to Mirja earlier this week and she wanted to make sure the design
met the needs we had and not just doing something convenient. I think we've
done the analysis and confirmed the design is the only one works. I think we
can talk with Mirja and get the discuss point resolved. I'm happy to find her
in person to do the explanation, or if you think we just should send her the
slides? Med: It's up to you. I prefer that you or Chair can talk to Mirja to
solve this. Ben: I'm happy to do that.

Kaname: I'm following the discussion on the mailing list and have no objection
with these assessments. I have tested the interoperability when using UDP. I'm
wondering if Jon could give some assessments about the interop when using TCP.
Chair: It's a good suggestion. Jon: I have done some tests about TCP and
heartbeat failures within my implementation, but it hasn't been totally
rigorous and hasn't been with an interop with Kaname's go-dots implementation.
It may be area for further testing. But the preferred protocol really is UDP.
Chair: Jon and Kaname have done a lot of good work on the interoperability
test. I encourage you both to do more tests about this typical issue. If you
have some results please send to the mailing list. John: Sure.

3. Controlling Filtering Rules Using DOTS Signal Channel (15 min)
- presenter: Kaname Nishizuka
- draft: draft-ietf-dots-signal-filter-control-01

Frank: As a contributor I have a question for clarification. Can you explain
why there is a need that sending the first mitigation request with ACL? Kaname:
When attack happens, the client tries to mitigate the attack, it also wants to
enable the ACLs installed by the Data Channel before. So we can enable both the
ACLs and the mitigation request. Frank: In the previous version, you haven't
mentioned this corner case. This goal is to activate the ACL right now when
sending the first mitigation request. Kaname: Yes.

Wei: If the first mitigation request with no ACL is processed successfully,
then sending an updated mitigation request with the ACL but the ACL is failed
to enforce, in this case it's not necessary to send a new mitigation request
without the failed ACL. Kaname: The ACL included in the mitigation request may
conflict with other situation, in order to continue the other ACLs the DOTS
client needs to drop the failed ACLs. Wei: The ACL may fail, but the DOTS
server can omit the failed ACLs and do other things. If you send a new
mitigation request just without the failed ACL, no new things will happen.
Kaname: The DOTS client realizes the failure and can adjust the ACLs. Wei: If
the DOTS client can't fix the problem, it isn't necessary to send a new
mitigation request. Kaname: The 'must' is too strict. Wei: 'must' may be not
OK. Med: Response for Wei's comment. He's right about his observations.
Actually this case is only suitable for the situation that ACL is sent in the
first mitigation request or ACL is sent in a mitigation request whose
mitigation scope has also been changed. This is already covered in the text.

Chair: We think this draft is relatively mature. We can consider the WGLC on
the mailing list, anybody can comment and give feedback.

4. DDoS Signal Channel Call Home (10 min)
- presenter: Wei Pan
- draft: draft-ietf-dots-signal-call-home-03

Chair(Frank): Is the dedicated heartbeat mechanism totally same with the
heartbeat mechanism defined in the base spec? Wei: It's not totally same or
totally different. The DOTS roles reversed, so the processes for the DOTS
client in base spec is suitable for the DOTS server in call home scenario.
Chair(Frank): That's a difference of the direction, other parts should be
similar. Wei: I think yes, maybe Med can do more explanation. Med failed to
join the meetecho queue, Chair asks to leave this issue to the mailing list.

Chair(Valery): I think the terminology used is a bit confusing, for example in
base spec the DOTS server is in the upstream provider and the DOTS client is in
your own network, but in call home scenario the situation is different while
using the same terminology. Readers may be confused. Maybe you can invent some
new names to clearly distinguish this case, because base signal channel can be
co-located with the call home signal channel. Wei: I know what you mean, this
can be discussed on the mailing list with the authors later.

Kaname: The call home has two functionalities, first is the reversal of (D)TLS
layer and the related heartbeat mechanism, second is the expansion of the
source related information. I agree that the reversal of (D)TLS is required
especially if the DOTS server is behind the NAT. The source attributes can also
be used in the provider network. It only says that source-prefix must be within
the scope of DOTS server domain. But in the provider use case, the DOTS server
can be not the closest to the source. Wei: I got your point. For the call home
scenario, the source-prefix validating is mandatory, but for the base signal
channel this can be discussed later. Kaname: Second question. If the attacker
is behind the carrier grade NAT, then the attacker must be mapped from the
external address to the internal address, how the DOTS client knows which DOTS
server the attacker belongs to? Wei: That's a good question. In the call home
draft now it contains this situation, maybe Med can do more explanation.
Meiling Chen: In the call home scenario, the DOTS client may send mitigation
requests to many DOTS servers, is this another DDoS attack? Wei: Sorry, I
didn't get your point. Maybe we can discuss on the mailing list. Med: Trying to
answer the comment from Kaname. We have specified in the document how it can
access to the mapping information, and the information can help DOTS client to
identify the appropriate that server and supply the appropriate information to
this server. The document provides some examples how this interface can be
implemented at DOTS client. If you don't have the validation of the source
prefix, you may send mitigation requests to some servers which can't control
the attacker. For sending source prefix in the classic signal channel, the
validation is not needed. Kaname: Please clarify the validation is different
from the base signal channel and call home signal channel.

5. Server Discovery (10 min)
- presenter (remote): Mohamed Boucadair/Tiru Reddy
- draft: draft-ietf-dots-server-discovery-04

Chair: The draft needs a little bit polishing, especially for using normative
language in selection server discovery methods. Med: If you have any proposal,
please send it to the mailing list.

6. DDoS Mitigation Offload Usecase (15 min)
- presenter: Yuhei Hayashi
- draft: draft-hayashi-dots-dms-offload-usecase-01

Frank: As one of the co-authors of the use case draft, I have discussed with
the leading co-editor and we tend to agree that you have proposed some new
description of the existing use cases and it's not a big change. If our AD
permits, I think we can update the use case draft and then go to next process.
Chair: Question to AD, whether we need a new WGLC of the use case draft? Ben: I
think the use case draft is still early in the process. Updating the draft in 1
week will be OK.

Kaname: I'm not OK with the description and diagram of the use case, it's
confusing. I'll help you update the text and diagram.

Wei: First, how to distinguish the number of reflector is small or enormous?
Second, different kinds of information are sent in different kinds of attack,
so what are the references on which your conclusion based? Third, how to decide
the destination addresses that will be attacked in the future? I'll send to
mailing list for more discussion.

Chair: This is a valuable work, but it is very new, we can't make decision now,
we hope more people can review it and give comments.

Meiling Chen: I'm interested in your draft and I agree with your solution. A
question will be posted to the mailing list.

7. A method for dots server deployment (10 min)
- presenter (remote): Meiling Chen
- draft: draft-chen-dots-server-hierarchical-deployment-00

Wei: I've read your draft, I think it's a reasonable work and a good direction.
Other people may have the same difficulties that you encountered when you
deploy DOTS. You can highlight them and we can have more discussion. You listed
4 conditions, some are conspicuous (like the first 1), and some are also
requirements. You should find out the solutions, not just give another
requirements. The diagram of the network topo is also confusing because I
didn't find where the DOTS client is.

Chair: I feel like that your draft is more like a white book to describe how to
use DOTS protocols. Maybe you can clearly clarify what's your problem and
what's your new use case. And then we can discuss. Meiling Chen: I'll do it in
the next version.

8. DOTS client carry ddos attack information in signal channel (15 min)
- presenter (remote): Meiling Chen
- draft: draft-chen-dots-attack-informations-00

Chair: The next presentation about telemetry is similar with yours. Because of
the time reason, let's go to the next presentation first, if we have more time,
we can discuss these two drafts together.

9. Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry (15 min)
- presenter (remote): Tiru Reddy
- draft: draft-reddy-dots-telemetry-00

Wei: I agree with the motivations, and I support this work. The most important
thing is the use case of using telemetry. About the telemetry details, I will
comment on the mailing list.

10. WG next steps & recharter discussion (5 min)
Chair: Because of the time, we will discuss the recharter later with AD. We'll
put the discussion to the mailing list to let everybody know the progress. No
big changes, mostly is about the milestone and including the deployment
considerations in the charter.