DDoS Open Threat Signaling (DOTS) WG Virtual Interim Meeting Minutes Monday, October 2, 2017 14:00 - 15:30 UTC Agenda: https://datatracker.ietf.org/doc/agenda-interim-2017-dots-03-dots-01/ 1. Note well, logistics and introduction ======================================== Presenters: Roman Danyliw and Tobias Gondrom Slides: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/slides-interim-2017-dots-03-sessa-chairs-slides/ The chairs provided a status summary of the WG. ~21 individuals joined the meeting. The WG discussed the current milestones for the informational documents not on the meeting agenda (requirements, architecture). ** The requirements draft will require one more revision prior to entering WGLC. This updated draft can be ready prior to the Oct-30 draft-cutoff for the IETF 100 meeting. ** The architecture draft should enter WGLC only after the requirements draft is complete. No significant edits are needed for this draft. 2. Use Case Discussion ====================== Presenter: Roland Dobbins Slides: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/slides-interim-2017-dots-03-sessa-use-cases/ Draft: draft-ietf-dots-use-cases-07 Dobbins provided an update on the use case draft. The -08 revision is planned for Thursday, October 5, 2017. The -09 revision is planned for Friday, October 20, 2017. It is anticipated that the -09 will be ready for WGLC. Q: (Mohammed Boucadair): What content will go into the -08 revision? A: (Roland Dobbins): The -07 removed a significant amount of text. This -08 update will add some of it back. Comment: (Kathleen Moriarty): I recommend you don't use the term 'HOME-NET' to describe a use case as this would be confusing with other IETF work. A: (Roland Dobbins): Agreed. I have some concern with that use case. A: (Kathleen Moriarty): To clarify, I'm only suggesting changing the name. Q: (Roland Dobbins): Who gets to decide how the use cases should be scoped? Does the editor team need to be in consensus? A: (Roman Danyliw): This is a WG document. Put all the text that needs to be discussed into the document and the WG can decide how to proceed. 3. Protocol Drafts ================== 3a. NCC Group Implementation Report ----------------------------------- Presenter: Jon Shallow Slides: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/slides-interim-2017-dots-03-sessa-ncc-group-implementation-experience/ Shallow presented on NCC Group's experience implementing the current (draft-ietf-dots-data-channel-03 and draft-ietf-dots-signal-channel-03). Comment: (Roman Danyliw): Another independent implementation is a very helpful addition to the WG. Thank you. Q: (Roman Danyliw): Will NCC Group release this code? A: (Jon Shallow): No. However, we plan to host a public server in the near future against which other implementations could text interoperability. Per Slide 13: Comment: (Tiru Reddy): IMO, we should not expand the alias name A: (Jon Shallow): Agreed. Per Slide 14: Comment: (Roland Dobbins): Ordering of ACL rules will have to be done client or server side. A: (Jon Shallow): The protocol needs more specificity to allow standardized handling of the ACLs A: (Tiru Reddy): We need to approach the NetMod draft authors to discuss this further A: (Roman Danyliw): Who can make that link? Is help from the chairs required? : Jon Shallow volunteers. Comment: (Flemming Andreasen): Updates to the data channel might need to be reflected in the signal channel spec, and vice versa Comment: (Dave Dolson): Could we track these issues in github? A: (Tiru Reddy): Yes. I'll upload them. Comment: (Kaname Nishizuka): Our (NTT) implementation found many of these same issues. 3b. Signal and Data Channel --------------------------- Presenter: Tiru Reddy Slides: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/slides-interim-2017-dots-03-sessa-signal-and-data-channel/ Drafts: draft-ietf-dots-data-channel-04 draft-ietf-dots-signal-channel-04 Reddy presented on the recent updates to the data and signal channel drafts based on WG feedback. Per Slide 4: Q: (Flemming Andreasen): What is the rational for the -1 value (for the lifetime parameter)? Is this used instead of a heartbeat? A: (Tiru Reddy): No, a heartbeat is still required A: (Flemming Andreasen): What happens if a heartbeat is not received? A: (Tiru Reddy): The mitigation continues A: (Flemming Andreasen): This change seems significant as a soft state approach is no longer being taken. A: (Tiru Reddy): It will be up to the server implementation. A: (Flemming Andreasen): We need more discussion here. Is it up to the server or indefinite? A: (Mohamed Boucadair): This -1 value behavior is consistent with the requirements (SIG-006). Per Slide 7: Q: (Flemming Andreasen): What's the rational for a heartbeat-interval = 91? That value may be challenging for NATs A: (Tiru Reddy): Timeout for NATS should be around 120s (per RFC4787) A: (Flemming Andreasen): What's the basis for that value? We have a requirements to run through a NAT ... A: (Jon Shallow): The minimum for the heartbeat should be 10s A: (Roman Danyliw): Let's mark this topic as an unresolved issue needing additional discussion, and track it in github Slide 9: Comment: (Roman Danyliw as individual): I endorse requesting a new port for the DOTS signal channel. A: (Jon Shallow): We're currently using the CoAP port like other applications A: (Andrew Mortensen): A distinct port could help in a gateway scenario A: (Flemming Andreasen): If the signal channel needs a distinct port, does the data channel? A: (Roman Danyliw): Let's mark this topic as an unresolved issue needing additional discussion, and track it in github Slide 11: Q: (Kaname Nishizuka): What is the overlap in this case? ... A: (Roman Danyliw): Let's mark this topic as an unresolved issue needing additional discussion, and track it in github Slide 14: Q: (Dave Dolson): Would the /.wellknown/ be mandatory? A: (Jon Shallow): Can we afford the overhead of discovery? A: (Kaname Nishizuka): We use /.wellknown/ in our NTT implementation. A: (Dave Dolson): We might want the URI to be configurable to send different customers to different URIs A: (Roman Danyliw): Let's mark this topic as an unresolved issue needing additional discussion, and track it in github Slide 17-18 Comment: (Dave Dolson): We need to better understand the behavior of these mutual authentication options under attack scenarios 4. Open Mic =========== Comment: (Darrin Pettis): Thanks for all of the hard work on the protocol! 5. Closing ========== Presenters: Roman Danyliw and Tobias Gondrom The following actions were identified during the meeting: ** A -08 version of the use case draft will be published on Thursday, October 5, 2017 ** The requirements draft team will discuss specific timing but plans to release an updated draft prior to IETF 100 that will be ready for WGLC ** The protocol draft team will start using github to track open issues. ** The following issues discussed during the meeting can seed this open issue list as they require further discussion: (all slides numbers reference Slides: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/slides-interim-2017-dots-03-sessa-signal-and-data-channel/) -- -1 lifetime parameter value in a mitigation request (slide 4) -- default values for message transmission (slide 7) -- default port usage (slide 9 and 16) -- handling of overlapping mitigation-ids (Slide 11) -- default mitigation lifetime parameter (Slide 14) -- use of .well-known URI (Slide 14) -- solutions for mutual authentication (Slide 17-18)