* 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 —  

IETF-104 dots minutes

Session 2019-03-28 1050-1220: Athens/Barcelona - Audio stream - dots chatroom


minutes-104-dots-00 minutes

          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
          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
          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
          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
          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
          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
          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
          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
          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.

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