DDoS Open Threat Signaling (DOTS) WG Agenda THURSDAY, July 20, 2017 15:50-17:50, Afternoon Session II Berlin/Brussels Co-Chairs: Roman Danyliw and Tobias Gondrom 1. Note well, logistics and introduction ======================================== presenters: Roman Danyliw and Tobias Gondrom slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-chairs-slides The chairs presented on the status of the working group. 2. Use Case Discussion ====================== presenter: Roland Dobbins draft: draft-ietf-dots-use-cases-07 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-use-cases-draft-ietf-dots-use-cases Dobbins presented the status of the -07 use case draft. Comment: (Tobias Gondrom): This is a very new version, please review it and give your help on comments. Comment: (Flemming Andreasen): With the respect of the homenet use cases, what's your concern about the use cases? A: (Roland Dobbins): Because it is not sufficiently different from some aspects of several other use cases. A: (Flemming Andreasen): So it’s not the scenario that you feel isn't relevant, but that it isn't sufficient unique to the others? A: (Roland Dobbins): Yes Comment: (Artyom ?): I have three suggestions. (1) The first one is about the MSSP requesting assistance from other MSSP. It is important to review the work done by other work groups. (2) The second one is about the use cases in 3.2.1.suppression of outbound DDoS traffic originating from consumer broadband access network. It may contradict with the group charter which says the WG will focus on the signaling and coordination mechanisms directly related to DoS attack detection, classification traceback and mitigation. (3) The third one is that the draft on github hasn’t been updated to the latest version. A: (Roland Dobbins): To your first of your comment, if you can give us some pointers on the list that would be helpful. With the regards to the outbound DDoS issue, it is a distinct use case from other types of bad traffic emanating from broaband access network. Broadband operators spend lots of time dealing with this and suppressing outbound DDoS attacks in many different ways. The idea of this use case is to illustrate that DOTS could be used to signal for the mitigation action. Secondly, it also offers the ability actually quarantine potentially nodes which are launching lots of outbound DDoS attack. Q: (Kathleen Moriarty as AD): what is the plan for the use cases draft? A: (Roman Danyliw): Publish the use cases, requirements and the architecture as separate informational documents. A: (Roman and Tobias): The WG has indicated that the use cases, requirements, architecture drafts are all very valuable for readers to understand the protocols. 3. Requirements Discussion ========================== presenter: Robert Moskowitz draft: draft-ietf-dots-requirements-06 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-requirements-draft-ietf-dots-requirements Moskowitz provided an updated on the -06 requirements draft. Comment: (Artyom ?): The definition of client signal limits the scope of a requested mitigation. In the draft, the DOTS client is described as a decision maker. But in the case of DoS attack, the bandwidth is consumed so that the victim/client side can only see a limited number of data. Hence the DOTS client may not be a good decision maker because it doesn't have enough data. A: (Bob Moskowitz): I will say this is an advisory message. Though the client says I see this attack, the server says the attack is really something else. The server having broader view can see something much different. A: (Andrew Mortensen): To the point that the server must see the mitigation. I believe the text says the server can continue mitigation but the client is no longer responsible for that mitigation. There are likely service agreements to describe business relationships between the client and server. A: Please send you specific comments in mailing lists and the github, so that we can discuss it openly and track the modification Comment: (Roland Dobbins): we previously have the use cases of dots server cannot receive the message, we can bring that use case back. Besides, dots does not consider specific DDoS detection, classification, tracebacck and mitigation techniques. Dots Chairs: How many people have read this requirements draft? Seems like many. Dots Chairs: what's the timeline for the next new version? A: (Andrew Mortensen): early next week. 4a. Architecture: draft-ietf-dots-architecture-04 ================================================= presenter: Nik Teague draft: draft-ietf-dots-architecture-04 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-architecture-draft-ietf-dots-architecture Teague provided an update on the -04 architecture draft. 4b. Architecture: draft-boucadair-dots-multihoming-01 ===================================================== presenter: Mohamed Boucadair draft: draft-boucadair-dots-multihoming-01 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-architecture-multihoming-draft-boucadair-dots-multihoming Boucadair introduced this new draft on handling multi-homing in the DOTS architecture. Comment: (Roland Dobbins): Use cases, requirements and architectures are worked in parallel with one another and informed one another bilaterally. But we do not anticipate any new requirements that have not already been anticipated and discussed in these documents from last version. some new use cases need new contents in requirements and architecture draft. Nik: will look at it. Q: (Flemming Andreasen): (1). We want to address the simple scenarios first. So do you think the multihoming is an absolute requirement for what we are doing in the first step in DOT to address. (2) Do you want to standardize what DOTS gateway is? I don't think we want to do it. Comment: (Roman Danyliw): thank you Mohamed for elaborating on the multi-homing topic and write a draft. We've discussed it at the interim meeting/ Comment: (Flemming Andreasen): As a general rule, we're trying to address the simple use cases first. This the multi-homing is a more complex use cases. A: (Mohamed Boucadair): Agree the step by step way to do the protocol, multi-homing problems can be solved later. And there is no dots gateway in current architecture, it's just dots client + server. A: (Tobias Gondrom): if you think any features are essential, please solve it right now. we will not wait for next stage to do it. A: (Roland Dobbins): to support multi-homing is a hard requirement for DOTS protocol. A: (Flemming Andreasen): there are various multi-homing use cases, how can I know in advance the specific use cases in network? A: (Mohamed Boucadair): indeed, it is learned by some provision work. Comment: (Roland Dobbins): lots of your content are the operational thing, but are out of DOTS protocol scope. We can add some description about this part since they are useful. Chairs: suggest to add the multi-homing contents into existing requirements and architecture draft. As of yet, the multi-homing problems are still not clear for WG, please discuss them in mailing list until we have a more clear picture about it. 5a. Protocol: IETF 99 Hackathon Activity ======================================== presenter: Kaname Nishizuka slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-dots-hackathon-report Nishizuka presented on his experiences and insights with implementing the DOTS protocols during the hackathon. Chairs: Great work at the hackathon! Thank you Kaname! We'd like to see more implementations and perhaps an interoperate test in Singapore. Comment: (Roland Dobbins): from operational perspective I would support relaxing the heartbeat requirements you showed. A: (Artyom ?): be careful with dropping the zero heartbeat mode requirement A: (Andrew Mortensen): I'm wondering if it will be sufficient to meet the requirement for two unique implementations that are interoperable. A: (Nik Teague): Echo some the discussion on the zero heartbeat idea. Should support zero heartbeat mode, but not necessary to be must. A: (Roland Dobbins): +1 on Nik Q: (Dave Dolson) Any concerns on the packet size during your test? for example, json, cbor, xml, etc? Chairs: Polling the room, 4-5 companies (purposefully not named in the minutes) are interested to do the further hackathon together. As a reminder open source or proprietary implementations are welcome to an interop. 5b. Protocol: draft-ietf-dots-signal-channel-02 : draft-ietf-dots-data-channel-02 =============================================== presenter: Nik Teague draft: draft-ietf-dots-signal-channel-02 draft-ietf-dots-data-channel-02 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-signal-and-data-channels-draft-ietf-dots-signal-channel-02-draft-ietf-dots-data-channel-02 Teague presented an updated on the WG signal and data channel drafts. Q: (Roland Dobbins): What's the logic behind the thinking that it might make sense to do the mitigation session limitation during the session negotiation? A: (Nik Teague): Can't recall. This is the first version so there may be some baggage and there is some changes occurred on a rolling basis. Something maybe overlap so I wouldn't put too much. Q: (Flemming Andreasen): A general question on both draft. It's not so clear to me when I look at these drafts exactly how the extensibility requirements are being satisfied. A: (Nik Teague): There is something I need to address it. 5c. Protocol: ====================================================== presenter: Mohamed Boucadair draft: draft-boucadair-dots-server-discovery-02 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-dots-server-discovery-draft-boucadair-dots-server-discovery Boucadair introduced a new draft proposing an approach to conduct server discovery. Q: (Roland Dobbins): There is a lot of discussion on anycast here. It seems there is an assumption that anycast is going to be a very common addressing mechanism for DOTS server. What is the assumption based on? A: (Mohamed Boucadair): Read the DOTS architecture, it has message there. Comment: (Kaname Nishizuka): As a implementer we would like to keep the DOTS client simple. A: (Mohamed Boucadair): There is only a recommendation to implement all the steps there. Q: (Martin ?): Is there any mechanism to foreseen for bootstrapping trust? Comment: (Bob Moskowitz): We should look at Netconf zero touch Comment: (Roland Dobbins): There needs to be some good discussion with the architecture and requirements work about all this. 5e. Protocol: draft-francois-dots-ipv6-signal-option-02 ======================================================= presenter: Jérôme François draft: draft-francois-dots-ipv6-signal-option-02 slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-dots-ipv6-dots-signal-draft-francois-dots-ipv6-signal-option-02 François provided an update on a draft describing an alternative signal channel. Q: (Roland Dobbins): What is the value of having an additional in band auxiliary channel? A: (Co-chair): Is that a new use case to talk about? A: (Co-chair): I'm also confused a little bit. I can see maybe I want to upload information to a server in case I'm going death or silent. But I'm not quite clear what's the benefit of uploading it somewhere else instead of uploading it to the server and so I'm not grasping what you try to solve. I am not seeing it as a strong requirements. 6. Closing