Re: IPS Reliability/Availability

["David W. Goodrum" <dgoodrum () nfr com>]

Hi David,

Sorry for the late post.  I will chime in that we here at NFR have 
tested, and are now shipping, this architecture for our multigigabit 
sensors.   I know you're looking for 3rd party testing, but I can tell 
you that we looked at a number of architectures before finally choosing 
this model to run our multigig solution.  Here's what our benchmarking 
found.

Question 1:  Our benchmarks have shown, with the basic 7 processor 
model, that it can sustain over 2Gbps of actual customer traffic (not 
fake traffic, but actual customer data), and that using this 
architecture we can actually scale the product with more processors to 
hit the 10G mark.

Question 2:  The only two IPS companies I know of that use this 
technology are NFR and SourceFire so far.  But, I know that other 
industries are using it also for their applications.

Question 3:  Pros of this architecture:

    - upgrade paths are a big one.  We can be very flexible in 
software, because we aren't putting any code down into hardware.   IPv6 
is a great example of this.  It was easy for us to add IPv6 capability 
via software.  If we had to do it in hardware, we'd probably be years 
away from producing something due to the nature of programming in 
hardware.  Using this model, our customers can retain all their existing 
hardware to support the new functionality, and with no performance loss.
    - One of the other nice features was redundancy.  We can hot swap 
CPU's in the event of some strange hardware failure.
    - Also, thanks to this hot swap, we can simply add more processors 
to an existing system to let the system grow with bandwidth 
requirements. So, the 7 processor model might work for you today.  But, 
in two years, you might need more performance, so you can simply add 
more processors to make it keep up.
    - Oh, and CPU redundancy means that we don't have to worry about 
any single processor becoming a bottleneck.  Meaning that inline 
prevention has even less likelihood of becoming a potential failure 
point on the network.

Cons of this architecture
    - it's hard to convince people that this solution is actaully as 
fast (or faster) than an ASIC solution for the same price.  ASICs have 
been around a long time, and people have a kind of warm fuzzy from that 
older technology.


You can go to http://www.bivio.net to read the details.

I want to point out that we do still ship x86 based sensors for 
customers who don't need this type of performance.  The x86 architecture 
is still the least expensive architecture out there, and it hits the low 
bandwidth budget very well.  This RISC architecture was great because it 
let us take the years of development we did on the x86 platform and cut 
it over to this RISC model very cleanly, with little development time or 
cost.

I have a 3 page powerpoint that we provide customers when they ask about 
the differences between our RISC architecture vs ASIC.  I don't think I 
can post attachments to the list, so I'll send it to you separately.  If 
anybody is actually interested, contact me off-list and I'll send it to 
you as well.

thanks,

-Dave


> Actually, I'm seeing other vendors, SourceFire being one of the ones
> in the eval list below, who have not gone the ASIC route, but have
> gone with a kind of RISC architecture to get speed.  Their pitch is
> that they get the performance of the ASIC vendors by using multiple
> RISC chips (I think the base model that does a gig inline has 6 RISC
> processors) to handle the load (plus an extra processor to handle the
> management end of things... so 7 all together).    They are claiming
> performance of an ASIC but the flexibility of software.  Not sure how
> valid that claim is.
>
> Question 1 :  I'm wondering if anybody has tested these or stacked
> them up next to the ASIC brands to test perfomance, and if so, can
> they provide some feedback.
>
> Question 2: Does anybody have a list of which vendors are using ASICs
> for performance and which are using this RISC type architecture for
> performance?
>
> Question 3: Not so much a question, but a general request;  I'd be
> interested in a "pro vs con" for each if anybody gets their hands on
> them.
>
> -d
>
> On 2/6/06, Andrew Plato <andrew.plato () anitian com> wrote:
>
> > Most of these devices are pretty good for reliability. The only
> > exception I would make is SourceFire, which back when we sold it had
> > abysmal reliability (3 out of 4 boxes we sold to a customer show up dead
> > or died soon after installation).
> >
> > TippingPoint sells a zero-power bypass add-on for their IPS. If the IPS
> > fails in anyway, traffic is passed through the zero-power device. Its
> > very easy to add. Juniper does something similar.
> >
> > -----------------------------------------------
> > Andrew Plato, CISSP, CISM
> > President/Principal Consultant
> > Anitian Enterprise Security
> >
> > -----------------------------------------------
> >
> >
> >
> >
> > -----Original Message-----
> > From: geek_brigades () yahoo com [mailto:geek_brigades () yahoo com]
> > Sent: Thursday, February 02, 2006 8:27 AM
> > To: focus-ids () securityfocus com
> > Subject: IPS Reliability/Availability
> >
> > I am working on a big IPS project and I am very concerned about
> > installing an inline device in a core enterprise network, where these
> > devices have the potential to create big time network outages.
> >
> > Can you, please, share your possible bad experiences about the
> > reliability of the following inline IPS products:
> >
> > ISS
> > TippingPoint
> > Juniper IPS
> > Sourcefire
> > McAfee IntruShield
> >
> > Have you had any issues with the availability of these devices, such as
> > fail close crashes or do you have any experience with bypass switches
> > that would mitigate the availability issue?
> >
> > Thanks,
> > Mike
> >
> > ------------------------------------------------------------------------
> > 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.
> > ------------------------------------------------------------------------
> > _________________________________________________
> > NOTICE:
> > This email may contain confidential information,
> > and is for the sole use of the intended recipient.
> > If you are not the intended recipient, please reply
> > to the message and inform the sender of the error
> > and delete the email and any attachments from
> > your computer.
> > _________________________________________________
> >
> > ------------------------------------------------------------------------
> > 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.
> > ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
> 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.
> ------------------------------------------------------------------------

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