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

Nick Hilliard <nick@foobar.org> Tue, 15 March 2016 22:55 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 1270812D69F for <v6ops@ietfa.amsl.com>; Tue, 15 Mar 2016 15:55:02 -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 lHDKU3jDgFSP for <v6ops@ietfa.amsl.com>; Tue, 15 Mar 2016 15:55:00 -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 CACE012D7A3 for <v6ops@ietf.org>; Tue, 15 Mar 2016 15:54:59 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2FMsnBL032392 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2016 22:54:51 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org
Message-ID: <56E892B8.9030902@foobar.org>
Date: Tue, 15 Mar 2016 22:54:48 +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>
In-Reply-To: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/To4fVAj1G0Dajv09aPzpw1In11I>
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: Tue, 15 Mar 2016 22:55:02 -0000

otroan@employees.org wrote:
> from the perspective of a software forwarding path. parsing the 
> extension header chain is _always_ going to be slower than not doing 
> it. that in itself can be considered opening your implementation up 
> to DOS attacks, but oh well.

assuming that you're talking about routers with separate management and
forwarding planes, and that you're referring to packets being punted
from the regular forwarding plane to the management plane when they are
difficult to handle (e.g. large EH chains), you can assume that on
current large routers, this is as good as dropping the packet because
the disparity between the capacity of the forwarding plane and the
management plane is too large to be useful. No-one in their right mind
will let the management plane of a high end router chew up management
CPU by forwarding punted packets. It's pointless.

> can ingress / edge filters be done in two stages? core routers only 
> filter on SA/DA while whatever infrastructure function you need to 
> reach apply deeper filters?

Basically, no.  What might look to be legitimate traffic on core ingress
might only become visible as a ddos attack on the egress to the edge.
That's assuming that there is a clear-cut edge and core which there
often isn't.

> for DOS attacks, are those filters put in place dynamically?

yes - e.g. via flowspec.

> what does a typical attack look like?

they vary extremely widely; the smarter attacks will measure the effect
on the recipient site and vary the ddos traffic according to what
appears to work the best.  I.e. if one style of traffic appears not to
be having an impact, the traffic profile might change to something else
to see if that causes more trouble.

> can you identify it without having to parse EHs?

If someone attacks with ipv6 and there is a long enough EH chain to
cause the normal forwarding plane of a router to be unable to look far
enough into the packet to determine the L4 info, then the only real
option is to drop or rate limit (which is nearly equivalent to dropping
in the case of a ddos). There is insufficient parsing granularity on any
current equipment to be able to do much else.

> how often are you not able to identify it even when looking deep?
> any papers/reports on this?

No papers that I'm aware of.

Nick