DDoS Open Threat Signaling (DOTS) WG Agenda Tuesday, July 19, 2016 1620-1820 Afternoon Session II Bellevue SEC dots DDoS Open Threat Signaling WG Co-Chairs: Roman Danyliw and Tobias Gondrom 1. Note well, logistics and introduction (chairs, 5 min) Flemming: data model is still missing; Frank: we have some related content in some solutio drafts; Tobias: Are Flemming or other guys willing to do this work? Any other volunteers? some responses 2. Use Case Discussion (20 min) - draft-ietf-dots-use-cases-02 (Roland Dobbins, 10 min) Tobias: November is the WG Last Call milestone for this draft. If you have new use cases, please submit them before November Roland: -02 or even -03 will be prepared before the deadline, -02 is a major update. Andrew: Is there working copy of the draft now? Roland: we will send it to the list ASAP. Roman: please help us to review the draft, and if you have ideas about new use cases, please let us know. Jabber: do not see version 2; Roland: promises at least one update before November. - Additional use cases discussion (10 min) 3. Requirements Discussion (20 min) - draft-ietf-dots-requirements-02 (Andrew Mortensen, 10 min) - Additional requirements discussion (10 min) Roland: we will include the DOTS gateway (for intra or inter-domain) contents in next use cases draft, hope it is helpful to imply the requirements. Frank: Information model and data model is similar in the aspect for decribing what information we need and their attributes, I don't think we need repeated requirements for them. Andrew: agree and thanks. Flemming: Agree, don't get hung up on data and info models. staying at data model is not the best idea. 4. Architecture Discussion (20 min) - draft-ietf-dots-architecture-00 (Andrew Mortensen, 10 min) - Additional architecture discussion (10 min) Brian Rosen: most important learning from SIP gateway is that you must have security on every hop if you expect end-to-end. You cannot have any unsecure link. Bob: need geo-loc Roland: not geo-loc, perhaps topology Bob: agree Roland: looking at SRV records and anycast to find server Roland: think about federation--call it out in arch doc. there are maybe two stages for DOTS WG: 1--standardize the current proprietary interface for the p2p connection, 2 -- have a federated coordination among peers in the neraly middle term Flemming: please say more about coordination response Frank: in my dots protocol draft we mentioned two models: p2p and coordinated. I think it can explain the possible models. T. Reddy. Cisco: client should discover there are multiple upstream dots servers so that we have 1-to-1 request/response. Roland: real problem where customer must *manually* coordinate upstream mitigation. We can improve automation if federation. coordination is necessary for DOTS. coordination center can have more overall view of the network flow and make good decision. Flemming: more content is needed in requirements draft to make the two mode clear. Dave Dolson: is it intended to create a new session layer protocol? Vs. reuse an existing like diameter? Andrew: current thinking is to have a persistent connection Roland: redirection has some value for ddos protection SPs, and anycast may be useful to partly solve the redirected signaling problems.The question is redirection has some operational issues we need to consider the tradeoff, such as:reliability and resilience, since there can be a lot of nodes among the dots client and dots server. Flemming: redirected signaling is different from recursive signaling, it's more explicitly to express the policy and action. we should consider both of them. Tiru:the privacy concerns is not on the traffic, but on the contents of message whether they should be known by upstream operators. The key is important. Roland: I don't see the privacy concerns on the recursive model. recursive is only to have more hop relation comparing redirected signaling Roland: Mitigation issues: peer lost should be optional for mitigation trigger condition, for there can be other reasons for peer lost. And the mitigation initiation condition is more accurate and can be more broad than the current lists. 5. Protocol Drafts (40 min) - draft-reddy-dots-transport-05 (Tiru Reddy, 10 min) Roman: which use cases are your solution draft covered? Tiru: potentially all. we'll mention that on the draft. Roland: dynamic feature like happy eyeball is important, though it is not the first step (near future) Tiru: it make senses for the use cases when DOTS server has dynamic address and port. Andrew:can you explain the reason why you choose CoAP? Tiru: CoAP fits well all the requirements about DOTS transport protocol (congestion control, etc), it's an existing technology running over TCP and UDP transport, so we don't need to reinvent a new one. Andrew: Do you see any issues when a DOTS gateway is a B2B CoAP proxy? Tiru: end to end encryption and authentication is very complicated, but hop by hop authentication is enough and supported by CoAP. - draft-francois-dots-ipv6-signal-option-00 (J�r�me Fran�ois, 10 min) Roman: how does the server know the messages switched from previous signaling channel to the new channel? Jerome: we have normal signaling channel, and the backup channel actually watches traffic of normal channel. Roman: It seems a bit tricky Roland: is this solution the backup channel? Jerome: yes Roland : mechanisms that excessively relies on options are not the best one Jerome: it's just another optional signaling channel, to increase the chances of DOTS messages' transmit. Flemming: 2 basic questions: what is the goal of the content included in ip option attribute? if the DOTS regular can not arrive the DOTS server, how your channel can achieve this? Jerome: we will try every possible address and path to guarantee it. - draft-fu-dots-ipfix-extension-01 (Alex Zhang, 10 min) Roland: I agree there are some possible new works here. But we need to have a clear understanding of current state of art, then identify the gaps, then reopen the closed IPFIX WG related works. The proposed IEs in the draft is more broad than current DOTS WG, it needs a broader concensus. Tiru: current network devices and FWs do send this kind of telemetry information for attack detection. Can you explain why you need those new IEs? Tobias: we do see the benefits of using some new IEs for the network attack detection. for the benefits of the industry, we want this information can be vendor neutral, which means to be the standardized ones. Roman: which use cases are covered, and are not covered? Frank: we will clarify this in the draft (do citation in the draft). - draft-nishizuka-dots-inter-domain-mechanism-01 (Frank Xia, 10 min) chairs: no time for comments 6. Related Work (5 min) - draft-mglt-i2nsf-ssf-collaboration-00 (Daniel Migualt, 5 min) Tobias: does this draft relate to I2NSF? Daniel: I guess so. 7. Open-Mic (10 min) Chairs: we are hoping to see some running code, or implementation. So we will have a interim meeting in Wednesday to discuss it. 8. Closing