[ILUG] Firewall Overhead.

[Paul Jakma]

On Tue, 27 Jun 2000, Smelly Pooh wrote:

> Typical advocate attitude, there is no OS for every occasion, 

you're agreeing with me??

> that's precisely the point I've been trying to get across to you mad
> hats (prove me wrong mad hats).

read the archives: i've also advocated IRIX and Digital Unix in the past,
even Unixware!

> I like Linux, I recommend it to
> people who want to try out Unix, I run it at home, I like to read
> about the new things they're doing with it and the acceptance it's
> gaining.  Hell I'm a minor advocate myself.  But when I do see a
> department in which Linux is obviously lacking,

it lacks loads of loads things that other Unices have... so what? And
there are areas where linux gets stomped for performance. So what?

and there are areas where linux is the better choice. so what? I'm
actually happy about it. Linux will improve, so will the other
Unices. 

(aside: at least we can have flamefests about which Unix is best -> good)

> I'm not going to go on about how it's a memory hog, too complex, and
> doesn't belong in the kernel, especially when the next version of the
> Linux kernel is going to have that exact feature in the kernel,

it already was in the kernel as a programming interface -> ip_masq_...

> and the man who wrote ipchains and iptables things it's a great thing

i'm sure he does. and i never said stateful firewalling wasn't good
either. i just said that lambasting linux for not having full blown
stateful firewalling like your $CHOSEN_OS is unjustified.

and personally, i much prefer application level proxying. much easier and
far more powerful than stateful proxying. (eg at home i use ip_masq_icq,
but i'd much rather use a proxy if one was available).

> (now who's going to know more about firewalls... Paul and Kevin on the
> local LUG, or the people who actually write and use these firewalls?)
> 

rusty russel et al obviously. but if you want to use this point then you
should shut up about networking/firewalls too.

> > > Stateful information a memory hog?  Excuse me, but the kernel
> > > buffers used to hold the tcp/udp data from connections are only
> > > orders of magnitude bigger.
> > 
> > my point exactly, thanks for detailing it for me.
> 
> You made that point where?  I'm referring to kernel buffers which are
> required for data, not a stateful firewall.
>

think about 'state', now put that together with 'maintain' which a
stateful firewall does (as you've been so keen to point out).... and which
a 'static' firewall does not...

> > stateful firewall must maintain connections. it must maintain socket
> > state info (considerable in the case of TCP), might even have to
> > maintain complete TCP fragments depending on how 'stateful' it is.
> 
> Same information that is kept on an IP stack, I'm no kernel hacker, but I
> wouldn't be at all surprised if most stateful firewalls use this information
> that is already present.
>

there is a fundamental difference here that you're not grasping:

1. the static firewall gets packet, processes packet, punts out/discards 
packet, forgets packet ever existed.. (ignoring fragment assembly, which
stateful would have to do too, but the static one doesn't /have to/ do)

2. the stateful does all the above, but as you have pointed out, it must
remember them. Eg you gave the example of UDP applications, eg DNS, where
you say stateful firewalling has the benefit of stronger protection
against session spoofing. How do you think it does this? It has to
remember a certain amount of detail of past UDP traffic, and it still
won't be invulnerable unless it has an infinite memory and a good
knowledge of the actual application... (in kernel)

sorry, but i much prefer to run a caching/forwarding dns server in
userspace.

> Benchmarks please
> 

can't provide one. however it follows from logical reasoning if you accept
that stateful requires more memory. 

- the more state it remembers, the more memory it needs.
- as memory needs increase, so does load on the cpu<->memory bus.
- as load on the hot bus increases, so you need a faster bus.
- faster host buses typically come with come faster CPU's.

/anecdotal/ evidence: at compaq they use AS's with Alta Vista firewall
(stateful) for allowing very limited and controlled access by certain
customers to certain compaq applications. These machines had at least
256MB of RAM.

> Those are kernel modules, you know, "kernel" modules that you load
> into the "kernel", that run in "kernel" space? 

yep. it's not ideal.

> Did you read Kevin's college answer sheet aswell?
> 

no, he guards it religiously. however he does brief me on what to say
before i post to ilug. he's also chief nappy changer round here. (kev,
where are you - i'm full up).

> My chosen OS being every other Unix capable of packet filtering.
> 

good for you then. nice having a choice isn't it? 

> The difference there is that when sendmail goes down, all that happens
> is mail doesn't get through, when a user space firewall goes down,
> everything gets through.
> 

bollocks... 

if i'm running squid on a firewall, and squid goes down - does that mean
everyone can now suddenly access web sites directly? no. stop spreading
FUD.

> Um... unless we're talking 16-bit x86 hardware, 

x86 capable of running DOS/Win3.1 and Linux. (what does 16bit have to do
with it?)

> I don't think DOS/Win3.1 was ever faster than Linux.

DOS is significantly faster than linux. You're a CS grad aren't you,
figure it out..

> Perhaps in the kernel, along with stateful packet filtering, which evidently
> conflicts with the Linux view
> 

if you keep throwing stuff in the kernel you end up with SystemV.. eg why
is Solaris so pitifully slow on low-end hardware (x86/SPARC compared to
linux)? Why is IRIX6.5 so much slower than IRIX6.2 which is far far slower
than the BSD based IRIX5.4 on low-end hardware?

--paulj