Hi Mike, No offense meant against Toplayer or anyone. I believe that you were not accurately informed in certain aspects.
1) Our campus's WAN link is only OC3 and there were only about 60Mbps of traffic going through the AM when packets were dropped. 2) We didn't expect the AM to withstand 800k pps of Syn Flood. However, it was dropping a lot of packets on our normal traffic of 13k sessions setup per second. The drop rate was about 35% to 40%. We haven't even gotten to testing DOS on the AM yet. The average DOS that we had received from there internet were about 10Mbps, which translates to about to 19,000 sessions/s. 3) You are right, the 800kpps DOS is very davastating to the network and usually takes a chunk of the network down. Surprisingly, routers ACLs and storm-control settings on switchs had been able to reduce these DOSs to a reasonably manageable level. Of course, its up to the individual to view whether the Cisco Catalyst 6500 with SFM and SUP2 is a single device or not. 4) Our suspicion of the CPU idle issue was based on findings from our extensive testings. Your regional support manager (Chian) with the help of regional technical expert (Sungki) had all these testing details and was there to observe the phenomenon as well. We had been waiting for Toplayer to get back to us on the CPU level phenomenon but after 5 months, there still hasn't been any satisfactory answer. Your speculation of the AM being placed in an asymetric routing situation is totally unfounded as the AM was placed directly behind a FW which happens to be the chokepoint and only point of entry and exit to the Internet. I strongly suggest that you dig out all the relevant information from your engineers before making any further speculations. 5) Load balancing is a good solution. I guess its just my personal view that its better to look for a higher end devices than start load balancing a group of low-end devices. I'll like to state once again that our encounter with the AM occurred about 5 months ago. What we experienced then may or may not be relevant to the AM available today. These experiences were raised out merely for the benefit of the community and potential AM customers by highlightly certain issues that potential AM customers may want to take note of. Cheers, Jeffrey Kok -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 07, 2002 7:25 AM To: [EMAIL PROTECTED] Cc: Jeffrey Kok Chew Mun; [EMAIL PROTECTED] Subject: RE: [ISSForum] Intrusion Detection vs Intrusion Prevention Hi All, > I would like to respond to Mr. Kok's 29-Nov-02 submission regarding > the Top Layer Attack Mitigator security appliance. I will try to be > objective in my reply, however you should note that I work for Top > Layer. > First of all, the AM is successfully deployed in many gig-attached networks of similar size to his network. That said, Mr. Kok is correct that, like any stateful inspection device, there are performance limitations in Top Layer's Attack Mitigator. His assessment of some of those characteristics is reasonably accurate for the version of the product he was running at the time. > He is also correct that there may be some Gigabit links that have too > much traffic for one Attack Mitigator appliance to handle. Although > the single appliance Attack Mitigator does indeed have Gigabit > Ethernet connections (to allow for Gig E connections from Routers and > Switches), it is rated for use on OC-3 and lower speed links. > > He is again correct that a SYN Flood of 800K SYNs/sec can overload a > single Top Layer Attack Mitigator. In fact, this is a very large SYN > flood, filling almost an entire OC-12 worth of bandwidth with minimum > size packets. Indeed this must be devastating to his network when > this type of attack takes place. I do not know of an effective > one-box solution that can address a SYN flood of this magnitude, while > still letting legitimate connections through. Does anyone else know > of such a solution? > > Finally, Mr. Kok is again correct that the version of Attack > Mitigator used in his trial was not able to block fragmented versions > of URI attacks such as Code Red and Nimda. This feature has been > radically enhanced in our latest version, available worldwide, and now > blocks fragmented URI attacks effectively. > > However, Mr. Kok is mistaken regarding his assumptions about the CPU > utilization on the Attack Mitigator, and his overall conclusion about > the applicability of the device in busy networks. Due to the AM's > architecture, the CPU utilization DOES provide an accurate indication > of how busy the system becomes dealing with forwarding traffic, > mitigating SYN flood attacks, and setting up and tearing down > connections used in the stateful inspection. The fact that the CPU > utilization was low would indicate that his network was NOT > overloading the throughput, connection setup/teardown, or SYN flood > mitigation capabilities of the Attack Mitigator. > > The far more likely scenario is that the Attack Mitigator was placed > into his network in a position that had asymmetrically routed traffic > (that is, responses may traverse a different path than requests). > Like any fully stateful device, the Attack Mitigator must see all > traffic from both directions of a conversation in order to work > properly. When placed on a single leg of an asymmetrically routed > network, for example, a stateful device may not see the closing of TCP > connections, and thus uses up its system resources until the connection record can be timed out due > to inactivity. In a busy network such as the one Mr. Kok describes, a > misconfigured stateful device can fill up its own stateful inspection > tables in a very short time, causing additional problems such as the > ones his users experienced. > > The suggestion that Top Layer made for a multi-box solution was not > ridiculous, but instead is a clever way to resolve the asymmetric > traffic handling to allow stateful devices such as the Attack > Mitigator to operate correctly, and in a distributed scalable manner > to address even the very largest attacks such as the ones that Mr. Kok > describes on his network, while not compromising availability. > > Thanks, > Mike Paquette > > _______________________________________________ ISSForum mailing list [EMAIL PROTECTED] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo
