Re: [Dots] Signal / Data / Alias / Filter Implementation
"Jon Shallow" <supjps-ietf@jpshallow.com> Thu, 03 August 2017 08:14 UTC
Return-Path: <supjps-ietf@jpshallow.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 25AF8132323 for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 01:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 0BAvVWgDCMM9 for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 01:14:49 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF58126CB6 for <dots@ietf.org>; Thu, 3 Aug 2017 01:14:49 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <jon.shallow@jpshallow.com>) id 1ddBHL-0000D1-Tt for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 09:14:48 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: dots@ietf.org
References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10@DM5PR16MB1788.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10@DM5PR16MB1788.namprd16.prod.outlook.com>
Date: Thu, 03 Aug 2017 09:14:49 +0100
Message-ID: <042c01d30c30$93ad0670$bb071350$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_042D_01D30C38.F5727FE0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQLJsfx7oZFS+IA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/crMS6nKGBmwks_QlBfrt-K8ZZco>
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 08:14:51 -0000
Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its life time. Reflections attacks (where the source port is constant - e.g. 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped currently. The DOTS client may continue to change its mitigation requests as the attacks evolve / mutate which is fine from my perspective. I really want to move away from Vendor Specifics for the more common definitions so that there is a standard across all vendors - even if the parameters are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but there (co-incidentally) is a large overlap. FlowSpec does not support Uri, but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could change, the type of attack itself could evolve or change from one attack type to another. It was discussed in the WG that this kind of information are only hints and not mandatory to be conveyed by the DOTS client in the mitigation request. https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type of the attack. However, DOTS signal channel draft allows vendor specific parameters and reserved key values in the range of 32768 to 65536 for vendor specific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some questions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based. There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations. I have not found a way of using a Filter defined over the Data Channel as a signal Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question - DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities. Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon
- [Dots] Signal / Data / Alias / Filter Implementat… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Roland Dobbins
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Dobbins, Roland
- Re: [Dots] Signal / Data / Alias / Filter Impleme… kaname nishizuka
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Konda, Tirumaleswar Reddy
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Roland Dobbins
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Roland Dobbins
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Konda, Tirumaleswar Reddy
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Konda, Tirumaleswar Reddy
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Konda, Tirumaleswar Reddy
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… kaname nishizuka
- Re: [Dots] Signal / Data / Alias / Filter Impleme… kaname nishizuka
- Re: [Dots] Signal / Data / Alias / Filter Impleme… kaname nishizuka
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Roland Dobbins
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Jon Shallow
- Re: [Dots] Signal / Data / Alias / Filter Impleme… Konda, Tirumaleswar Reddy