DDoS Open Threat Signaling (DOTS) WG Agenda TUESDAY, November 3, 2015 1300-1500 Afternoon Session I Room 501 SEC dots DDoS Open Threat Signaling WG Co-Chairs: Roman Danyliw and Tobias Gondrom Meeting recording: http://ietf94.conf.meetecho.com/index.php/Recordings#DOTS 1. Note well, logistics and introduction (chairs, 5 min) 2. Use Case Discussion (50 min) - draft-ietf-dots-use-cases-00 (Roland Dobbins, 30 min) - draft-nishizuka-dots-inter-domain-usecases-00 (Kaname Nishizuka, 10 min) - Additional use cases discussion (10 min) 3. Requirements Discussion (30 min) - draft-ietf-dots-requirements-00 (Andrew Mortensen, 20 min) - Additional requirements discussion (10 min) 4. Additional Drafts (40 min) - draft-reddy-dots-transport-01 (Prashanth Patil, 10 min) - Discussion (5 min) - draft-fu-dots-ipfix-extension-00 (Frank Xia Liang, 10 min) - Discussion (5 min) 5. Closing (5 min) ------------------------------------------------ 1. Note well, logistics and introduction ------------------------------------------------ Presenters: Roman Danyliw and Tobias Gondrom Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-0.pdf The agenda was approved without any changes. The chairs encouraged contributions of architecture text and solution-oriented drafts to inform the existing use cases and requirements drafts. To improve WG transparency the IETF issue tracker and likely github as a document repository will be adopted. ------------------------------------------------ 2a. Use Case Discussion: draft-ietf-dots-use-cases-00 ------------------------------------------------ Presenter: Roland Dobbins Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-2.pdf Q: (Stefan Fouant) Could you clarification why a relay is needed? A: (Roland Dobbins) A relay is used for aggregating requests/responses, implementing a filtering policy, or as a proxy between stateful and stateless transport ------------------------------------------------ 2b. Use Case Discussion: draft-nishizuka-dots-inter-domain-usecases-00 ------------------------------------------------ Presenter: Kaname Nishizuka Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-3.pdf * Comment: (Chris Morrow): I don't see distinct use cases depending on whether the upstream network is cloud-based or not. * Response: (Kaname Nishizuka) the difference is: one supplicant, multiple mitigators; and one mitigator, multiple supplicants. Currently this is a considerations for an NTT service, but it can be generalized into DOTS. There is a need to have a strong coupling of the DOTS server with DDoS mitigator. * Response: (Flemming Andreasen) The difference is traffic redirection. In the first use case, traffic redirection is not needed. For the second, traffic does need to be redirected to the cloud-based anti-DDOS service. (Tobias Gondrom): The second use case is related to the situation where two people are competing for the same resource (Roland Dobbins): Cloud-based anti-DDOS services means more provisioning works. They are important but not belong in DOTS. * Comment: (Robert Moskowitz) In talking about terminology, we must remember that the mitigator and mitigation are not in scope for DOTS. It can be on DOTS server or not, but this part of work should be done in I2NSF. DOTS is responsible for the signaling work between DOTS client and DOTS server. * Comment: (Roland Dobbins) WG use cases draft co-authors agree to combine some contents of this draft into WG use cases draft. Q: (Frank Xia) A centralized orchestration center (or broker model) should be considered as one possible use case; telemetry information step is also useful and maybe be specified in DOTS scope. Are you interested as an operator? A: (Kaname Nishizuka): We use various approaches for collecting information and triggering the DDOS mitigation: flow collector, web portal, firewall, etc. We also think provisioning is valuable that can be considered by DOTS. * Comment: (Flemming Andreasen) Another use case is when a user/application are in a cloud-based service. They don’t own their IP address space and it might be shared with other users. * Response: (Roland Dobbins) There are two ways for cloud-based application -- one is the DDOS mitigation service is provided by the cloud provider. The other may depend on the DNS to diverse the traffic. Q: (Flemming Andreasen) Is provisioning in scope for DOTS? A: (Roland Dobbins) some policy provisioning or registration belongs to I2NSF. We should discuss in details in requirements draft. * Comment: (Luyuan Fang): Two additional use cases: inter-provider, inter-cloud. The Microsoft cloud can tackle the DDOS attack to itself, but the interconnection between clouds can be easily attacked. Another interesting thing would be including capability negotiation, mitigation, report and monitoring and deep knowledge sharing. * Response:(Roland Dobbins): Agree, they are all important use cases. * Response: (Tobias Gondrom) Luyuan Fang can catch up with use case editors to check if her use case are written correctly. * Comment: (Robert Moskowitz) We have not yet done an important part of the DOTS work -- schema and data model for the DOTS messages. * Response: (Roland Dobbins) Agreed. That is important and should be included in the use cases and requirements drafts. ------------------------------------------------ 3. Requirements: draft-ietf-dots-requirements-00 ------------------------------------------------ Presenter: Andrew Mortensen Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-4.pdf Q: (Daniel Migault) Is IPFIX information in the data channel? A: (Andrew Mortensen): Considering white/black lists, configuration and mitigation scope and so on Q: (Flemming Andreasen) A good start. It seems to be missing a data model. Can an architecture draft be developed in parallel? A: (Andrew Mortensen) Agreed. A: (Robert Moskowitz) I encourage anyone to contribute to the data model content A: (Tobias Gondrom): The chairs and AD believe all this can be developed in parallel. A: (Flemming Andreasen) What are the plans for those documents? A: (Tobias Gondrom): WG chair hat off. I'd like to see several solutions and for them to be in separate documents. Q: (Eric Wang): How about QoS? A: (Andrew Mortensen): Currently considered as rate limiting. * Comment: (Roland Dobbins): Need to be consider how to avoid the situation that many attack source addresses are shared on the wire. * Response: (Andrew Mortensen): false negative or positive are the results. * Response: (Tobias Gondrom): An IPv6 address is very large. This would make this use case more interesting. * Response (Nik Teague) White lists are also important. * Response (Luyuan Fang) Need to consider IPv6 in more detail and in addition to the source/dst address * Response (Roland Dobbins) IPv6 is already considered in scope, and IPv4 has the same problem. * Response (Andrew Mortensen) Will do. Q: (Eric Wang) Are QOS issues considered? A: (Andrew Mortensen): Will consider. A: (Roland Dobbins) Should be part of the provisioning work. ------------------------------------------------ 4a. Additional Drafts: draft-reddy-dots-transport-01 ------------------------------------------------ Presenter: Prashanth Patil Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf * Comment: (Roland Dobbins) What you mentioned is more about the victim asset information, not necessarily related to the attack telemetry information. The DOTS client may not have attack classification capability. * Response (Prashanth Patil): It might simply notify "i am attacked, my address, my condition..." * Comment: (Wes Eddy) Don't use UDP. TCP is better * Response: (Robert Moskowitz): The choice of transport is a large discussion where any choice will be a compromise. We need to have a design session with transport mind on how to achieve this compromise. * Response: (Roland Dobbins) An important point. We need both stateful and stateless transport. Q: (Tobias Gondrom) Any suggestions on how to coordinate this issue with transport guys? A: (Wes Eddy): Ask for operator guys for a transport suggestion A: (Aaron Falk): The Transport Area meeting could be used to discuss this question. * Comment(Roland Dobbins) DOTS needs bidirectional transport to maintain the DTLS connection. * Comment (Nik Teague): As an operator, I feel that flowspec is very difficult to use. What the challenges do you see with using filtering rules on the device? * Comment (Robert Moskowitz): We need someone to tell us what is the useful data modeling information. Q: (Dave) Is DNS related? A: (Robert Moskowitz) DOTS client does not need DNS but a DOTS server and mitigator might. ------------------------------------------------ 4b. Additional Drafts: draft-fu-dots-ipfix-extension-00 ------------------------------------------------ Presenter: Frank Xia Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-1.pdf * Comment: (Chris Morrow) I've been working with Netflow since 2002 and am unsure of the unsolved issue proposed here. * Comment (Roland Dobbins) Echo Chris. There is confusion --there needs to be clarification on what should be done in the exporter, what should be done in the collector/analyzer. There is also a need to consider the performance aspect of using a device for flow-based monitoring. Discussion on an IPFIX extension is not needed if this is done at the collector. Is this Netflow vs IPFIX? * Response: (Frank Xia) The focus is on the sampled flows rather than the packet. Not sampling all the flows. * Response: (Tobias Gondrom) Discuss with big telco operators, they use Netflow, but IPFIX can offer you more rich and broad information, you may agree or you may not agree. * Response: (Roland Dobbins) IPFIX is even richer. Agree it can be extensible. Q: (Xiaohong): Have you done any research on the validity or feasibility of the approach? A: (Frank Xia) It was tested with operators with good results. It could detect most of the DDOS attacks. A: (Xiaohong): Not just mitigating. Should include inputs in the data modeling part of requirements from experimental result. ------------------------------------------------ 5. Closing ------------------------------------------------ An interim meeting will be held in late January or early February.