Skip to main content

Minutes interim-2017-dots-03: Mon 10:00
minutes-interim-2017-dots-03-201710021000-00

The information below is for an old version of the document.
Meeting Minutes DDoS Open Threat Signaling (dots) WG Snapshot
Date and time 2017-10-02 14:00
Title Minutes interim-2017-dots-03: Mon 10:00
State Active
Other versions plain text
Last updated 2017-10-03

minutes-interim-2017-dots-03-201710021000-00
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 behavior should be
aligned with the requirements.

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 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 >60s
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): If mandatory this might be a problem for the lifetime
parameter = -1 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)