Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

Nick Hilliard <nick@foobar.org> Wed, 16 March 2016 11:25 UTC

Return-Path: <nick@foobar.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25F112D75A for <v6ops@ietfa.amsl.com>; Wed, 16 Mar 2016 04:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ng7sh8wiKTkk for <v6ops@ietfa.amsl.com>; Wed, 16 Mar 2016 04:24:49 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF1612D540 for <v6ops@ietf.org>; Wed, 16 Mar 2016 04:24:46 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2GBOcCH058433 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2016 11:24:39 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local
Message-ID: <56E94275.20700@foobar.org>
Date: Wed, 16 Mar 2016 11:24:37 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: otroan@employees.org
References: <A277BE71-BD70-4AFE-97DA-F224D7DBBCB8@cisco.com> <BDA56C2D-788D-421C-B44A-1A29578F0F78@employees.org> <56E318C7.5020200@gmail.com> <F57DFD38-FC99-45AE-B41D-51B0565148B1@employees.org> <CALx6S37vNXk-g=W4n_Qvd2J=7xkgydvGEUwrhu8pRQig0hoqLg@mail.gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <CALx6S37vfDcchTa5Tch+BS8rQAGgPP_EeYbVz19WBchSHTqExg@mail.gmail.com> <56E60B0D.6070600@gmail.com> <CALx6S36_Vi4XZfPvCNY42zpbXy9dXeXzwE8KedxYDhne371HHA@mail.gmail.com> <56E6326B.2090303@gmail.com> <CALx6S353ognNHWnjbNSdW5hb_e6Hv3LqLa_r+e9yEW4F=cjH=A@mail.gmail.com> <56E6FC18.1060304@foobar.org> <CALx6S35pcSj_LLnDWJ68KwSYiHeu6FwrXTaR4N2xE6aY7MRO1A@mail.gmail.com> <CAHw9_iLbqEvsw0x4dDcA3Zy3SXKUROcQuy5nSynsL9Xi+xrZLg@mail.gmail.com> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org>
In-Reply-To: <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/gYS6rRTbYVtorXLaPZb1P-8FW8w>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2016 11:25:01 -0000

otroan@employees.org wrote:
> no, I'm talking about behaviour just in the data plane (in my case
> one that runs entirely in software).
> if the requirement is to look into the L4 header, then there will be
> a performance penalty for processing packets with extension headers.
> looking deeper into packets == more memory accesses.
> long EHs could be used as a DOS attack against the router.

It's not viable to run high end networks on general purpose CPUs using
software forwarding.  At the very least, you need NPUs if not custom
hardware (asics, "merchant silicon", etc).

> simple solution is to not look into the L4 obviously.

That isn't a viable workaround.  Losing visibility of L4 information is
catastrophic from the point of view of ddos management.

> why wouldn't the ddos flowspec description include the EHs in that
> case and not depend on only the L4 information.

Because if you have full control of a compromised device, you can create
random EH chains on an ipv6 packet?

> can we conclude that we don't know enough about ddos attacks to
> determine how they can be filtered?

Not sure what you mean here.  People initiating DDoS attacks will do
anything if they think it will cause damage to the recipient host.  Does
that answer your question?

Nick