On Tue, 29 Aug 2006, Paul Mc Auley wrote:
> Not all IP traffic is TCP.
The relevance of non-TCP IP traffic on stateful TCP filtering is hard
But yes, you want as little state as possible. For UDP, "stateful"
filtering often boils down to a timeout on the (src:port,dst:port) -
which is a pretty poor (and weak) form of filtering.
> The other classic edge case is FTP, and no matter how much you
> might want it otherwise, there are cases where FTP is a
$ ftp ftp.heanet.ie
Connected to ftp.heanet.ie.
<snip heanet banner>
220 ftp.heanet.ie FTP server ready.
Name (ftp.heanet.ie:paul): anonymous
331 Guest login ok, type your name as password.
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
That's behind a stateless TCP firewall. No state needed..
Ironically, given the point you thought you were making, TCP stateful
firewalls /can't/ do this - they need yet *more* state (acquired by
packet inspection of FTP protocol data no less, ick).
> balancing one, I'd be wary of the overhead from trying to keep the
> management for any non-trivial number of states synched up as I'd
> see that getting out of hand in a big hurry.
Yes, indeed. Now google for 'pfsync'.
> The correct answer is to match your solution to your problem. Just
> because a certain solution doesn't match your needs, has caused you
> trouble in the past or stolen your sweets doesn't automatically
> make it the wrong answer for all cases.
Stateful filtering can't but fail to cause problems. It's the nature
of it. Let's rattle off some of the obvious ones:
ok, this isn't a fault of stateful filtering, but it's symptomatic
of the same school of thought amongst firewall 'designers' of
putting way way too much "knowledge" into middle-boxes. Crap that
just shouldn't be there. "Knowledge" which eventually breaks.
- TCP Wscale
There are firewalls today which try to validate that packets are
within window. This fails miserably if a firewall is restarted
(One of the BSD firewalls, Open or Free). Unfixable.
- It will never, ever, ever, work with asymmetric paths. This
includes hosts with links to multiple networks for redundancy
purposes (a not at all uncommon scenario). Unfixable.
And yes, my employer regularly get support queries from customers
who have strange networking problems because of this.
The more your firewall tries to replicate state of transport and
user-level protocols, the more and more there is to go wrong, either
- the future catching up and invalidating its knowledge
> FFS, "NAT is evil?" Do you want everyone to switch to public IPs, right
> here, right now?
> Sure it causes problems for a range of cases, but that
> doesn't stop it being usable for home and office networking.
It's better than nothing, but lots of stuff is broken by NAT, which
is what makes it evil, yes.
Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
Most people feel that everyone is entitled to their opinion.
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!