DDoS Open Threat Signaling (DOTS) WG Agenda IETF 102 THURSDAY, July 19, 2018 1550-1750 Afternoon Session II Room: Van Horne (2) Co-Chairs: Roman Danyliw, Liang Xia and Tobias Gondrom 1. Note well, logistics and introduction (chairs, 5 min) - slides: https://datatracker.ietf.org/doc/slides-102-dots-chairs-summary/02/ - Agenda o No agenda changes - WG Document Status Requirement: Shepherd write up Architecture: WGLC on Monday (July 23rd) Use Case: May need one more version for WGLC. Almost ready to shepherd write up Signal Channel: Still has feedback on mailing list. Take another WGLC Data Channel: WGLC on September Flemming: We have a couple of pending changes for architecture. Hold on a little on WGLC. Andrew: WGLC on August. o Authors are updating and will post 2. Hackathon Report(s) (20 min) - presenters: Kaname Nishizuka, Jon Shallow, Liang 'Frank' Xia - slides: https://datatracker.ietf.org/doc/slides-102-dots-ietf-102-hackathon-interop-report/00/ o Chairs thanked the hackathon team. They highlighted a number issues which can be investigated. Chair: Do the updated signal and data channel documents solve the Kaname's issues? Med: Yes, these issues are fixed in the up to date documents. They are just some clarification issues. I really appreciate the work which is done by Kaname and the team. It help us to assess what we are putting in the document. Kaname: Not only I but also Jon did a lot of work on the interpro testing. Med: Question about mitigation on loss. How your implementation is behaving right now? Andrew: Med refers the deadman's trigger, I am not sure you have tested it. Kaname: We didn't test it, need ask Jon. Jon: In my interpretation the deadman trigger was there if the was a loss of signal heartbeats between the server and client. Then the server could initiate whatever he needed to initiate to start mitigation as a consequence of the deadman's trigger. But Andrew's email let me realized we don't have anything in place for what should happen to start the mitigation Med: To avoid the confusion, perhaps we just need to copy the most point from the architecture and put it into the signal channel. Andrew: The issue for me is we don't defined what is the scope of the mitigation actually when it is on the deadman's trigger. We can say that it takes place on loss of signal in architecture draft. But there is no way to tell the server based on the signal channel what the scope should be. 3. Implementation Report(s): (20 min) - PoC of intra-domain DDoS Orchestration using go-dots (Yuhei Hayashi, 10 min) - slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-poc-report-on-the-intra-domain-orchestration-use-case-01 Andrew: Whether you can send the top attackers information in the signal channel or the data channel? Yuhei: I think it is signal channel. Med: We have received the questions many times to add more information into the signal channel. But now we decided to maintain the mandatory information. The new information to be included in the signal channel is really optional to have. Nik: Agree with Med that freeze the signal channel to a certain point. Then yout build it into other drafts or other functionalities. Frank: Thanks for bringing poc and requirements (DOTS Clients to send attacker information) here, maybe future we can do some extensions. Please write a draft, so we can have a discussion. Currently, the WG works on basic DOTS signal. Have the core thing done, then we can do extension. Nik: There is nothing stop you from putting this into the draft. Yuhei: We will write a draft and send to WG mailing list, take comments from you Chairs: Take it to the mailing list 4. Signal Channel (20 min) - draft: draft-ietf-dots-signal-channel-20 - slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-signal-channel-00 - presenter: Mohamed Boucadair Next steps: get the last comments then we can move forward - update for max-age: Kaname: The updated text is not friendly to new readers. Some of the mailing list discussion context should be included in the draft. Med: If you think that is not clear in the new text, let me know then we can work on that. Chair: Maybe Kaname can help to provide the text Med: I am personally fine with the previous text. I decided to change the text becasue Jon has some confusion. 5. Adding DDoS Types for DOTS Signaling (10 min) - draft-yang-dos-type-for-dots-00 (Bo Yang, 10 min) - slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-adding-ddos-types-for-dots-signaling-00 Roland (Jabber): DOTS is not intended to be a full inter-vendor control channel. There are infinitude type of possible DDoS attack types. Different vendors use different paradigms. We should stick to signaling for now. Let's take this up as a possible extension Kaname: It is not mature to include these kind of DDoS types in the signal and data channel. Andrew: Support Roland and Kaname. And there is a document defining different DoS type in the IETF, the RFC4732. Bo: I got the information that IETF has DoS type definition. I will go back to check that. Roland (Jabber): RFC 4732 obsolete, it shouldn't be used. Andrew: He is correct. We have discussed something like this in the past. The reason we didn't do it is that the dots client may not have the full scope of attack. Bo: Yes, maybe the client do not have the whole information, or the information is not fully trusted. But we just suggested it as a optional field for reference. Andrew: Yes, I agree. I support this beyond the current signaling draft. 6. Data Channel (25 min) - draft-ietf-dots-data-channel-16 - slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-data-channel-00 - presenter: Mohamed Boucadair Discuss the IPv4 fragmentation Roman: This is one of the blockers to finish this document. The author would very much benefit from your opinion. Andrew and Kaname: support the proposal. Frank: Raise some discussion in mailing list. Jon: I would also like to see the ability to have the bits and the mask capability of the TCP flags. Roman: We have a little issues still to be resolved in -18. When we get -18, we will go WGLC for this document. 7. Use Cases (25 min) - draft: draft-ietf-dots-use-cases-13 - slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-use-cases-00 - presenter: Daniel Migault Chair:many versions were made, need time to review it. The author thought all the feedbacks are covered. The chairs will do the final check to see whether all the comments are addressed. Daniel: Yes, this is my feeling. 8. Closing (chairs, 5 min) Next steps: signal channel -21 will go to 2nd WGLC, data channel will go to WGLC There is more room for the enhancement work.