Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-03.txt

From: [email-masked]
Date: Thu, 17 Nov 2016 07:22:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DDoS Open Threat Signaling of the IETF.

        Title           : Use cases for DDoS Open Threat Signaling
        Authors         : Roland Dobbins
                          Stefan Fouant
                          Daniel Migault
                          Robert Moskowitz
                          Nik Teague
                          Liang Xia
                          Kaname Nishizuka
	Filename        : draft-ietf-dots-use-cases-03.txt
	Pages           : 23
	Date            : 2016-11-17

Abstract:
   The DDoS Open Threat Signaling (DOTS) effort is intended to provide a
   protocol that facilitates interoperability between multivendor
   solutions/services.  This document presents use cases to evaluate the
   interactions expected between the DOTS components as well as the DOTS
   exchanges.  The purpose of the use cases is to identify the
   interacting DOTS component, how they collaborate and what are the
   types of information to be exchanged.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dots-use-cases-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Nov 2016 16:24:01 -0500

Roland, Stefan, Daniel, Robert, Nik, Frank, and Kaname-san: 

This addition was very helpful in understanding the intra-domain context of
DOTS: 

  There are several merits of using DOTS signaling in an
intra-organizational manner:	
 		
 	   1.  It will facilitate interoperability between DDoS solutions/

 	   services by providing a standards-based, programmatic
communications	
 	   mechanism	
 		
 	   2.  It will reduce time to initiate DDoS mitigation services	
 		
 	   The required data exchange between DOTS client and DOTS server
may be	
 	   equivalent to or a subset of information set of
inter-organizational	
 	   use cases.

Section 3.4 was very useful as it described a pre-agreed contract with the
following elements:  mutual authentication between all elements (intra and
inter- organization) and DDoS service requested from multiple peered DOTS
organizations (via bi-lateral agreements or broker/orchestrator). 

Section A.1.1 - indicates that the DOTS client must be linked to the routing
devices (CPE, PE) and security devices (DDoS detection devices).    What I
still need help with based on Appendix A - is how much is the DOTS signaling
protocol and how much is the collaboration with other existing mechanisms.
What I am struggling with in this description is how much is in-band and how
much is out-of-band?   Do you utilize other protocols (BGP
Flow-specification)? 

In all of these questions, theoretical best mechanisms are NOT my focus.
What DOTS must support is the transition of the existing mechanisms to an
array of inter-operable solutions based on the IETF protocol.  After
chatting with you-all I really think there is unique about the DOTs
signaling protocol, but I am pushing to define when, where, how, and why. 

I will not be able to join you today - as I have duties for the IETF NOMCOM.
Thanks for all the wonderful discussions this week. 

Sue  

==============

Spelling nit: 

                 Inter-organizational: a DOTS communications relationship
between	
 	   distinct organizations with separate spans of administrative
control.	
 	   Typical inter-organizational DOTS communication relationships
would	
 	   be between a DDoS mitigation service provider and an end-customer

 	   organizational which requires DDoS mitigation assistance; between

 	   multiple DDoS mitigation service providers coordinating mutual

 	   defense of a mutual end-customer; or between DDoS mitigation
service	
 	   providers which are requesting additional DDoS mitigation
assistance	
 	   in for attacks which exceed their inherent DDoS mitigation
capacities	
 	   and/or capabilities.	

  /organizational/organization/

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, November 17, 2016 10:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the DDoS Open Threat Signaling of the IETF.

Abstract:

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 18 Nov 2016 06:32:56 +0700

On 18 Nov 2016, at 4:24, Susan Hares wrote:

>  indicates that the DOTS client must be linked to the routing devices 
> (CPE, PE) and security devices (DDoS detection devices).

Actually, that isn't the case.  Those are two example sets of 
participants only.

> What I still need help with based on Appendix A - is how much is the 
> DOTS signaling protocol

100%, excepting the parts which are explicitly called out as being 
outside the scope of DOTS.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 18 Nov 2016 04:20:00 +0000

On 18/11/2016, 08:32, "Dots on behalf of Roland Dobbins" <[email-masked] on behalf of [email-masked]> wrote:

    

I would agree this isn’t a MUST – its just one possible scenario.  Deployments and interdependencies will vary.

Thanks,

-Nik