Minutes IETF101: dots

Meeting Minutes DDoS Open Threat Signaling (dots) WG
Title Minutes IETF101: dots
State Active
Other versions plain text
Last updated 2018-04-23

Meeting Minutes

   DDoS Open Threat Signaling (DOTS) WG Minutes
IETF 101

Tuesday, March 20, 2018
15:50-18:20, Afternoon session II
Room: Viscount (1W)

Co-Chairs: Roman Danyliw and Tobias Gondrom

1. Note well, logistics and introduction
presenters: chairs

The chairs summarized the status of the working group.

2. Hackathon Report
presenter: Kaname Nishizuka and Jon Shallow

Nishizuka and Shallow summarized DOTS activity during the IETF 101 Hackathon. 
During this event, interoperability testing occurred -- mitigation request,
session configuration and coap ping were tested between NTT go-dots and NCC
group's implementations.

Comment: (Jon Shallow) There was a debate about cdid and cuid in the hackathon.
A: (Med Boucadair) Is there any clarification need to be added in the draft?
A: (Jon Shallow) Minor clarification.

Comment: (Tobias Gondrom) I encourage more vendors to join the interoperability
test activity. A: (Andrew Mortensen) Arbor are going to attend next IETF

Q: (Andrew Mortensen) Why do you choose libcoap as the coap basic, any
suggestions? A: (Kaname Nishizuka) libcoap support more functions like coap
ping than other library.

3. Additional Implementation Reports
DOTS implementors provided reports on their experiences.

(a) Arbor Networks Report (Andrew Mortensen)

Comment: (Liang Xia) Interop testing under bad/extreme network condition should
be considered in next stage. A: (Andrew Mortensen) Agreed. Doing testing that
simulate attack conditions would be valuable. A: (Jon Shallow) +1.

(b) NCC Group Report (Jon Shallow)

Comment: (Roman Danyliw) A reminder, NCC runs a public instance of a server. 
Implementers can do their own interop testing of a client.

4a. Signal Channel
draft: draft-ietf-dots-signal-channel-17
presenter: Tiru Reddy

Reddy presented an update on the signal channel draft.

Comment: (Roman Danyliw) The AD has approved early port allocation.  The formal
request needs to be submitted to IANA (by the chairs).

Q: (Andrew Mortensen) Do we need to establish the minimum requirement of the
cipher suites within the draft? Would we consider using QUIC as the transport
layer protocol in the future? A: (Tiru Reddy) QUIC is not designed for
constrained environment.  For the cipher suites, I have a section to discuss
the DTLS profile and what cipher suites should be implemented. We can go back
to see if any changes should to be made.

Q: (Kaname Nishizuka) Is ack timeout a float type?
A: (Tiru Reddy) Yes

Q: (chairs) Is the draft close to WGLC or are there any open issue? Are there
any big issue we havent discussed? A: (Jon Shallow) In addition to the
performance testing under stress condition, the drafts are relatively nearly
finished. A: (Andrew Mortensen) It's ready. A: (NiK Teague) +1 A: (Bob
Moskowitz): +1 A: (chairs) We'll wait for -18 to be published and then start a

4a. Data Channel
draft: draft-ietf-dots-data-channel-13
presenter: Med Boucadair

Boucadair presented an updated on the data channel draft.

Comment: (Flemming Andreasen) Per the client or domain filter discussion, I am
not clear what is the problem, we need to discuss later. A: (Tiru Reddy): I can
propose use cases to inform the discussion. A: (NiK Teague): The list of
filters is going to be advisory A: (Roland Dobbins): I see ICMP filters but not
ICMPv6.  We need to look into URIs and DNS resource records too.

Jon: I appreciate multihoming is way beyond just primary and secondary. I would
like at least two gateways which are similarly configured.

Comment: (Kaname Nishizuka) How should the confliction resolution of whitelists
be dealt with during the initial stage? activation stage? A: (Med Boucadair):
It is an implicit issue that doesn't need to be clarified in the signal channel

Comment: (Artyom Gavrichenkov) The latest version of these drafts are not being
added to GitHub.  It would be easier to comment if they were. A: (Document
authors) Agreed.

5. Architecture
draft: draft-ietf-dots-architecture-05
presenter: Andrew Mortensen

Mortensen provided an update on draft-ietf-dots-architecture-05.

Q: (Chairs) To confirm, the remaining issues will be addressed in an updated
draft next week? A: (Andrew Mortensen) Yes. A: (Chairs) Then the draft can go
to WGLC?  Would you prefer we stagger the WGLC on requirements, and let that
finish before we issue WGLC for architecture? A: (Andrew Mortensen): I don't
have any preference. A: (Med Boucadair) We need more time to review the current
text before launch the WGLC on the Architecture. Need make sure all the NAT
considerations are aligned with what have already provided in the signal

6. Use Cases
draft: draft-ietf-dots-use-cases-10
presenter: chairs, Daniel Migault
slides: (slide 8)

The chairs framed a discussion to elicit feedback from the WG (for use by the
editor team) on how to advance the -10 version.  Daniel Migualt presented an
alternative draft structure in preparation for multiple consensus hums.

Migualt presented a proposal to restructure the -10 draft.

Q: (Flemming Andreasen): How many pages in the current draft?
A: (Daniel Migualt) Roughly 10 pages

Q: (Tiru Reddy) Why remove the homenet usecases. it's a good usecase to me. 
It's a quite different use cases from others. A: (Daniel Migault) We didn't
have a agreement if the usecase is relevant or not A: (Roland Dobbins) There is
already another use case talks about outbound mitigation DDoS attacks. The
homenet use case can be added to this other use case for simplicity. A:
(Flemming Andreasen) I think this use case is fine, but we're spending a lot of
time working it.  Whatever it takes to publish this draft should be done. A:
(Nik Teague) Let's keep it simple. A: (Tiru Reddy) As long as the use case is
not harming the work, why remove this use case? A: (Tobias Gondrom) Is there
counter-proposal on how to frame this text. A: (Tiru Reddy) I'm comfortable
with the existing text, as is. A: (Roland Dobbins) The existing text needs
serious editing

Comment: (Roland Dobbins) Thank you Daniel for putting together this proposal. 
I agree that those familiar with DDoS could derive additional use cases from
the simplified ones presented by Daniel, those not familiar with the
operational world might not understand.  Reaching those audiences is the
benefit of the additional use cases.  I recommend we do not condense the use
cases.  If we do condense, I recommend we use the upstream-transit provider use
case as the first use case as it is simpler.

Q: (Tiru Reddy) Why do you need a DOTS client on a phone?
A: (Roland Dobbins) The motivation is outlined in the draft, in at least the
past version versions of the document.

Q: (Andrew Mortensen): What's the difference between having a DOTS client on a
phone and phone communicating through a portal that had a DOTS client? A:
(Roland Dobbins): There is a web portal for manual activation.  The phone is a
personal portal.

Comment: (Artyom Gavrichenkov) I suggest adding a new use case (in October
2017) "end user with an upstream transit provider or MSSP offering DDoS
mitigation services on a permanent basis". I think it was accepted on the
mailing list but it is missing in -10. Are there plans to incorporate it in
version 11? A: (Roland Dobbins): It's not a separate use case, its just a
separate operational motive operation. I agree that this arrangement should be
explicitly stated. To modes of operations exist -- permanent and as needed. 
Thanks for bringing it up.

Comment: (Tobias Gondrom/as individual) I primarily care about this work being
done. We've been refining this draft without substantial changes for several
versions.  I'm ambivalent on keeping the Homenet use cases.  For formatting, I
would prefer a streamlined option as proposed by Daniel to make it simpler to
consume.  Also, commitment from an editor to make changes would influence my
thinking. A: (Roman Danyliw) Agreed.  After the question on what to with the
homenet use case will be a needed conversation on resources. A: (Daniel
Migault) I can commit to work on GitHub and get the proposed changes I just
presented done in a month.

[Use Case Consensus Hum #1a] Hum if there objection to removing the HOMENET Use
Case? Consensus result: No objection heard

[Use Case Consensus Hum #1b] Hum if you support removing the HOMENET Use Case?
Consensus result: Consensus to remove HOMENET Use Case

Comment: (Roman Danyliw) The editor teams have two proposals on how to
structure the text. A: (Flemming Andreasen) Is there a difference in how long
we will have to wait to get the final version of the document depending on
which option is chosen? A: (Roman Danyliw) Lack of clarity on this timing is a
problem we have had. A: (Roland Dobbins) Option #1 requires the lease amount of
changes A: (Daniel Migault) A simpler document will be easier to get through
IESG review.  A more complex one may have a lot of feedback and discussions. A:
(Tobias Gondrom) There are pros-and-cons on both.

[Use Case Consensus Hum #2] Document structure in -11 should be:
-- (Option #1): use cases per -10 draft (less the HOMENET use cases that was
just removed by consensus) -- (Option #2): revised structure per presentation
Consensus result: Consensus was Option #2

Comment (Roman Danyliw): To confirm, these changes can be made within a month?
A: (Daniel Migault) Yes, working with the editor team we can incorporate the
mailing list feedback into a version on github. A: (Roland Dobbins) Agreed.

7. Closing

The WG thanks our outgoing area director, Kathleen Moriarty, for her great
support of this working group.