Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks

Jeremy Harris <jgh@wizmail.org> Wed, 11 February 2015 10:39 UTC

Return-Path: <jgh@wizmail.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500C1A87CC for <tcpm@ietfa.amsl.com>; Wed, 11 Feb 2015 02:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Uh2oQMlR2ve9 for <tcpm@ietfa.amsl.com>; Wed, 11 Feb 2015 02:39:43 -0800 (PST)
Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 1E3711A87CB for <tcpm@ietf.org>; Wed, 11 Feb 2015 02:39:42 -0800 (PST)
Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85_42-aebaf3d) id 1YLUho-00028S-KS for tcpm@ietf.org (return-path <jgh@wizmail.org>); Wed, 11 Feb 2015 10:39:40 +0000
Message-ID: <54DB316B.3030301@wizmail.org>
Date: Wed, 11 Feb 2015 10:39:39 +0000
From: Jeremy Harris <jgh@wizmail.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tcpm@ietf.org
References: <CADVnQynQ07-=gzUGbBivua17guztXG7hF4u3gk9m1D+sYyB_Fw@mail.gmail.com>
In-Reply-To: <CADVnQynQ07-=gzUGbBivua17guztXG7hF4u3gk9m1D+sYyB_Fw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/_cqdlHYDqmp-MLclcNBFz8yuX3U>
Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 10:39:45 -0000

On 10/02/15 02:11, Neal Cardwell wrote:
> This patch series mitigates such ack loops by rate-limiting outgoing
> duplicate ACKs sent in response to incoming TCP packets that are for
> an existing connection but that are invalid due to any of the reasons
> mentioned above: sequence number (1), ACK field (2), or timestamp
> value (3). The rate limit for such duplicate ACKs is specified by a
> new sysctl, tcp_invalid_ratelimit, which specifies the minimal space
> between such outbound duplicate ACKs, in milliseconds. The default is
> 500 (500ms), and 0 disables the mechanism.

Would it not scale better over different link speeds to use a
packet-counting approach rather than a rate limit?   For example,
output a dupACK only for alternate triggers.
-- 
Cheers,
  Jeremy