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.