Minutes interim-2017-dots-03: Mon 10:00
DDoS Open Threat Signaling
||Minutes interim-2017-dots-03: Mon 10:00
DDoS Open Threat Signaling (DOTS) WG Virtual Interim Meeting Minutes
Monday, October 2, 2017
14:00 - 15:30 UTC
1. Note well, logistics and introduction
Presenters: Roman Danyliw and Tobias Gondrom
The chairs provided a status summary of the WG. ~21 individuals joined the
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
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
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
3b. Signal and Data Channel
Presenter: Tiru Reddy
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 -1 value behavior
is consistent with the requirements (SIG-006).
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 (per RFC4787) 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 10s A: (Roman Danyliw): Let's mark this
topic as an unresolved issue needing additional discussion, and track it in
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
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
Q: (Dave Dolson): Would the /.wellknown/ be mandatory?
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
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!
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:
-- -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)