Minutes IETF99: dots
DDoS Open Threat Signaling
||Minutes IETF99: dots
DDoS Open Threat Signaling (DOTS) WG Agenda
THURSDAY, July 20, 2017
15:50-17:50, Afternoon Session II
Co-Chairs: Roman Danyliw and Tobias Gondrom
1. Note well, logistics and introduction
presenters: Roman Danyliw and Tobias Gondrom
The chairs presented on the status of the working group.
2. Use Case Discussion
presenter: Roland Dobbins
Dobbins presented the status of the -07 use case draft.
Comment: (Tobias Gondrom): This is a very new version, please review it and
give your help on comments.
Comment: (Flemming Andreasen): With the respect of the homenet use cases,
what's your concern about the use cases? A: (Roland Dobbins): Because it is not
sufficiently different from some aspects of several other use cases. A:
(Flemming Andreasen): So its not the scenario that you feel isn't relevant,
but that it isn't sufficient unique to the others? A: (Roland Dobbins): Yes
Comment: (Artyom ?):
I have three suggestions.
(1) The first one is about the MSSP requesting assistance from other MSSP. It
is important to review the work done by other work groups.
(2) The second one is about the use cases in 3.2.1.suppression of outbound DDoS
traffic originating from consumer broadband access network. It may contradict
with the group charter which says the WG will focus on the signaling and
coordination mechanisms directly related to DoS attack detection,
classification traceback and mitigation.
(3) The third one is that the draft on github hasnt been updated to the latest
A: (Roland Dobbins): To your first of your comment, if you can give us some
pointers on the list that would be helpful. With the regards to the outbound
DDoS issue, it is a distinct use case from other types of bad traffic emanating
from broaband access network. Broadband operators spend lots of time dealing
with this and suppressing outbound DDoS attacks in many different ways. The
idea of this use case is to illustrate that DOTS could be used to signal for
the mitigation action. Secondly, it also offers the ability actually quarantine
potentially nodes which are launching lots of outbound DDoS attack.
Q: (Kathleen Moriarty as AD): what is the plan for the use cases draft?
A: (Roman Danyliw): Publish the use cases, requirements and the architecture as
separate informational documents. A: (Roman and Tobias): The WG has indicated
that the use cases, requirements, architecture drafts are all very valuable for
readers to understand the protocols.
3. Requirements Discussion
presenter: Robert Moskowitz
Moskowitz provided an updated on the -06 requirements draft.
Comment: (Artyom ?):
The definition of client signal limits the scope of a requested mitigation. In
the draft, the DOTS client is described as a decision maker. But in the case of
DoS attack, the bandwidth is consumed so that the victim/client side can only
see a limited number of data. Hence the DOTS client may not be a good decision
maker because it doesn't have enough data.
A: (Bob Moskowitz): I will say this is an advisory message. Though the client
says I see this attack, the server says the attack is really something else.
The server having broader view can see something much different. A: (Andrew
Mortensen): To the point that the server must see the mitigation. I believe the
text says the server can continue mitigation but the client is no longer
responsible for that mitigation. There are likely service agreements to
describe business relationships between the client and server. A: Please send
you specific comments in mailing lists and the github, so that we can discuss
it openly and track the modification
Comment: (Roland Dobbins): we previously have the use cases of dots server
cannot receive the message, we can bring that use case back. Besides, dots does
not consider specific DDoS detection, classification, tracebacck and mitigation
Dots Chairs: How many people have read this requirements draft? Seems like many.
Dots Chairs: what's the timeline for the next new version?
A: (Andrew Mortensen): early next week.
4a. Architecture: draft-ietf-dots-architecture-04
presenter: Nik Teague
Teague provided an update on the -04 architecture draft.
4b. Architecture: draft-boucadair-dots-multihoming-01
presenter: Mohamed Boucadair
Boucadair introduced this new draft on handling multi-homing in the DOTS
Comment: (Roland Dobbins): Use cases, requirements and architectures are worked
in parallel with one another and informed one another bilaterally. But we do
not anticipate any new requirements that have not already been anticipated and
discussed in these documents from last version. some new use cases need new
contents in requirements and architecture draft. Nik: will look at it.
Q: (Flemming Andreasen): (1). We want to address the simple scenarios first. So
do you think the multihoming is an absolute requirement for what we are doing
in the first step in DOT to address. (2) Do you want to standardize what DOTS
gateway is? I don't think we want to do it.
Comment: (Roman Danyliw): thank you Mohamed for elaborating on the multi-homing
topic and write a draft. We've discussed it at the interim meeting/
Comment: (Flemming Andreasen): As a general rule, we're trying to address the
simple use cases first. This the multi-homing is a more complex use cases. A:
(Mohamed Boucadair): Agree the step by step way to do the protocol,
multi-homing problems can be solved later. And there is no dots gateway in
current architecture, it's just dots client + server. A: (Tobias Gondrom): if
you think any features are essential, please solve it right now. we will not
wait for next stage to do it. A: (Roland Dobbins): to support multi-homing is a
hard requirement for DOTS protocol. A: (Flemming Andreasen): there are various
multi-homing use cases, how can I know in advance the specific use cases in
network? A: (Mohamed Boucadair): indeed, it is learned by some provision work.
Comment: (Roland Dobbins): lots of your content are the operational thing, but
are out of DOTS protocol scope. We can add some description about this part
since they are useful.
Chairs: suggest to add the multi-homing contents into existing requirements and
architecture draft. As of yet, the multi-homing problems are still not clear
for WG, please discuss them in mailing list until we have a more clear picture
5a. Protocol: IETF 99 Hackathon Activity
presenter: Kaname Nishizuka
Nishizuka presented on his experiences and insights with implementing the DOTS
protocols during the hackathon.
Chairs: Great work at the hackathon! Thank you Kaname! We'd like to see more
implementations and perhaps an interoperate test in Singapore. Comment: (Roland
Dobbins): from operational perspective I would support relaxing the heartbeat
requirements you showed. A: (Artyom ?): be careful with dropping the zero
heartbeat mode requirement A: (Andrew Mortensen): I'm wondering if it will be
sufficient to meet the requirement for two unique implementations that are
interoperable. A: (Nik Teague): Echo some the discussion on the zero heartbeat
idea. Should support zero heartbeat mode, but not necessary to be must. A:
(Roland Dobbins): +1 on Nik
Q: (Dave Dolson) Any concerns on the packet size during your test? for example,
json, cbor, xml, etc?
Chairs: Polling the room, 4-5 companies (purposefully not named in the minutes)
are interested to do the further hackathon together. As a reminder open source
or proprietary implementations are welcome to an interop.
5b. Protocol: draft-ietf-dots-signal-channel-02
presenter: Nik Teague
Teague presented an updated on the WG signal and data channel drafts.
Q: (Roland Dobbins): What's the logic behind the thinking that it might make
sense to do the mitigation session limitation during the session negotiation?
A: (Nik Teague): Can't recall. This is the first version so there may be some
baggage and there is some changes occurred on a rolling basis. Something maybe
overlap so I wouldn't put too much.
Q: (Flemming Andreasen): A general question on both draft. It's not so clear to
me when I look at these drafts exactly how the extensibility requirements are
being satisfied. A: (Nik Teague): There is something I need to address it.
presenter: Mohamed Boucadair
Boucadair introduced a new draft proposing an approach to conduct server
Q: (Roland Dobbins): There is a lot of discussion on anycast here. It seems
there is an assumption that anycast is going to be a very common addressing
mechanism for DOTS server. What is the assumption based on? A: (Mohamed
Boucadair): Read the DOTS architecture, it has message there.
Comment: (Kaname Nishizuka): As a implementer we would like to keep the DOTS
client simple. A: (Mohamed Boucadair): There is only a recommendation to
implement all the steps there.
Q: (Martin ?): Is there any mechanism to foreseen for bootstrapping trust?
Comment: (Bob Moskowitz): We should look at Netconf zero touch
Comment: (Roland Dobbins): There needs to be some good discussion with the
architecture and requirements work about all this.
5e. Protocol: draft-francois-dots-ipv6-signal-option-02
presenter: Jérôme François
François provided an update on a draft describing an alternative signal channel.
Q: (Roland Dobbins): What is the value of having an additional in band
auxiliary channel? A: (Co-chair): Is that a new use case to talk about? A:
(Co-chair): I'm also confused a little bit. I can see maybe I want to upload
information to a server in case I'm going death or silent. But I'm not quite
clear what's the benefit of uploading it somewhere else instead of uploading it
to the server and so I'm not grasping what you try to solve. I am not seeing it
as a strong requirements.