* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dots Status Pages

DDoS Open Threat Signaling (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2015-Jun-26 —  
Chairs
 
 


IETF-105 dots minutes

Session 2019-07-24 1000-1200: Centre Ville - dots chatroom

Minutes

minutes-105-dots-01 minutes



          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.
          
          



Generated from PyHt script /wg/dots/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -