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

"Susan Hares" <shares@ndzh.com> Thu, 17 November 2016 21:26 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EDC12953B for <dots@ietfa.amsl.com>; Thu, 17 Nov 2016 13:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n3JqiXFgbkc for <dots@ietfa.amsl.com>; Thu, 17 Nov 2016 13:26:34 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CB81294C9 for <dots@ietf.org>; Thu, 17 Nov 2016 13:26:34 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135;
From: Susan Hares <shares@ndzh.com>
To: dots@ietf.org
References: <147939617386.1746.17021745002346494502.idtracker@ietfa.amsl.com>
In-Reply-To: <147939617386.1746.17021745002346494502.idtracker@ietfa.amsl.com>
Date: Thu, 17 Nov 2016 16:24:01 -0500
Message-ID: <02b801d24118$ebccbe10$c3663a30$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHk/Q+VDj1rlUmyX6TwnwToXroWj6C4MnLg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/3b1LiNWhjrhtMWEBiRMjI8u4Ka4>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-03.txt
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 21:26:35 -0000

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:dots-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Thursday, November 17, 2016 10:23 AM
To: i-d-announce@ietf.org
Cc: dots@ietf.org
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.

        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/

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots