Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Firewall Wizards: Re: High Speed Firewalls

Re: High Speed Firewalls

From: Crispin Cowan <crispin_at_wirex.com>
Date: Tue, 07 Mar 2000 20:55:01 +0000

David Newman wrote:

> We may be talking at cross-purposes here. I agree fully with what you say
> here, but I was making a different point.
>
> My contention is that it is not possible to ftp a 12.5-Mbyte (100-Mbit) file
> through a firewall with 100Base-T interfaces in 1 second, even though the
> interfaces are theoretically capable of moving traffic at that rate.

Ok. My contention is precisely that it IS possible to FTP a 100 Mbit file
through a firewall with 100Base-T interfaces in one second, plus the epsilon
time of network latency for the last packet to get through. If the application
experiences lower throughput than that, then it may be the fault of the
end-host systems, and not the firewall.

> Even a
> perfect firewall will still have to deal with packet headers, TCP connection
> setup and tear down, and its own inspection engine -- and all that pushes us
> over our 1-second budget. Ergo, there's no such thing as "line-rate"
> throughput from an application perspective. Any claim that a firewall does
> so (and I've heard several such claims) is a lie.

This is the part that does not follow. All of those issues relate to packet
latency, not throughput. If the firewall is a makes no attempt at parallel
operation, and therefore processes each packet sequentially, then your claim is
true. But those assumptions are not necessarily true. A firewall could have a
CPU that is a great deal faster than line speed, and therefore have ample time
to inspect one packet while another packet is being transferred from the
network interface to the machine's memory.

> This is a different issue than measuring bits on the wire, as we do when we
> benchmark switch or router performance. Of course there are firewalls that
> can saturate a 100Base-T link, full duplex; I've tested several of these.
> But they don't, and can't, push application data or even TCP at "line rate."

The only fundamental reason that applications cannot see "line rate"
performance at the application layer is the bandwidth overhead imposed by
packet headers. All that stuff about inspection is irrelevant to the question
of theoretical upper bounds to firewall bandwidth.

Certainly the stuff about inspection is relevant to *practical* discussions of
firewall bandwidth. The more inspection you try to do at "line speed", the
more computes you're going to need in the firewall. But if you throw enough
CPU hardware at the problem, you certainly can get the firewall to process
packets at line speed bandwidth, as evidenced by your evaluations that saturate
100Base-T links.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
                  JOBS! http://immunix.org/jobs.html
Received on Mar 12 2000

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos