Minutes IETF104: dots
minutes-104-dots-00

DDoS Open Threat Signaling (DOTS) WG Agenda
IETF 104

Thursday, March 28, 2019
1050 - 1220, Morning session II
Room: Athens/Barcelona

Co-Chairs: Liang Xia and Valery Smyslov
AD: Benjamin Kaduk

1. Note well, logistics and introduction (5 min)
- presenters: chairs
Ben Kaduk: The requirements draft has addressed all the AD comments and I can
send it to RFC Editor. The signal channel and data channel should go on the
IESG agenda probably for April 11th. Roman Danyliw: I'm handling over Shepherd
responsibilities to Valery Smyslov. And the IPR check isn't done. Authors
respond on the IPR concurrence.

2. Controlling Filtering Rules Using DOTS Signal Channel (10 min)
- presenter: Kaname Nishizuka
- draft: draft-nishizuka-dots-signal-control-filtering-04
Chair: This draft is originated from the problems found by the Hachathon test.
I think this version is relatively mature from my personal idea. Med: This is
really a problem. It's better for this draft to not be included in the signal
channel specification. We give some use cases to illustrate how to use this new
attributes. Thanks to the reviewers and feedback. The current version is stable
enough for working group adoption. Roman Danyliw: The signal channel isn't
published, should we call back the signal channel and insert this draft into
it? Med: This is only a procedural problem. The extension of this draft is
simple that there is just one attribute. It's up to the working group to
decided it. Tiru: I like this proposal, but I would like more time to discuss.
Med: If we put this into the signal channel, then the signal channel will have
a normative reference to the data channel, it will cause a reference loop.
Chair: This draft opens a door for using signal channel to control information
originating from the data channel. Will more and more such things happen? Med:
I think the answer is no. We don't want to have similar functionality between
the signal channel and data channel. This is just one signal case. Chair: We
have a general consensus. Roman Danyliw: We are not going to update the base
spec, right? Tiru: I'm hoping so. Chair: More discussion on the mailing list.

3. Interoperability and Hackathon Report(s) (10 min)
- presenters: Kaname Nishizuka, Jon Shallow
Chair: About the interop test, what is the 10% left test that is not tested?
Kaname: The gateway function, redirection, Happy Eyeballs function. Maybe we
can implement these functions later and test them.

Kaname: Is a 'PUT + acl-list' allowed to create a new mitigation?
Med: Yes. The current draft includes such use case. There is no need to
restrict that the filtering update must be after the creation of mitigation.
Kaname: If sending 'PUT + acl-list' first, then this message should be treated
as mitigation request in attack time. Med: Yes. This is rational and current is
in the draft. Both cases that including the acl-list in creating request or
updating request are reasonable. Tiru: Yes. I agree with Med, there is no need
to restrict that. Chair: We are going to run out of time. Please send these
questions to the mailing list.

Kaname: Should it be treated as "protocol":6 even if no protocol number was
specified in the IPv4 or IPv6 section? Med: The DOTS server must check the
attributes sent from DOTS client are consistent. It's allowed if you don't
include the port number but it can be inferred from other attributes.

4. Multihoming Deployment Considerations (10 min)
- presenter: Mohamed Boucadair/Tiru Reddy
- draft: draft-ietf-dots-multihoming-01
 Tiru: The mid in forking cases may cause problems because different servers
 may return different results. I think we should try to avoid these scenarios
 because it will complicate the handling of aggregation of responses.
Chair: I have a personal suggestion. Can you give some general guidance for
which mechanism should be used in which use case? Med: We can't make a
recommendation at the network level. The draft is based on current multihoming
practices. Chair: Maybe you can provide a table in the last of the document and
do a summary of all the listed ways. Med: OK.

5. Server Discovery (10 min)
- presenter: Mohamed Boucadair/Tiru Reddy
- draft: draft-boucadair-dots-server-discovery-05
Roman Danyliw: Do apologize in the chair role for not closing the adoption.
Active chairs may fix that.

Tiru: If you have DNS Server Discovery, then you don't really need mDNS. You
can remove them.

Chair: Do you plan to update the current version and make it a working group
draft or use the current draft to be the working group draft? Med: I prefer
using the current draft to be the WG draft, and then taking some time to update
it.

6. Cooperative DDoS mitigation between the Home network and ISP (10 min)
- presenter: Tiru Reddy
- draft: draft-reddy-dots-home-network-03
Toma: The problem statement only abstract the word Home. Have you considered
changing the word Home to something different because this solution is also
useful for corporation networks. Tiru: It's definitely applicable to even
enterprise networks. The attacks on IoT can highlight the problem. The use
cases and scenarios could be various. Chair: This is a general solution and
applicable for many scenarios. How to clarify this in your draft? Tiru: We can
add a section to clarify this. Toma: The server discovery mechanism can be
different in home network and enterprise network. Tiru: It should be handled in
the server discovery draft.

7. DDoS Mitigation Offload Usecase (10 min)
- presenter: Yuhei Hayashi
- draft: draft-hayashi-dots-dms-offload-usecase-00
Chair: You are asking the working group to adopt your use case. But the use
case draft now is in Publication Requested status. Maybe AD can give some
advices. Tiru: This draft describes different use cases from the use case
draft, and it's some enhancements to the core specification protocols. But
'cuid' is supposed to be an identifier of the DOTS client, and it's not
appropriate for the DMS using to notify the orchestrator to offload the attack.
I think you should list all the methods to do the offload, and probably extend
the protocol, rather than overloading the 'cuid'. Med: This is not actually a
use case document and different from the current use case draft. It's an
applicability statement of the previous specification, and can help people see
the DOTS solution is deployable. Chair: So you want to bring something to help
us to clarify the deployable concerns. Med: This draft is important because it
uses DOTS to do the offload, which is not a extreme case, and coordinates with
other extensions to provide the service efficiently. Ben Kaduk: With AD hat.
1st, many working group drafts are basically done, you may put that as an input
in terms of your eventual goal. 2nd, the applicability statement is a technical
term in the IETF (RFC2026), so there would be a very stringent quality
threshold on such a document. Tiru: Maybe we need have a draft to provide a
deployment guidance for the people who want to deploy DOTS in their network.
Ben Kaduk: Thank you for having this work done. It's useful to write
descriptions of how people are doing.

8. Using Attack Type and Bandwidth in Signal Channel (10 min)
- presenter: Meiling Chen
- draft: draft-chen-dots-attack-type-expansion-00
- draft: draft-chen-dots-attack-bandwidth-expansion-00
Chair: What is the difficulty for you that different vendors have different
kinds of attack type? Meiling Chen: We have many vendors' equipment, we have to
manage them together, so coordinating is very important. Chair: Do you have
some specific example? For example, your network management system receives
different kinds of information but actually they are the same. Meiling Chen:
When vendor A provides HTTP Flood and vendor B provides TCP SYN Flood, we don't
know if they are the same and it will confuse us. Tiru: I think this draft
brings the DDoS telemetry back which has been discussed in the working group
couple of years before. I remember Radware had published a draft talking about
various telemetry details including bandwidth and attack types. The problem
with DDoS attack types was there were many attack types and there is no global
registry which can map all that types. If a vendor is incapable of handling all
the layers of attack then it's gonna be really difficult to handle even a
single DDoS attack which typically spans multiple protocol layers. Meiling
Chen: We can discuss on the mailing list. Tiru: We had discussed these problems
before and the working group had decided not to pursue them. Now you bring it
back, and maybe we should discuss this again. Toma: It's very hard to convince
all the vendors for a unified attack type naming. Maybe we just need to
maintain the mapping tables. For the zero day attacks, they are not in your
unified format, unifying its name maybe a year later. Why the 'protocol level'
is mandatory? Chair: Maybe you can discuss on the mailing list, because it's
running out of time. Wei Pan: The draft has two premises, one is different
vendors' devices have different capabilities, the other is they are good at
handling different kinds of DDoS attacks. The premises and motivations are
reasonable. The extension needs more discussion. Roman Danyliw: Thank you for
bring your use case here. In both drafts, if you can describe how you are going
to do the extensions, that will help talk through the taxonomy side of the
attack. I guess you will use the IANA registry proposed by the signal channel
to add the fields. Meiling Chen: Yes.

9. WG next steps (10 min)

10. Closing (5 min)
- presenters: chairs
Chair: Now we have some new work, for example the provisioning issues, new use
cases, new extensions. Please read these documents, give more comments and
discuss on the mailing list.