On Tue, 27 Jun 2000, Smelly Pooh wrote:
> In reply to Paul Jakma's flatulent wordings,
> No, typical advocate attitude is Linux is the OS for every occasion, I'm
> saying there isn't such a thing as an OS for every occasion.
>
which is what i said! rhetorical question: "show me the unix for every
occasion". the obvious answer: "it doesn't exist". you agree.
> So I wouldn't use Linux to do those things where it lacks what other
> Unices can do (such as with packet filter firewalls) and I wouldn't
> use Linux to those things that it gets stomped for performance (such
> as user space packet access)
>
of course not. no one would ask you to. if linux doesn't meet your
requirements for a certain firewalling application, but xyzBSD does, then
you use xyzBSD. Has anyone here said anything to the contrary?
> Alright, tell me how I get stateful firewalling working on Linux 2.2 then,
> please do, or is this some bullshit API that does nothing?
>
it's how all the ip_masq_ modules are implemented. see
linux-2.2/Documentation/networking/ip_masq/ for some very very basic info,
and read the source for the existing ip_masq_ modules for real info.
> I was "lambasting" Linux packet filtering for not being the optimal, and one
> of the examples I provided was its lack of stateful firewalling (the other
> being userspace filtering). Have I "lambasted" any part of Linux without
> justifying myself with facts?
>
linux 2.2+ does have stateful firewalling. (i was wrong).
but my preference is still for proxies. (but that's me).
> up, quite unlike you conjecturers, who have absolutely no evidence, no
> benchmarks, dare I even say no experience with stateful firewalls?),
> one might claim I'm a bit of a sheep, but one that is much more likely
> to be correct than you.
>
you're either trolling or you've been out in the sun too long and you need
to cool down.
> and for the 3rd time, that 'state', which the stateful firewall 'maintains'
> does not require as much memory as buffers already present for data used in a
> normal tcp/udp connection and the already existing state maintained by your
> TCP/IP stack, it is akin to the overhead of IP headers of internet data,
> something which quite small in proportion to the actual data transferred.
>
i sort of agree... however (for the xth time) you're still forgetting
something ---TIME--- the state has to be remembered! and TCP state is not
inconsiderable. (_IF irc_ it's about 64k per TCP connection)
> As I've said, this information is present in the kernel anyway, how
> does the Linux IP stack know when a TCP connection exists and an
> incoming packet is valid? Or if a UDP session is valid? Good lord it
> must need infinite memory to do that?
>
ok...
1. if it's a static firewall, it's just passing packets, so there are no
TCP connections to keep track off (TCP state is only maintained by the end
stations) - though it may be examining the TCP headers. Once the the
packet is gone, it is forgotten, all kernel buffers relating to that
packet are either de-allocated or thrown back into the pool.
2. the static firewall on the other hand must maintain at least some of
these IP structures for a certain amount of time. In addition it also
needs to maintain per session data, eg it needs to keep track of the TCP
state of a connection (static fw doesn't do that), it might even have to
maintain the data depending on how far it takes the 'keeping' state thing.
And if it wants to maintain state of UDP app's then it must have an
understanding of the application data inside the packet (..yuk), and it
must maintain state from that data for a certain period of time. and it
still can't stop UDP spoofs completely cause of the very nature of UDP.
> claim that a stateless firewall would run happily on an old 486, and
> implythat a stateful one would not, have you any benchmarks at all to
> prove this? Or did you just make that up?
>
no i don't have a benchmark for 'stateful' firewalls - it covers such a
huge range, how could you? from linux with an ip_masq module to
large proprietary firewall packages.
> Especially when you try to use that to argue that Linux packet filters
> in user space
>
ideally packet filtering, nfs, etc.. should be.
> No, same as the way when sendmail goes down people can't access your
> e-mail (as stated above), but when a packet filter goes down, the
> effect is that people will have access to all the sevices that the
> packet filter was there blocking in the first place, you know what I
> mean, don't give me your bullshit about FUD.
>
eh? no.. cause if it was in userspace, then it would be forwarding in
userspace and the kernel would be configured not to forward. application
goes down, forwarding goes down.
> Well genius, stateful firewalling doesn't slow down the kernel, why?
i meant more throwing things into the kernel in general.
> Because it's optional, if you don't use it you don't have to enable
> it.
nice to hear.
> If you do use it, it's going to be miles faster than having it as
> a userspace filter.
perhaps the real solution is for the kernel hackers to work on making
userspace<->kernel driver latency/throughput better. then perhaps these
things could be punted back to user space with a minimal performance loss.
anyway..
--paulj
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
