Minutes IETF98: dots
minutes-98-dots-00

DDoS Open Threat Signaling (DOTS) WG Agenda

TUESDAY, March 28, 2017
1640-1840  Afternoon Session III
Zurich G

Co-Chairs: Roman Danyliw and Tobias Gondrom

1. Note well, logistics and introduction
========================================
presenters: Roman Danyliw and Tobias Gondrom
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-chairs-summary-01.pdf

The chairs summarized the status of the working group since the last in-person
meeting:
  ** Interim meeting (February 22)
  ** Use case design team meeting (March 27)
  ** Draft updates
  ** Call for adoption on drafts
  ** Milestone updates

2. Use Case Discussion
======================
presenter: Roland Dobbins
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-ietf-dots-use-cases-04-update-01.pdf
draft: draft-ietf-dots-use-cases-04

Dobbins summarized the status of the use case draft noting that the new version
is simplified, includes intra-organizational use cases and refined the
orchestration section.

Q: (Chairs): What is the timeline for the updated version of the draft?
A: (Roland Dobbins): In ~3 weeks.
A: (Chairs): Please get out changes as they come in and strongly encourage more
open comments and discussion in DOTS mailing list

Q: (Andrew Mortensen): How about the multi-homing use cases? DOTS architecture
draft has it. A: (Roland Dobbins): Yes, this is planned and will added in next
version.  In addition, multiple clients request for help, how to handle them by
orchestration is also a use case.

Chairs: This draft was submitted just recently so it has not been reviewed
sufficiently.  We encourage additional review.

3. Requirements Discussion
==========================
presenter: Andrew Mortensen
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-ietf-dots-requirements-04-update-00.pdf
draft: draft-ietf-dots-requirements-04

Mortensen summarized the status of the requirements draft noting that
outstanding issues are tracked in Github.  With this new draft, half of those
issues were addressed.  Additional issues will be addressed in next release
perhaps next week.

Discuss on client/server mitigation communication:

Comment: (Roland Dobbins): The client can't control the DOTS mitigation
service, such as time, scope, other policy aspects. The client just send its
request and the decision is made by the server. I suggest that the mitigation
termination timer be an implementation detail and not be standardized. A:
(Andrew Mortensen): The draft should define the responsibility among DOTS
clients and servers, but not to touch their contractual relation. I agree that
DOTS specifies only the communication.

Comment: (Roland Dobbins): Using FQDN is confusing.
A: (Andrew Mortensen): It actually should be domain names. will change.

Comment: (Flemming Andreasen) DOTS clients can not address the confliction and
overlapping problem by itself. It should be DOTS server to do it. Regarding
DOTS gateway, suggest a clear definition. A: (Andrew Mortensen): Agreed. DOTS
server need to handle this problem, details is needed.

Q: (Kaname Nishizuka): Do you consider anycast application in DOTS signal?
Could a zero heartbeat model and anycast support for DOTS server exist in DOTS
architecture? A: (Andrew Mortensen): It's in the architecture draft and for
DOTS server auto-discover. But yes, we can consider its use in DOTS
architecture. A: (Nik Teague): DOTS does not need to have a strict
session/channel function (for heartbeat check...), just communicate between
client and server by any flexible way.  Anycast is useful in many ways, such
as: ad-hoc communication scenarios.  We should consider it.

4. Architecture Discussion
==========================
presenter: Andrew Mortensen
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-ietf-dots-architecture-01-update-00.pdf
draft: draft-ietf-dots-architecture-01

Q: (Kathleen Moriarty): Are you suggesting DPI in the architecture draft? The
privacy problem should be considered and well handled. Another way is you don't
mention it in draft. A: (Andrew Mortensen): We are not advocating DPI or other
technologies to impact the privacy. We just mention that privacy problems
should also be considered in DOTS architecture.

Comment: (Roland Dobbins): I suggest a interim meeting to have a detailed
interactive discussion about architecture draft. A: Chairs: What is your
timeline? If you let us know in advance we can arrange it.

5. Protocol Drafts
==================

5.a draft-reddy-dots-data-channel-05
------------------------------------
presenter: Nik Teague
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-reddy-dots-data-channel-05-update-00.pdf
draft: draft-reddy-dots-data-channel-05

Teague summarized the status of the draft noting the recent additions of the
YANG model.

(Chairs): We have a poll for adoption started on this draft.  Any comments?
A: (Flemming Andreasen): I support adoption.
A: (Nik Teague): It still some improvements but I support adoption.
A: (Bob Moskowitz): I support adoption.  This will let us focus more on the
signaling channel draft.

5.b draft-reddy-dots-signal-channel-09
--------------------------------------
presenter: Nik Teague
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-reddy-dots-signal-channel-09-update-01.pdf
draft: draft-reddy-dots-signal-channel-09

Teague summarized the status of this CoAP CBOR-based draft.

Q: (Andrew Mortensen): Should we wait for TLS 1.3 for DOTS signaling channel?
A: (Nik Teague): This is being considered.

Q: (Chairs): Per the comment during the presentation, why do you think it is
now too early to call for adoption on this draft? Any gaps problems still
exists in the document? A: (Nik Teague): Just some more refinements needed, not
too much about the whole contents.

Comment: (Flemming Andreasen): A single signaling solution is we need, and can
solve my problem about data model design.

Q: (Bob Moskowitz): What are issues with (D)TLS 1.3, are they blocking?  And
what are the implementation issues with DTLS libraries.  Do we need
implementation recommendation section? A: (Nik Teague): Good comments.  We will
do these works after finishing our convergence.

Consensus call -- (Chairs to the WG): Who supports adopting this draft as a WG
document? vs. Not? ** Chair summary: There was consensus to adopt this draft.
** Chair guidance: Authors of this draft, please resubmit as a WG document.

5.c NTT Implementation Report
-----------------------------
presenter: Kaname Nishizuka
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-ntt-implementation-report-00.pdf

Nishizuka described NTT's DOTS implementation.

Comment: (Andrew Mortensen): Any suggestion about DTLS library implementations?

Q: (Chairs): which version do your implementation is based on?
A: (Kaname Nishizuka): data channel draft: 04, signal channel draft: 07

Comment: (Flemming Andreasen): I agree that signal channel and data channel
should be independent, it's only the contents they convey have the correlation.

Q: (Kaname Nishizuka): Do we think that data channel and signaling channel can
be separated, not bundle together? If it makes sense, I hope there are new use
cases in use cases draft. A: (Flemming Andreasen and Nik Teague): Yes, this is
the possible use case. we should consider. A: (Chairs): Is this noted as a use
case in any documents? A: (Nik Teague): Not yet, maybe need to add in use case
draft.

Q: (Andrew Mortensen): Does your implementation include the client provision
and bootstrapping issues? A: (Kaname Nishizuka): Not yet.

Comment: (Bob Moskowitz): Multiple signaling devices with single data channel
presents authentication challenges A: (Flemming Andreasen): Could this be
solved by coupling the contents of the two channels?

Chairs: Implementation reports are helpful and warmly welcome.

5.d Cisco Implementation Report
-----------------------------
presenter: Flemming Andreasen
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-cisco-implementation-report-00.pdf

Andreasen summarized Cisco's web-based proof-of-concept.

6. Other Work
=============
presenter: Hui Zheng
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-dots-draft-fu-dots-ipfix-tcp-tracking-00-00.pdf
draft: draft-fu-dots-ipfix-tcp-tracking-00

Zheng described the motivation and intent of the draft.

Q: (?): For IPFIX registry updates, do we need technical review, or expert
review? A: (Chairs): Expert review is sufficient.

Comments: (Kathleen Moriarty): Be aware of issues with protecting
confidentiality. Either the Security area or OPS area can advance this draft.

7. Open Mic
===========

Comment: (Andrew Mortensen): DOTS currently is based on DTLS 1.2. When 1.3 is
published, we can follow it without big efforts.

Comment: (??): Any clarification about mitigation measures?
A: (Andrew Mortensen): We have mitigation definition in drafts but, DOTS is
mitigation measures independent, and we don't exclude any possible methods,
such as: flowspec, fw, ddos devices, etc.

8. Closing
==========
presenter: Roman Danyliw and Tobias Gondrom

The chairs closed the meeting noting that:
** the use case and requirements drafts milestone will slip to July 2017
** the architecture draft will also slip to September 2017
** an interim meeting will be scheduled before Prague
** implementations are actively encouraged