Re: [Dots] Signal / Data / Alias / Filter Implementation

kaname nishizuka <kaname@nttv6.jp> Thu, 03 August 2017 10:46 UTC

Return-Path: <kaname@nttv6.jp>
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 3C6DD126CC4 for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 03:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 r5EnhROMyBFJ for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 03:46:03 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1AACA131D27 for <dots@ietf.org>; Thu, 3 Aug 2017 03:46:02 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 0140C25F68D; Thu, 3 Aug 2017 19:46:01 +0900 (JST)
Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 5A4A775900C; Thu, 3 Aug 2017 19:46:00 +0900 (JST)
To: Roland Dobbins <rdobbins@arbor.net>, Jon Shallow <supjps-ietf@jpshallow.com>
Cc: dots@ietf.org
References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <B8BBF80E-5A5B-473D-A0B2-B6EFEC21DEBF@arbor.net> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> <78660E60-0A94-4164-A8C0-5485816DE059@arbor.net>
From: kaname nishizuka <kaname@nttv6.jp>
Message-ID: <8115e45d-cebc-89a4-cd70-fdd7368a719e@nttv6.jp>
Date: Thu, 03 Aug 2017 19:45:59 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <78660E60-0A94-4164-A8C0-5485816DE059@arbor.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/n1GvNDeZaS4gh4XuhafPKKDlLrc>
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
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, 03 Aug 2017 10:46:05 -0000

 > The intent of DOTS is NOT to re-create flowspec.

Yes, I agree.


 > Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX.  We don't intend to do that.

 From ISP operator's perspective, DDoS mitigation includes RTBH, ACL, flowspec, dedicated box and cloud-type of service etc,..
As for flowspec, opening flowspec interface to other organizations is equal to passing responsibilities to other people, but DOTS is not.
DOTS should be able to cover the same problem space of flowspec in a safer manner, so giving layer-4 traffic information in data-channel is realistic for me.


thanks,
Kaname


On 2017/08/03 17:04, Roland Dobbins wrote:
> On 3 Aug 2017, at 14:56, Jon Shallow wrote:
>
>> I am of the firm opinion that destination-ip is REQUIRED
>
> The intent of DOTS is NOT to re-create flowspec.
>
> It's to signal the need for DDoS mitigation.
>
> 'Taking out someone else's IP' is not a concern of DOTS itself; this has to do with the provisioning of the DOTS clients, servers, and associated detection/classification/traceback/mitigation systems.
>
> Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX.  We don't intend to do that.
>
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots