Subject: Re: IPF state and spurious blocks
To: Darren Reed <darrenr@reed.wattle.id.au>
From: Michael Graff <explorer@flame.org>
List: tech-net
Date: 05/27/1999 22:12:51
Darren Reed <darrenr@reed.wattle.id.au> writes:

> 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).

True.

Perhaps a pointer to the socket could be used to speed things up
though...


> > 	(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.

Isn't it a hash table of some sort?

> > 	(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.

Can I say:

	block in on fxp0 proto 4 from any to any

and does

	block in on fxp all

block non-ICMP, UDP, TCP packets?

--Michael