DDoS Open Threat Signaling (DOTS) WG Minutes IETF 103 THURSDAY, November 8, 2018 0900-1100 Morning Session I Room: Meeting 1 Co-Chairs: Roman Danyliw and Liang Xia Minute Taker: Wei Pan 1. Note well, logistics and introduction ======================================== presenters: chairs slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-chairss-summary-02 The chairs summarized recent activities of the WG and the status of the drafts. 2. Interoperability and Hackathon Report ======================================== presenters: Kaname Nishizuka, Jon Shallow slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00 Kaname Nishisuka presented the results of interop testing from the IETF 103 Hackathon. Comment: (Tiru Reddy) You should try DTLS/TLS 1.3. Per Slide #7 Q: (Flemming Andreasen) After the client losing heartbeat from server, will it try to contact another server? A: (Jon Shallow) If the server can't receive heartbeat response from the client but can receive the heartbeat request, it can still regard the client alive, and do the mitigation. A: (Flemming Andreasen) One incorrect action may be the client concluding to initiate a new DTLS session to the DOTS server or a new server, but it will not succeed. A: (Jon Shallow) The client should using the existing channel whenever he's doing any requests, and it should try to set up a new session. The spec doesn't mention about an alternative server. Per Slide #9: Comment: (Flemming Andreasen) Option 1 makes sense. About option 2, if it works, then why wouldn't it work over the data channel? A: (Tiru Reddy) Option 1 is good, you should propose a draft about it. A: (Roman Danyliw) Take more discussion on option 1 to the mailing list. Comment: (Jon Shallow) TLS 1.3 has been published out. DTLS 1.3 isn't out yet. Everything in the interop was done with either TLS 1.2 or DTLS 1.2. A: (Ben Kaduk) DLTS 1.3 is in working group last call. 3. Server Discovery =================== presenter: Tiru Reddy* draft: draft-boucadair-dots-server-discovery-05 slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-server-discovery-and-multi-homing-considerations-00 Tiru Reddy presented a draft that describes multiple approaches for DOTS server discovery. Comment: (Frank Liang Xia -- as individual) In this draft, you have several ways to do the server discovery. It seems you extend some existing protocols and you have specific extension for these protocols. A: (Tiru Reddy) The only extension is for DHCP restore. Q: (Frank Liang Xia -- as individual) There are some guidelines or rules for using the other existing protocols to do the server discovery, right? A: (Tiru Reddy) Right. A: (Frank Liang Xia) We should be careful about the specific protocol extension. I personally think we can have more discussion on the details. Comment: (Flemming Andreasen) I think the overall problem space makes sense, we do need to solve this. A: (Roman Danyliw -- as individual): +1. This will help people use DOTS, and I support this work moving forward. 4. Multihoming Deployment Considerations ======================================== presenter: Tiru Reddy* draft: draft-boucadair-dots-multihoming-04 slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-server-discovery-and-multi-homing-considerations-00 Tiru Reddy presented a draft that describes deployment considerations for DOTS in a multi-homed environment. Comment: (Roman Danyliw): As background, this draft was created to describe multi-homed considerations originally in the use case, architecture and requirement documents. WG consensus was to remove this text and publish it as a separate document. (Roman Danyliw) How many people have read these two drafts? -- No many. -- Take discussion to the mailing list. 5. Cooperative DDoS mitigation between the Home network and ISP =============================================================== presenter: Tiru Reddy* draft: draft-reddy-dots-home-network-00 slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-cooperative-ddos-mitigation-between-the-home-network-and-isp-00 Tiru Reddy presented an additional use case for DOTs in the home network environment. Q: (Wei Pan) When NAT is on-path, the source address of the outgoing traffic will be translated to a random external IP address by the NAT equipment, so how do the DOTS client find the correct DOTS server? A: (Tiru Reddy) ISP assigns IP addresses or prefixes to the home networks, so ISP is aware of from which home network that the traffic is outgoing. Comment: (Roman Danyliw -- as individual) I like this use case. I recommend you include language in the privacy section to discuss what will and won't get leaked to the ISP about the internal home network. Comment: (Kaname Nishizuka) I support it. There may be a discussion about this in a IPv6 use case. I think attack name/id conveyed by DOTS client is diagnostic, the home routers may not be capable of handling emerging sophisticated attacks, so I don't think such information is required. (Tiru Reddy) It's just for diagnostic purpose. Comment: (Frank Liang Xia -- as individual) This is a rarity use case. To achieve this goal, the home network gateway which is a very limited device should support DOTS server function. This is different from our previous design, so I have some confusion about it. I also think the solution reflects the idea that we need to do some near source attack mitigation, and this is the key point of this draft. We have some other similar cases, like datacenter or branch network. A: (Tiru Reddy) I think this solution is going to be useful for various other use cases, and we can definitely update the draft. For some vendors, we are adding a lot of capability to the home router, like limited IPS function, IOT firewall function, etc. DOTS server on the home router is not a public DOTS server, it is only for the intended DOTS client and there is going to be only one DOTS connection, so the home router will not be overwhelmed. A: (Frank Liang Xia) It will be very useful if you can provide more evidence or observation from your side about this possibility in the mailing list. A: (Tiru Reddy) Sure. Comment: (Martin) I like the point previous speaker made with the key aspect of mitigating attacks closer to the source. There are some countries where a net neutrality imposes quite strict restrictions on what a telecom can do on home user. I think it would be wise to tailor the functions on home gateway very strictly to the use case of DDoS mitigation, but not for the generic firewall or some dpi work, so that it may have a better chance of getting deployment in such countries. A: (Tiru Reddy) I totally agree with you. We didn't want to blindly block the traffic. This is pretty much specific for DDoS and we don't want to be used for other purposes. 6. DDoS mitigation offload usecase and YANG module expansion in signal channel =============================================================== presenter: Yuhei Hayashi draft: draft-h-dots-mitigation-offload-expansion-00 slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-ddos-mitigation-offload-use-case-and-yang-module-expansion-in-signal-channel-draft-h-dots-mitigation-offload-expansion-00-00 Yuhei Hayashi presented an additional use case for DOTS with an orchestrator. Q: (Roman Danyliw) Does the orchestrator wait for the network administrator to take action? A: (Yuhei Hayashi) I divided the draft. Q: (Tiru Reddy) Why the DMS must use DOTS to talk to the orchestrator? A: (Yuhei Hayashi) I will discuss this on the mailing list. Q: (Kaname Nishizuka) How many source IP addresses can be included? A: (Yuhei Hayashi) In the draft now is 10, but not concrete. Q: (Flemming Andreasen) Is it worthwhile to standardize the communication between the DMS with the orchestrator? Why use signal channel to do that? A: (Yuhei Hayashi) I will discuss this on the mailing list. A: (Jon Shallow) When DMS has the trouble in pipe, it sends dots session request up to the orchestrator, and the orchestrator can mitigate upstream what's taking place. Comment: (Martin) The use case seems really helpful. 7. WG next steps ================ The chairs solicited feedback from the WG on interest in new work items. No new items were raised. The remaining time was spent on open mic: Q:(Kaname Nishizuka) Are there any connection among the server discovery, multihoming consideration and the call home? What about server discovery in local home use case. A:(Tiru Reddy) There is a connection between all the three. Nowadays many of the home routers come with multiple interfaces and do support multihoming. The home router needs to initially discover the DOTS server. These three are not independent. Comment: (Martin) I have a question for Yuhei on the mitigation offload use case. I'm wondering if the signaling of what the client perceives to be attack traffic and the offloading use case are actually bound tightly together or whether they are good ideas on their own. A: (Yuhei Hayashi) Thanks for your feedback, I will send revision to the mailing list. Comment: (Ben Kaduk): I want to apologize to everybody that the AD review on the signal channel and data channel are taking so long. I expected to be done sooner. Comment: (Markovski) I apologize I haven't been in this working group before. The new research group SMART has some overlap with DOTS. People who are interested in SMART can join the planning meeting this evening. Q: (Tiru Reddy) I have a question about DOTS implementation. I'm wondering has anyone considered any mechanism for the crypto mechanisms & identities provisioning of DOTS client and server for mutually authenticating each other. Any one has any insights on it, or we should discuss it on the mailing list. A: (Frank Liang Xia) You can do this on the mailing list. If we have enough interest, we can do this kind of work. Also for today's individual drafts, I think they all make sense, but we need more discussion and comments. (Lawrence Muchilwa) I want to volunteer my time to anyone who might need help with implementation. 8. Closing ========== The chairs summarized the WG discussion.