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

Warren Kumari <warren@kumari.net> Wed, 17 June 2015 23:29 UTC

Return-Path: <warren@kumari.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E6B1B2C9E for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 16:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level:
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 vsiQUtCqwcrp for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 16:28:59 -0700 (PDT)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F045E1ACDF5 for <v6ops@ietf.org>; Wed, 17 Jun 2015 16:28:58 -0700 (PDT)
Received: by obbsn1 with SMTP id sn1so43387554obb.1 for <v6ops@ietf.org>; Wed, 17 Jun 2015 16:28:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZLNEsacmGcwkFNF+RzfmSxIZSwfwcTvjWuKOaUXPaAk=; b=Nf+9ANGD9PuOa6BQp9knajG+0rhIUMrwq9CkVeYb5qag3IvOJfJxW3sHmErFw2NPce yVzeXoywSbf8aXVgVdjvAoMaHSyF/pIRxxIoostCt5+s5fDJbsoO/I2MSAYZC8kIzvvA Rc/J+PekmYKNor3PHGEfcrURfGyWX/UljKut9PNygKm5rnJd1KVvz+gR0OXFuXGGsb+2 GB01Z75+DwWZdmXZ2JdT2dL5SQiqW4qrg7lj4vNklyApb0sWt+MBCafmvCRg9ZkrDwF2 6oOGMkdE0knKqfNPWesDpTsVPuDnZ83xQn8dj97EK+hzPSMo4pJz6X10Ai+s2dW/lYM/ 5sog==
X-Gm-Message-State: ALoCoQnzYUWhIw/FV8yK2UPxu0EcNr5+jiF//2vifRsPbiPZYGHOmfgcjfDJ5YmVVPhdmR0ua05V
MIME-Version: 1.0
X-Received: by 10.60.34.36 with SMTP id w4mr4363952oei.69.1434583738397; Wed, 17 Jun 2015 16:28:58 -0700 (PDT)
Received: by 10.202.196.75 with HTTP; Wed, 17 Jun 2015 16:28:58 -0700 (PDT)
In-Reply-To: <5581B2DF.8040207@innovationslab.net>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net>
Date: Wed, 17 Jun 2015 19:28:58 -0400
Message-ID: <CAHw9_iLE8_Z75DJA+AdSONH7vC5tAc_PyopqzF=iKsSgJKT-+A@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4FKWHvgmfk23gdWA6j49nsw_X5w>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 17 Jun 2015 23:29:01 -0000

On Wed, Jun 17, 2015 at 1:48 PM, Brian Haberman
<brian@innovationslab.net> 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 (http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/net/ipv6.h#L253
), 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
cannot just use regular DRAM here (buffer memory for 100Gbps needs to
be fast, especially for small packets), so realistically you are
looking at RLDRAM (reduced latency DRAM) - SRAM would be draw even
more power, cost more, lower density, etc and DDR3 doesn't have the
cycle time.

A quick look shows Micron's largest RLDRAM seems to be
MT44K32M36RCT-125E
(http://www.micron.com/~/media/documents/products/data-sheet/dram/1gb_twindie_rldram3.pdf),
a 10ns cycle time 32Meg x 36 wide chip, for 144MB (1152Mbit) per part.
For 125GB I'll need 889 of those.

A Cisco CRS-16 with CRS-X 4-Port 100GE blades gives me 64x 100Gb
ports, so 8TB of fast RAM, or 56,896 ram chips. Calculating current
consumption is tricky, because it depends upon how the memory is being
accessed (which the attacker can also (somewhat) control, but using
Micron's helpful power calculator spreadsheet we get ranges from
2154mw to 4035mw. Assuming there are no reads or writes 99% of the
times, we get a consumption of 2022mw + 151mw, for a total of 2173mw,
or 2.127W per chip. We have almost 57,000 of them, so that's 123KW per
router in memory alone (keep in mind there is also the memory
management, etc) . Currently the max power of a fully loaded CRS-1 16
is ~10KW, so that's a 12X increase just for the RAM.

Tempkin / RAS's NANOG presentation "Help! My Big Expensive Router Is
Really Expensive! "
(https://www.nanog.org/sites/default/files/wednesday.general.temkin.panel.pdf)
and Wobker's 'Power Consumption in  High-End Routing Systems'
(https://www.nanog.org/meetings/nanog54/presentations/Wednesday/Wobker.pdf
) shows the power consumption becomes distinctly linear -- you need to
move so much air to cool many KW that your fan / cooling system starts
to become a significant power draw. At this point you need to start
pumping even more air to cool the cooling, and so it spirals out of
control...
I'm not going to bother trying to calculate that, because, frankly,
I've gotten bored and want my dinner :-)

... and success, it is now too late to do my expense report, that will
be pushed to tomorrow :-)

W


>
> Regards,
> Brian
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf