Minutes for DOTS at IETF-94
minutes-94-dots-1

DDoS Open Threat Signaling (DOTS) WG Agenda

TUESDAY, November 3, 2015
1300-1500  Afternoon Session I
Room 501  SEC  dots  DDoS Open Threat Signaling WG

Co-Chairs: Roman Danyliw and Tobias Gondrom
Meeting recording: http://ietf94.conf.meetecho.com/index.php/Recordings#DOTS

1. Note well, logistics and introduction (chairs, 5 min)

2. Use Case Discussion (50 min)
   - draft-ietf-dots-use-cases-00 (Roland Dobbins, 30 min)
   - draft-nishizuka-dots-inter-domain-usecases-00
     (Kaname Nishizuka, 10 min)
   - Additional use cases discussion (10 min)

3. Requirements Discussion (30 min)
   - draft-ietf-dots-requirements-00 (Andrew Mortensen, 20 min)
   - Additional requirements discussion (10 min)

4. Additional Drafts (40 min)
  - draft-reddy-dots-transport-01 (Prashanth Patil, 10 min)
  - Discussion (5 min)
  - draft-fu-dots-ipfix-extension-00 (Frank Xia Liang, 10 min)
  - Discussion (5 min)

5. Closing (5 min)

------------------------------------------------
1. Note well, logistics and introduction
------------------------------------------------
Presenters: Roman Danyliw and Tobias Gondrom
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-0.pdf

The agenda was approved without any changes. The chairs encouraged
contributions of architecture text and solution-oriented drafts to inform the
existing use cases and requirements drafts.  To improve WG transparency the
IETF issue tracker and likely github as a document repository will be adopted.

------------------------------------------------
2a. Use Case Discussion: draft-ietf-dots-use-cases-00
------------------------------------------------
Presenter: Roland Dobbins
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-2.pdf

Q: (Stefan Fouant) Could you clarification why a relay is needed?
A: (Roland Dobbins) A relay is used for aggregating requests/responses,
implementing a filtering policy, or as a proxy between stateful and stateless
transport

------------------------------------------------
2b. Use Case Discussion:
    draft-nishizuka-dots-inter-domain-usecases-00
------------------------------------------------
Presenter: Kaname Nishizuka
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-3.pdf

* Comment: (Chris Morrow): I don't see distinct use cases depending on whether
the upstream network is cloud-based or not. * Response: (Kaname Nishizuka) the
difference is: one supplicant, multiple mitigators; and one mitigator, multiple
supplicants. Currently this is a considerations for an NTT service, but it can
be generalized into DOTS. There is a need to have a strong coupling of the DOTS
server with DDoS mitigator. * Response: (Flemming Andreasen) The difference is
traffic redirection. In the first use case, traffic redirection is not needed.
For the second, traffic does need to be redirected to the cloud-based anti-DDOS
service. (Tobias Gondrom): The second use case is related to the situation
where two people are competing for the same resource (Roland Dobbins):
Cloud-based anti-DDOS services means more provisioning works. They are
important but not belong in DOTS.

* Comment: (Robert Moskowitz) In talking about terminology, we must remember
that the mitigator and mitigation are not in scope for DOTS. It can be on DOTS
server or not, but this part of work should be done in I2NSF. DOTS is
responsible for the signaling work between DOTS client and DOTS server.

* Comment: (Roland Dobbins) WG use cases draft co-authors agree to combine some
contents of this draft into WG use cases draft.

Q: (Frank Xia) A centralized orchestration center (or broker model) should be
considered as one possible use case; telemetry information step is also useful
and maybe be specified in DOTS scope. Are you interested as an operator? A:
(Kaname Nishizuka): We use various approaches for collecting information and
triggering the DDOS mitigation: flow collector, web portal, firewall, etc. We
also think provisioning is valuable that can be considered by DOTS.

* Comment: (Flemming Andreasen) Another use case is when a user/application are
in a cloud-based service. They don’t own their IP address space and it might be
shared with other users. * Response: (Roland Dobbins) There are two ways for
cloud-based application -- one is the DDOS mitigation service is provided by
the cloud provider.  The other may depend on the DNS to diverse the traffic.

Q: (Flemming Andreasen) Is provisioning in scope for DOTS?
A: (Roland Dobbins) some policy provisioning or registration belongs to I2NSF.
We should discuss in details in requirements draft.

* Comment: (Luyuan Fang): Two additional use cases: inter-provider,
inter-cloud.  The Microsoft cloud can tackle the DDOS attack to itself, but the
interconnection between clouds can be easily attacked.  Another interesting
thing would be including capability negotiation, mitigation, report and
monitoring and deep knowledge sharing. * Response:(Roland Dobbins): Agree, they
are all important use cases. * Response: (Tobias Gondrom) Luyuan Fang can catch
up with use case editors to check if her use case are written correctly.

* Comment: (Robert Moskowitz) We have not yet done an important part of the
DOTS work -- schema and data model for the DOTS messages. * Response: (Roland
Dobbins) Agreed.  That is important and should be included in the use cases and
requirements drafts.

------------------------------------------------
3. Requirements: draft-ietf-dots-requirements-00
------------------------------------------------
Presenter:  Andrew Mortensen
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-4.pdf

Q: (Daniel Migault) Is IPFIX information in the data channel?
A: (Andrew Mortensen): Considering white/black lists, configuration and
mitigation scope and so on

Q: (Flemming Andreasen) A good start. It seems to be missing a data model. Can
an architecture draft be developed in parallel? A: (Andrew Mortensen) Agreed.
A: (Robert Moskowitz) I encourage anyone to contribute to the data model
content A: (Tobias Gondrom): The chairs and AD believe all this can be
developed in parallel. A: (Flemming Andreasen) What are the plans for those
documents? A: (Tobias Gondrom): WG chair hat off. I'd like to see several
solutions and for them to be in separate documents.

Q: (Eric Wang): How about QoS?
A: (Andrew Mortensen): Currently considered as rate limiting.

* Comment: (Roland Dobbins): Need to be consider how to avoid the situation
that many attack source addresses are shared on the wire. * Response: (Andrew
Mortensen): false negative or positive are the results. * Response: (Tobias
Gondrom): An IPv6 address is very large.  This would make this use case more
interesting. * Response (Nik Teague) White lists are also important. * Response
(Luyuan Fang) Need to consider IPv6 in more detail and in addition to the
source/dst address * Response (Roland Dobbins) IPv6 is already considered in
scope, and IPv4 has the same problem. * Response (Andrew Mortensen) Will do.

Q: (Eric Wang) Are QOS issues considered?
A: (Andrew Mortensen): Will consider.
A: (Roland Dobbins) Should be part of the provisioning work.

------------------------------------------------
4a. Additional Drafts: draft-reddy-dots-transport-01
------------------------------------------------
Presenter: Prashanth Patil
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf

* Comment: (Roland Dobbins) What you mentioned is more about the victim asset
information, not necessarily related to the attack telemetry information. The
DOTS client may not have attack classification capability. * Response
(Prashanth Patil): It might simply notify "i am attacked, my address, my
condition..."

* Comment: (Wes Eddy) Don't use UDP. TCP is better
* Response: (Robert Moskowitz): The choice of transport is a large discussion
where any choice will be a compromise.  We need to have a design session with
transport mind on how to achieve this compromise. * Response: (Roland Dobbins)
An important point. We need both stateful and stateless transport.

Q: (Tobias Gondrom) Any suggestions on how to coordinate this issue with
transport guys? A: (Wes Eddy): Ask for operator guys for a transport suggestion
A: (Aaron Falk): The Transport Area meeting could be used to discuss this
question.

* Comment(Roland Dobbins) DOTS needs bidirectional transport to maintain the
DTLS connection.

* Comment (Nik Teague): As an operator, I feel that flowspec is very difficult
to use. What the challenges do you see with using filtering rules on the device?

* Comment (Robert Moskowitz): We need someone to tell us what is the useful
data modeling information.

Q: (Dave) Is DNS related?
A: (Robert Moskowitz) DOTS client does not need DNS but a DOTS server and
mitigator might.

------------------------------------------------
4b. Additional Drafts: draft-fu-dots-ipfix-extension-00
------------------------------------------------
Presenter: Frank Xia
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-dots-1.pdf

* Comment: (Chris Morrow) I've been working with Netflow since 2002 and am
unsure of the unsolved issue proposed here.

* Comment (Roland Dobbins) Echo Chris. There is confusion --there needs to be
clarification on what should be done in the exporter, what should be done in
the collector/analyzer. There is also a need to consider the performance aspect
of using a device for flow-based monitoring. Discussion on an IPFIX extension
is not needed if this is done at the collector.  Is this Netflow vs IPFIX? *
Response: (Frank Xia) The focus is on the sampled flows rather than the packet.
Not sampling all the flows. * Response: (Tobias Gondrom) Discuss with big telco
operators, they use Netflow, but IPFIX can offer you more rich and broad
information, you may agree or you may not agree. * Response: (Roland Dobbins)
IPFIX is even richer. Agree it can be extensible.

Q: (Xiaohong): Have you done any research on the validity or feasibility of the
approach? A: (Frank Xia) It was tested with operators with good results. It
could detect most of the DDOS attacks. A: (Xiaohong): Not just mitigating.
Should include inputs in the data modeling part of requirements from
experimental result.

------------------------------------------------
5. Closing
------------------------------------------------

An interim meeting will be held in late January or early February.