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

ÿþ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
  ** 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