------------------------------------------------ DDoS Open Threat Signaling (DOTS) BOF Minutes ------------------------------------------------ Tuesday, March 24 2015 1520 - 1720 CDT, Afternoon Session II Venetian Chairs: Russ Housley and Roman Danyliw Note taker: Takeshi Takahashi 1. Logistics, agenda bashing, introduction of BOF (chairs, 10 min) 2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min) 3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min) 4. Panel discussion on suitability (40 min) - (moderator) Nik Teague - Rich Groves - Vince Berk - David Larson - Andrew Mortensen - Ramakant Pandrangi 5. Further discussion (30 min) 6. Closing (chairs/AD, 5 min) ------------------------------------------------ 1. Logistics, agenda bashing, introduction of BOF (chairs, 10 min) ------------------------------------------------ Presenters: Russ Housley and Roman Danyliw Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dots-2.pptx The agenda was approved without any change. The purpose of DOTS, expected outcomes and relationship to other WGs was introduced. The following questions need to be answered: 1. Do we understand the problem space sufficiently? 2. Does this problem need standardization?? 3. Who is willing to contribute to this IETF effort? 4. How should this work be done in the IETF? ------------------------------------------------ 2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min) ------------------------------------------------ Presenter: Nik Teague Draft: draft-teague-open-threat-signaling-00 Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dots-3.pptx The presenter provide the further details on the motivation for the BOF and the specifics of a draft that presents and approach to address these challenges. Q: Brian Trammel: Please confirm that we are going to use IPFIX over UDP here. A: Nik Teague: Yes. Q: Daniel : Are there any example of the dictionary definitions and thresholds etc.? A. Nik Teague: There is a dictionary definition example in the draft. Q: (Cisco): The information channel when under attack is mainly between CPE and service provider. That customer would likely want to get feedback about the mitigation through that same channel. A: (Nik Teague): Yes, that is very true. I call it a heartbeat. It is a heartbeat in a day-to-day operation, but during the attack, the channel will be an UDP, lossy, anyway, but will maintain feedback from upstream provider. To sum up, you are right. Q: (Frank Shaf, Huawei): According to the presentation, CPE can use IPFIX channel to send the attack type information to the cloud based server. Can you clarify what you mean by CPE here? CPE should have anomaly detection functionality, correct? A. (Nik Teague): We are talking about a security device, specifically for DDoS mitigation device. You likely have a DDoS mitigation device in your network. DOTS is envisioned to use when upstream help is required to mitigate the attack. Q: An IPFIX tunnel is used to transport the attack type information in your draft, but the fields appear to be beyond current IPFIX functionality. A: (Nike Teague): IPFIX will be extended through custom templates. Comment: This is a nontraditional use of IPFIX. Chair Facilitation: (Roman Danyliw): From the discussion to date, the CPE is roughly defined as a specialized DDOS mitigation device. If there is any discomfort with this scope please make your concerns known. Q: (Brian Stefan): It is great to see "SOS" bit here. In terms of thresholds, part of values for having different CPEs and different cloud providers, isn't it provide different control systems? A: (Nik Teague): Yes. Q: Given that, what is the value of specifying thresholds? A: (Nik Teague): This should be an option for the operator. The CPE should be able to evaluate which threshold need to be exchanged. Defining threshold for the other organization needs to be done carefully. Q: Is there any idea or possibilities that those devices can be linked further? For instance, a service provider and DDOS mitigation device can talk to upstream providers, and implement a sort of push mechanism? A: I don't see why not. You could chain them. Q: (Kathleen Moriarty) There has been prior work to address the same issue, such as RID in INCH WG but it did not take off. Why do you think this work will be different? A: We have some good supports and feedbacks from various vendors and operators in this field. They generally said that this is something they want. Comment: (Brian Trammel). I love seeing somebody using the extensibility of IPFIX. Why aren't you using the existing information elements? Also, when you are under attack, using IPFIX over UDP is a terrible idea, because you are not get any of your data out at all. There is a profile for IPFIX over SCTP, it is not very often implemented. I know that IPFIX is often implemented over UDP. For this specific application, it is a good idea to follow RFC 7011 and 5013. Please think very hard about whether this is going to work under attack. Q: Two questions: 1. Are there any privacy consideration, particularly when you are aggregating this type of data, cross-carrier, in a centralized point? 2. Is there a risk that you end up with false-positives, particularly with black listing? A: (Nik Teague) 1. These would be considerations for privacy and the details need further examination. The last slide enumerates that encryption, obfuscation and authentication need to be examined. 2. Black lists don't need to be accepted. I hope there is a degree of due diligence on the side of provider in providing black lists. Comment: (Cisco): With regard to Kathleen's question, I think the market and threat landscape have changed. DDoS is real issue today. In order to mitigate attacks, you need an end-to-end solution. Today, you are essentially locked into a single vendor ecosystem. If you try to build an end-to-end DDoS solution, it is very difficult to do because open signaling doesn't exist. These solutions also have limitations. From my customer view, I would see a lot of interests in DOT. This interest is a key difference from earlier efforts and likely a contributor to why this work will take off. ------------------------------------------------ 3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min) ------------------------------------------------ Presenter: Ana Hedanping Draft: draft-fu-ipfix-network-security-00 Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dots-0.pdf The presenter provided an overview of the draft. There were no questions. ------------------------------------------------ 4. Panel discussion on suitability (40 min) ------------------------------------------------ Moderator: Nik Teague 1. Rich Groves (A10 Networks) 2. Andrew Mortensen (Arbor Networks) 3. Vince Berk (FlowTraq) 4. Ramakant Pandrangi (Verisign) 5. David Larson (Corero) [1st round of moderated discussion] Nik Teague: The purpose of this panel is to demonstrate the support for DOTS. Two questions will guide the first round of panel discussion. * Why you are interested in an IETF standards for DOTS * How can DDOS mitigation get better? Rich Groves (A10 Networks) ** We see DOTS as an exchange of security policy across devices. ** DDoS is definitely one good use case for this. ** If we have a standard for exchanging policies, that is beneficial not only for vendors but also customers. Andrew Mortensen (Arbor Networks): ** DDoS is bad, and nobody is disagree with that. ** DDoS is dynamic, and we do need to work together to fight it. ** Arbor already has implemented solutions, but we are excited about the possibility of seeing capability expanded. Vince Berk (FlowTraq): ** From the viewpoint of our customers, the Internet has many issues. The IETF has picked up some of the problems so that people can solve them together. ** DDoS is such an absolute abuse of the Internet which required a coordinated response. Ramakant Pandrangi (Verisign) ** The Internet is getting bigger and more complex, thus the architecture needs to be fundamentally changed. ** We have to enable different architectures and ecosystems; and they are coming from customer feedback. ** Not every customers looks the same. ** Depending on the environment the solution should be different ** We wish to have a light-weight, focused, and deployable standard, thus we came to IETF. David Larson (Corero) ** A federation mechanism as promised would allow for better understanding and utilization of local context. ** DOTS will allow us to get away from strict sampling mechanisms and have better information on what is happening in real time by coordinating the view from on premise to the cloud. ** If we share this information using DOTS, we are going to be much faster at responding to evolutions in the threat landscape. [2nd round moderated discussion] Nik Teague: ** In what ways are you willing to contribute to DOTS and IETF? Rich Grove (A10 Networks) We have already starting on an external scripting mechanism in our product. Likewise, we already have templated IPFIX capabilities. Taking whatever event information and time series data, it is actually trivial for us. We are very committed to help not only in the IETF process, but with reference implementations. Andrew Mortensen (Arbor Networks) We have got involved a little bit late. The current draft does not meet all of Arbor's needs, but we are committed to helping shape the result into something that we would be able to consume. We will be available and contributing to this work. Vince Berk (FlowTraq) We have a group of engineers, who integrate with many different devices and capabilities. Open standards will make our life much easier. Ramakant Pandrangi (Verisign) Our customers have and consider different kinds of devices from different vendors. We already have a basic version of the APIs with which we are getting some integration. We are working on expanding that. David Larson (Corero) We are also already implementing and testing some capabilities. The work in the draft clearly needs commitments from multiple entities, such as my company that do on-premise detection and mitigation, as well as cloud entities. We are committed to participating any kind of open environment that tries to develop this issue. [Questions from the audience] Q: (Kathleen Moriarty): Once you have this capability, is there any interests in integrating with existing mitigation methods? Is there any interests in going from this detection and immediate mitigation to stop DDOS to coordinating with other such groups to stop such activities? A: (David Larson) This type of metadata is generally invaluable. I agree with you. A: (Vince Berk) The reason this conversation is being driven by DDOS protection is because there is such an opportunity to do address the issue right now. The conversation is not necessarily about botnet mitigation. A: (Rich Grove): I agree. The proposal for exchanging capabilities is fantastic. Comment: (Kathleen Moriarty) The CARIS workshop might be of interest. https://www.iab.org/activities/workshops/caris/. Q: What kind of protocols do we want to deploy and develop for DOTS? I see that you would like to collect some sampled data, communicate capabilities of devices to a central point, and to later send policies to the devices. Does that capture what you are looking for? A: (Rich Grove): That's a fine core requirement. A: (Andrew Mortensen): There needs to be emphasis on the need for policies from CPE to be provided upstream. A: (David Larson) I do not see much need for sampling or being able to encapsulate sampled data and expressed upstream. A: (Nik Teague) Agree. We are not so much sending the sampled data up for analysis, but we are sending analyzed data up for action, or further analysis. Comment: (Brian Trammel) I see that three are 5 panelists with at least 5 solutions. Using IPFIX and JSON is fine, but we need to ensure interoperability. Step back and make sure the simple intersection architecture. A: (Nik Teague) Agreed. This will be further refined with additional discussion. Q: Are you suggesting using IPFIX to distribute policies to different devices? A: (Rich Grove): It is a fine way. Each device has certain range of capabilities. We have to figure out a method to make sure those capabilities are expressed and distributed to the sender. I am not entirely sure whether IPFIX is only the thing we need there, but we will know after further discussion. Q: What about the use of NETCONF to distribute policies? A: (Rich Grove) Yes, NETCONF is definitely viable approach. My problem is making sure that the signaling works through some middle-boxes. We have to have a transport mechanism that works pretty well for that. A: (Vince Berk): In the DOTS use case, customers have on-premises equipment that can handle some attacks. However, there is a moment that these devices realize that they cannot handle this anymore. At this point, any information we have available on the attack can be signaled up to upstream providers. They may select specific mitigation putting in place. A: (Ramakant Pandrangi): People needs different types of workflows. We are not looking at this protocol to solve that or to specify those workflows. A: (Andrew Mortensen): The idea of trying to change the configuration during attacks is not ideal. Modifying prefixes etc is not good idea. This could be covered by https or peace-time channel. A: (David Larson): I don't see the benefit of this endeavor to be about a protocol or configuration. I see it more as a signaling approach and schema. The most important thing in this environment is the heterogeneous participants in the enforcement of DDOS mitigation. The selection of NETCONF, IPFIX, etc doesn't matter that much, compared to the schema that can be instantiated by any types of protocols. Comment: We all agreed that it is an important issue. We need to know whether it is a right way. We need to be extensible. The drafts are very good starting point. We could begin with defining scope and high-level goals. Q: (Nokia): Who defines and update the signatures? A: (Nik Teague): We will figure it out along the way. Q: (Nokia): But you are going to work on it? A: (Nik Teague): Yes. Q: (Deutsch Telecom): The CPE will periodically contact the server somewhere in the cloud. This makes me a bit nervous. Signaling once an hour to the cloud is quite a big load. I would just ask a mechanism that does not put a permanent load to the infrastructure. A: (Nik Teague): Good point. Periodically is a very vague word. We need to think it through A: (David Larson) Today we do sampling of the edge network in order to determine what is going on, and that is very heavy weight and data intensive. If we move to a model where the on premise solution encapsulates the network itself and knows what's going on, then only communicating metadata might be necessary. It will reduce the problem. A: (Ramakant Pandrangi): If we talk about a practical deployment, the CPE is just a logical unit. It could be a controlling element or management device that actually does integration with upstream providers. Comment: My feeling today is that the first draft is for intelligent DDOS mitigation devices, while the second draft reflects more simple nodes in a network. I would like to encourage that protocol development considers both A: (Ramakant Pandrangi) I agree that developing both is appropriate. ------------------------------------------------ 5. Further discussion (30 min) ------------------------------------------------ After two presentation and a panel, the BOF chairs opened the floor for further discussion. A summary of the discussions from the meeting up to that point on the scope of DOTS included a protocol that: ** can send the capabilities of the CPE up to a service provider (SP) ** can send observations of threat activity seen by the CPE to the SP ** enable the SP to send down policy to the CPE ** enable the SP to inform the CPE the mitigations it is performing on its behalf The CPE could be a specialized DOS mitigation device or a system that is more general purpose. There was no agreement on which representation would be best. Comment: It is important to step back and consider defining the problem spaces and necessary techniques. Comment: I am looking at the trust. Why should we trust the information? How does the trust mechanism not become the attack surface itself? Q: Will the protocol set that have been presented be adopted as WG draft? A: (Roman Danyliw): This is not a working group forming BoF, so the answer is no. --[Consensus call]-- Is the problem space understood? yes : strong no : some Is there a need for the standardization? yes : strong no : none Comment: (Brian Trammel): I've not hummed for the 1st question, but I've hummed for the 2nd one. Let me explain why. The problem space discusses in the panel is fairly understood. It is also clear that there will be many contributors. We have discussed the edges of the problem spaces very much. I hummed for yes on standardization because if we draw a box in a more restricted way, it could actually succeed. We might have less opportunity for doing something a little bit on the edge, but that is better than trying to boil the ocean at once. Response: (Roman Danyliw) Are you saying there is interest in doing something like DOTS, even if we do not have very rigorous scope? Comment: I did the same hum as Brian. I am looking at broader set of network security functions than just ddos. We are now moving toward networking environments and a SDN-type of architecture. The need to standardize these interfaces is crystal clear. --[Consensus call]-- Who will be willing to contribute? - Significant number of people, >30 The chairs then opened the floor for discussion on how this work should be done in the IETF? Comment: Please start a new working group. Comment: I believe we need to define scope very carefully, as you can see the different scope of the 1st and 2nd presentations today. We need to tighten the charter. Comment: You mean, pick one or two use cases and get those working. If it works, we could work on something else? Comment: (Kathleen Moriarty): This is a non-WG forming BoF. The request for the meeting came too late for much advanced discussion. If there is sufficient energy on the list, we do not have to have another BoF. Q: Is there some information on rechartering some other working groups? A: (Roman Danyliw): MILE and OPSAWG have some overlap. There are likely others. A: (Kathleen Moriarty): Threat exchange work is done in MILE. There is some overlap. Comment: At IETF91, i2nsf ran a BOF/meeting with 20 operators and users. I am not sure in which way, but there are certain synergy between both. You could consider how to cooperate with I2NSF. Comment: (Eric Burger): It will be distracting to integrate this with existing working groups. Rechartering existing WG is not good idea Comment: I'm in favor of generating new WG. We need a clarity on scope so that we can achieve something meaningful in a reasonable time frame. Comment: (Brian Trammel): Do not open the IPFIX WG again. I do not see the danger happening since the scope is totally different. It is a clear cross area between SEC and OPS. It is a good candidate for cross area working. Comment: (Kathleen Moriarty): Noted. Comment: I agree with Kathleen's clarification on the i2nsf and this work. i2nsf is more on signaling, but there should be some cross work. There are definitely correlations between the two groups. Comment: (Dan Romascanu): Please do not add any new use cases on different types of interaction from architecture and requirement point of view to i2nsf. We have been focusing on defining scopes and charters. Reopening the full-scope discussion will delay our work. Comment: (Kathleen Moriarty): We have enough people who wish to separate the working groups, but they acknowledge there is some overlap. ------------------------------------------------ 6. Closing (chairs/AD, 5 min) ------------------------------------------------ Chairs thanked the participants and closed the meeting. The BOF participants were reminded that if they had interest in advancing the work to take discussions to the mailing list. This includes feedback on the drafts and candidate language for a draft charter for proponents of a new working group.