Subject: Re: IPF state and spurious blocks
To: Michael Graff <explorer@flame.org>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-net
Date: 05/28/1999 14:39:28
In some email I received from Michael Graff, sie wrote:
>
> My largest problems with ipf:
>
> (1) socket state isn't really tracked, it is recreated. It
> would be much nicer to somehow attach the socket info to
> the ipf line, and let the socket feed back into ipf what
> the state is. This would do several things. for one, the
> same thing (packet -> state) wouldn't have to be done
> twice.
Except that this doesn't really help when neither endpoint are the host
in question (unless you're going to force everything through application
proxies).
> (2) The state entries are not dynamic. Once you hit 2048,
> you're out of state entries. This is once again a problem
> with duplicating state. If a UDP socket closes, for
> instance, I'd rather have the state vanish, not time out
> in 2 minutes.
2048 is an arbitrary number picked at compile time that can be changed.
More recent changes in the code allow this to be changed at run-time by
doing and "ipf -D", change variable, "ipf -E". At present, however, you'd
need to use adb to make such a change since NetBSD doesn't support adding
variables to sysctl at run time and ipfilter doesn't have an interface (yet)
for changing those variables whilst not running.
> (3) There is no way to filter other than icmp, udp, and tcp.
> I'd like to be able to filter out all other "crap" like
> GRE tunnels from hosts I don't have a tunnel to, but the
> ipf doesn't do this.
Well you can filter other protocols, but it doesn't support filtering
on other protocol headers. So if GRE has some fancy information in its
packets, it does not provide an interface to get at that.
Darren