Subject: Re: pf status
To: None <pavel.cahyna@st.cuni.cz, current-users@netbsd.org>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: current-users
Date: 07/31/2005 03:30:27
On Dec 19,  7:18am, Pavel Cahyna wrote:
} On Fri, 29 Jul 2005 02:58:15 -0700, John Nemeth wrote:
} 
} >      I think I have commented on this before.  However, what I would
} > like to see is something akin to the way Cisco's IOS works.  Under IOS,
} > you define an access-list then you assign it to various places.  I.e.
} ...
} >      I think integrating pf and ALTQ is vary much the wrong thing to
} > do.  This would make ALTQ only usable with pf.  Using the above idea,
} > we seperate packet classification from treatment.  This would allow any
} 
} I like your idea, but the integration with firewalls sounds like a much
} easier task. (Or have you already started implementing your idea?)

     Lots of things are easier when you take shortcuts, but that doesn't
make them better.

} > packet classification engine (i.e. pf, ipfilter) to be used with any
} 
} pf and ipf aren't just packet classification engines, they do more -

     This is their primary purpose.

} reject the packets, modify them or send ICMP error messages. How they

     The whole point is that they shouldn't be doing all this other
stuff.  This would mean developing the infrastructure to do these other
tasks; however, it would make the system more flexible.  I.e. you could
have pf classify packets on one interface and ipfilter on a different
interface.  You could even use one for inbound packets and the other
for outbound packets on the same interface.  However, if you wanted to
use features like "keep state" you would probably be restricted to
using the same packet classifier for both directions on a given
interface.  As for flexibility today, I have to ask, can you even
compile a kernel with both ipfilter and pf?  I haven't checked, but I
suspect that you can't.

} could be used as classification engines? It seems that the easiest way is
} to let them tag the packets as an addition to logging them, blocking them
} and other actions, and then let ALTQ use those tags. But isn't that
} exactly what pf/ALTQ integration does?

     Perhaps.  But, the point is that pf and ALTQ shouldn't be
integrated, since that would preclude using ipfilter to tag packets for
ALTQ.

}-- End of excerpt from Pavel Cahyna