Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices

Brian Haberman <> Thu, 18 June 2015 11:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87B5E1A02F1 for <>; Thu, 18 Jun 2015 04:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B-GccJBkE9AV for <>; Thu, 18 Jun 2015 04:33:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D5CC1A028A for <>; Thu, 18 Jun 2015 04:33:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id DA6CC880E2 for <>; Thu, 18 Jun 2015 04:33:00 -0700 (PDT)
Received: from Brians-MacBook-Pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 7BCB771B0002 for <>; Thu, 18 Jun 2015 04:33:00 -0700 (PDT)
Message-ID: <>
Date: Thu, 18 Jun 2015 07:32:48 -0400
From: Brian Haberman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IPv6 Operations <>
References: <> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L9Ig9dXVvRdXRCSaFCne4EMKTxurm0hoD"
Archived-At: <>
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2015 11:33:02 -0000

Hi Warren,

On 6/17/15 7:28 PM, Warren Kumari wrote:
> On Wed, Jun 17, 2015 at 1:48 PM, Brian Haberman
> <> wrote:
>> On 6/17/15 1:43 PM, Enno Rey wrote:
>>> Let's put it slightly different: the intrusion detector is supposed
>>> to detect/block certain application layer attacks. Which it does as
>>> long as those come in/pass by without extension
>> If the device is trying to inspect application-layer data, it might as
>> well act like the destination and re-assemble the fragments. Yes, this
>> is costly processing, but it mitigates this bypass mechanism.
> It also:
> A: assume that all the packets go through this device and
> B: that the device has enough state space to store bits until the
> fragments have all shown up (a standard attack against reassembling
> firewalls / ALGs is to send a fragment with the attack, then a whole
> heap-o-fragments that you never intend to complete (to starve buffer
> space) and then the final attack fragment.
> The FW can choose to A: fail open (allow the oldest uncompleted
> fragment when the buffer fills up) or B: fail closed / DoS (drop
> oldest fragments when the buffer fills). Neither is good. The attacker
> gets to set how long they wait before sending the final bits...
> I have some expense reports that I desperately don't want to do, so
> I'll procrastinate and try figure out just if this is even build able,
> regardless of cost...
> Linux has 60s (
> ), but let's choose 10s for how long we expect to be able to
> reassemble for - that's 125GB on a 100Gb interface. Unfortunately we

So, just a push back on these two assumptions.  Are they in conflict?
Would you really buffer 10 seconds worth of data on a 100Gbps interface?
 But, that is beside the point...

While the accompanying numbers are interesting (thanks for calculating
them) and scary, they don't really address my point.  These types of
intermediate security devices will always be at a disadvantage since: 1)
They need to inspect all the way to the application (or maybe transport)
layer, 2) at line rate, and 3) protect orders of magnitude more end nodes.

Mark's later e-mail is more articulate in pointing out that there are
three (or maybe more) distinct security issues being discussed here.
These need to be teased apart rather than addressing them partially with
short-term approaches.