Minutes IETF105: dots
|Meeting Minutes||DDoS Open Threat Signaling (dots) WG|
|Title||Minutes IETF105: dots|
|Other versions||plain text|
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.