> -----Original Message----- > From: j [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 15, 2006 9:58 AM > To: Mike Barkett; [email protected] > Subject: RE: IPS Reliability/Availability > --- Mike Barkett <[EMAIL PROTECTED]> 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. ------------------------------------------------------------------------
