Minutes interim-2018-dots-01: Wed 10:00
minutes-interim-2018-dots-01-201802071000-06

Meeting Minutes DDoS Open Threat Signaling (dots) WG
Title Minutes interim-2018-dots-01: Wed 10:00
State Active
Other versions plain text
Last updated 2018-03-07

Meeting Minutes
minutes-interim-2018-dots-01-201802071000

   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