-----Original Message-----
From: j [mailto:y8k0vt3p@yahoo.com]
Sent: Wednesday, March 15, 2006 9:58 AM
To: Mike Barkett; focus-ids@securityfocus.com
Subject: RE: IPS Reliability/Availability
--- Mike Barkett <mbarkett@nfr.com> wrote:
I'm wondering why CPU cluster technology that you
are deploying is
considered new in comparison to ASIC/FPGA/NP
technology.
Primarily because it is newer than those
technologies. Can you offer any
examples in which this approach was applied to
bundled network security
point solutions prior to the advent of ASICs?
If you consider firewall to be a bundled network
security point solutions, here is an example:
http://www.foundrynet.com/services/documentation/siFWLB/ServerIron_FWLB_VP
N.html
Well, personally, I don't consider them bundled in the same sense I meant.
Perhaps "integrated" would have been a better choice of words?
I have worked with various FWLB and IDSLB solutions for many years, and
every one of them has had more than its share of caveats, flaws, chicken
wire, scotch tape, bubblegum, wood glue, man-weeks of professional services,
and rackspace hogging equipment, not to mention an astronomical price tag.
The RISC based solution we are discussing is markedly different in that it
has none of the above, and it relies less on load balancing than traditional
"sandwich" solutions.
I only ever liked those FWLB/IDSLB solutions for 2 reasons:
1. They gave me an excuse to play with tons of assorted new technologies,
and
2. They gave me job security, because I was one of the few who knew how to
implement them properly at the time.
The Enterprise Series sensor is just one box that fits into the existing NFR
architecture, so sadly, the above two reasons do not hold true for it. :)
However, it also has several nasty properties,
especially in the IDS
space. In addition, the problems get nastier with
adding more CPUs to the cluster, so there are a
limit how many CPUs you can put in a cluster.
For starters, if your load balancing scheme is
based on TCP/UDP port
numbers, you'll have a hard time detecting even
simple port scan.
Jack
This might be partially true if the load balancing
assumption were correct,
but at least in the one implementation (NFR) with
which I am familiar, it is not.
Can you enumerate some of the inherent "nasty
properties" to which you allude?
It's hard to be specific without knowing the details
of load balancing.
However, let me try to list a few issues:
- Increased latencies and jitter in case of inline
deployment.
- Burst loss. For example, try to do a deep
inspection without loss of a large TCP window of a
single TCP session sent by a server or a test device
over a gige interface. What's max burst you can
process without loss ?
- If traffic from a malicious source is distributed
to several CPUs, it will take you much longer or even
impossible to detect the attack and start dropping
malicious traffic.
It's certainly understandable that you'd be skeptical about the numbers
being thrown around. You're not the only one. And it's true that a poorly
implemented distribution scheme will suffer from the problems you mention.
These are not new concerns, however, and the equipment and software that we
use to tackle the speed problem are specifically designed to handle these
challenges. As someone said on a previous thread (or was it this thread?),
let's wait until the third party numbers come out before passing judgement.
And until then, we stand firmly behind our appliance ratings.
-MAB
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
