DDoS Open Threat Signaling (DOTS) WG Virtual Interim Meeting Minutes Wednesday, February 7, 2018 15:00 - 16:30 UTC Agenda: https://datatracker.ietf.org/doc/agenda-interim-2018-dots-01-dots-01/02/ Recording: https://ietf.webex.com/ietf/ldr.php?RCID=24381ed6131f21287a17538623d43d78 1. Introductions and logistics ============================== presenters: Roman Danyliw and Tobias Gondrom slides: https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-chairs-overview The chairs provided a status summary of the WG. ~16 individuals joined the meeting. 2. Requirements Discussion ========================== goal: Review and resolve outstanding issues raised in WGLC presenter: Andrew Mortensen slides: https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-requirements draft: draft-ietf-dots-requirements-12 Mortensen summarized the outstanding issues identified during the WGLC. -- Comment: (Roman Danyliw): The mailing list (Jon Shallow) also identified that there was needed discussion on which channel should carry ACLs. A: (Jon Shallow): ACLs could also be suggested in the signal channel, very much like the alias field. A: (Andrew Mortensen): Yes, that can be considered. A: (Robin Dobbins): There is concern about whether we are reproducing Flowspec. A: (Andrew Mortensen): You're thinking of this as a "one-shot ACL"? A: (Jon Shallow): Yes, for instances where there are intelligent DOTS clients. It provides a hint. We don't need to reinvest FlowSpec. A: (Andrew Mortensen): I see no issue if the intent is a hint. Is it a sufficiently need/field from the current scope fields? A: (Jon Shallow): There is a need by the client to state in the signal channel to use "this predefined black-list" A: (Tiru Reddy): Why would the client want to selectively choose a blacklist? A: (Jon Shallow): You might want to be selective and this provides flexibility A: (Mohammed Boucadair): I see a case for this situation. We need to be aware of the consequences of hints, which might be wrong. This is more of an extension. A: (Roman Danyliw): Do we need to resolve this in the requirements document? Could we just move the requirement for ACLs into the general section instead of discussing it in the data or signal channel sections? A: (Mohammed Boucadair): Yes, we need to decide here because we've had previous conversations about scope. A: (Andrew Mortensen): To restate the proposal -- move the discussion of ACLs to a general section, but continue to the conversation outside the scope of the requirements draft (so that it can move to publication). A: (Jon Shallow): Works for me. A: (Tobias Gondrom): I support. A: (Andrew Mortensen): Does this open the need for a new requirement (general or otherwise) to distinguish between hints from the client and explicit filters? A: (Roman Danyliw): Yes, this seems like a practical resolution. Hints would be something different. A: (Andrew Mortensen): Agreed. That's my feeling too. A: (Mohammed Boucadair): We shouldn't restrict hints/intent to just ACLs. A: (Andrew Mortensen): Agreed. -- Q: (Roman Danyliw): To summarize, are there any other known issues with this draft beyond those identified in the slides, or just discussed? A: (Andrew Mortensen): Agree that this is the list of outstanding issues. A: (Roman Danyliw): To the WG? A: [no new issues voiced] -- Q: (Roman Danyliw): What's the schedule to get an updated draft to advance it for publication? A: (Andrew Mortensen): By March 2018 before IETF 101 the draft closure deadline. A: (Roman Danyliw): Thanks for all of your hard work. 3. IETF 101 Hackathon Coordination ================================== goal: Identify participants, coordinate activity, identify any help the WG can provide to participants presenter: open mic The following individuals plan to participate in the IETF 101 Hackathon: ** Jon Shallow (NCC Group) -- improve NCC Group implementation; interoperability testing ** Kaname Nishizuka (NTT) -- improve go-dots (NTT implementation); interoperability testing ** Liang Xia (Huawei) -- bring demonstration; interoperability testing ** Andrew Mortensen (Arbor) -- interoperability testing The planned participants voiced that no additional support from the WG was needed. 4a. Implementation Reports ========================== goal: share updates on implementations presenter: open mic The following implementers provided updates to the WG: ** Jon Shallow (NCC Group) -- NCC Group has updated their implementation against most features in the -17 version of the signal draft (no redirection and rate limiting) and -13 of the data channel draft (no gateway support and client registration). ** Liang Xia (Huawei) -- Huawei is working on a demo. ** Kaname Nishizuka (NTT) -- NTT is updating the go-dots implementation to support the -17 version of the signal draft. ** Andrew Mortensen (Arbor Networks) -- Arbor Network has an almost complete client implementation against the -16 version of the signal channel draft. It has been tested against the go-dots server and they plan to reach out to NCC Group to test interoperability against their server code before IETF 101. Q: (Andrew Mortensen): Is Jon Shallow/NCC Group the only implementation using RESTCONF for the data channel? A: (Jon Shallow): Yes, we (NCC Group) use a home grown RESTCONF A: (Kaname Nishizuka): We (NTT/go-dots) have not yet fully implemented it. -- Comment: (Andrew Mortensen): If there is only one RESTCONF implementation among us, we might want to collective focus time on that. -- Comment: (Andrew Mortensen): The quality of DTLS client libraries also remains an issue. CoAP too. Depending on the language used. Any other experiences? We're using tinydtls. A: (Jon Shallow): We're using libcoap. I plan to contribute back to the project improve various PKI issues needed for the signal and data channels. I've also shared my version of libcoap with Kaname/NTT. -- Q: (Daniel Migault): To clarify, does tinydtls not handle the needed PKI? A: (Andrew Mortensen): It only supports raw public keys. A: (Daniel Migault): So you have patches for it? A: (Jon Shallow): Yes. 4b. Protocol Discussion ======================= presenter: Mohamed Boucadair slides: https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-signal-channel : https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-data-channel draft: draft-ietf-dots-signal-channel-17 draft-ietf-dots-data-channel-13 Boucadair summarized the updates to the signal and data channels; and conducted a design walk-through on the significant changes. Question: (Mohamed Boucadair): All known issues have been addressed. Are there others from the WG on the signal channel? A: [no issues or feedback voiced] Q: (Roman Danyliw): Who has read -17? A: [not many, but there is support to read it] A: (Roman Danyliw): Not ready for a specific timeline for WGLC. We need review and would benefit from the implementations catching up. A: (Tobias Gondrom): You mean for the implementers. We don't need the implementations ready for WGLC. Right? A: (Roman Danyliw): Correct. 5a. Other Informational Drafts: Architecture ============================================ goal: Identify outstanding issues and define a schedule to bring the architecture draft to WGLC presenter: Andrew Mortensen slides: https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-architecture draft: draft-ietf-dots-architecture-05 (Andrew Mortensen) Mortensen enumerated the known outstanding issues to WGLC. -- Q: (Roman Danyliw): Are there any additional issues that would prevent a WGLC? A: [none voiced] -- Q: (Roman Danyliw): When could the next revision be made that would be the basis of the WGLC? A: (Andrew Mortensen): No more than a few weeks. A: (Roman Danyliw): As the only issue needing discussion, could you please summarize the STUN issue on the mailing to restart the conversation A: (Andrew Mortensen): Yes. 5b. Other Informational Drafts: Use Cases ========================================= goal: Identify outstanding issues and define a schedule to bring the use case draft to WGLC presenter: Roland Dobbins draft: draft-ietf-dots-use-cases-09 Dobbins summarized the next steps as follows: ** refactoring from IETF 100 and the mailing list ** have scheduled a poll for the week of February 12 to get the editorial team synchronized ** Plan to revise and update the draft by the end of February 2018 -- Q: (Roman Danyliw): Can someone from the UC author team summarize on the mailing list what needs to be addressed in the next draft update? A: (Roland Dobbins): That can be the outcome of the meeting next week. A: (Roman Danyliw): Ok. 6. Closing ========== presenters: Roman Danyliw and Tobias Gondrom The chairs summarized the outcome of the meeting as: ** signal and data drafts -- significant updates have occurred; additional review of these changes by the WG is needed ** requirements draft -- updated draft ready for advancement to IETF last call will be published by 03/05/2018 ** architecture -- discussion on remaining STUN issue will be started on mailing list -- updated draft ready for WGLC will be published by the end of February 2018 ** use cases -- Draft editor teams discusses document during week of February 12, 2018 -- Editor team will post open issues to the mailing list -- updated draft published by the end of February 2018 ** Hackathon at IETF 101: four implementations will be present ** Implementations: Arbor Networks and Huawei have announced implementations