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

otroan@employees.org Wed, 16 March 2016 14:00 UTC

Return-Path: <otroan@employees.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 19E0B12D572 for <v6ops@ietfa.amsl.com>; Wed, 16 Mar 2016 07:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 Mj0znKPEoJIz for <v6ops@ietfa.amsl.com>; Wed, 16 Mar 2016 07:00:38 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8D512D50A for <v6ops@ietf.org>; Wed, 16 Mar 2016 07:00:38 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 34485D7881; Wed, 16 Mar 2016 07:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=hxf7Me0q2Wq/3DI60L5ks+qUQgs=; b= mpqnNuL2uv2NPkcFr2HX194Pxd3PzNhQ2M4/H3YgpRyZNiSr/mgOVWZOWNPYQG7C ixjFl5wu0BGkJgTCymOL4IGrbuIQjl73tcs/Qj5/7EVHsocORNdRrdmqobY9j/pR SnHmwT32OQKRgDmuMgO5aLpueSyR0AgPdY+q/V2Xq54=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=nIPpe/7bus4ofHEr/a+uevHNwh nFpkO5pz0ePVetSR+Fm6fCG1wNi/gLA41vAYBTbeTmRRQQA69Spz8/OqSiLGRZB6 km0gM/gv4EMzmJvVWWDcW2+z0w1gHjEjjqgQLKIsvllmWZDqSbspBlx6TyNV2Pjz FM3CV4moDF/IBIjMM=
Received: from h.hanazo.no (unknown [173.38.220.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CA431D789F; Wed, 16 Mar 2016 07:00:35 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A510512AC811; Wed, 16 Mar 2016 15:00:33 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_240FE8F0-F6D9-439B-8E93-BAE8F877A40F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56E94275.20700@foobar.org>
Date: Wed, 16 Mar 2016 15:00:32 +0100
Message-Id: <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@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> <56E94275.20700@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/q70jjvWntgRKxi0qRL0DzEDt8HQ>
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 14:00:40 -0000

Nick,

>> 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).

that was pretty fundamentalistic.
as always it depends. if you're happy with a few 100Gs then you can do it on current commodity hardware.

>> 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.

I hear you are saying that, but it is difficult to know if that's correct or not without having access to data.
how did the ddos attack look like, then figure out what the possible mitigations are.

>> 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?

sure, I'm just saying that if the ddos mitigation requires lots of processing it will also cause damage to routers.

cheers,
Ole