From owner-freebsd-hackers Tue Feb 27 06:56:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA23726 for hackers-outgoing; Tue, 27 Feb 1996 06:56:43 -0800 (PST) Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA23721 for ; Tue, 27 Feb 1996 06:56:41 -0800 (PST) Received: from ugen-tr (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id JAA07277; for ; Tue, 27 Feb 1996 09:56:30 -0500 Date: Tue, 27 Feb 96 09:44:37 From: "Ugen J.S.Antsilevich" Subject: RE: IP filtering strawman, comments please. To: Poul-Henning Kamp Cc: hackers@freebsd.org X-PRIORITY: 3 (Normal) X-Mailer: Chameleon 4.00.4, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Well..sort of comment. Actually i was out of the IP filtering ideas picture for a while, and probably will stay this way if my Real Life [tm] will be the same but here is what i planned and started to do and i presume it is a pretty big change for a current policy of IP filtering so if anyone interested in doing so as a part of FreeBSD or as separate project i will be really happy. 1) We bring a new basic abstraction - instead of filter/rule/firewall entry or whatever-name- you-call-it the connection becomes a basis - at least for TCP/ UDP when posasible. 2) Filtering/routing machine maintains a hash/cache of all (or may be a most used part) of connections with some data regarding this connection flow. 3) Implementationwise i started writing it as a two-dimensional cache in which IP src/dst adresses define X-axe and ports space defines Y space differently for TCP and UDP and missing for IP. Then any connection holds a pointer to all relevant filtering rules which still do exist. 4) New connections coming checked only once agains the rules to find which do match this pattern - i.e. by src/dst adress/port/interface/whatever new criteria will come. Then any packet only checked against this set of rules in case it has specific flag-options settings, actually there could be a default action taken from the rule which applies to most common type of packet for connection. 5) This allows along with simple filtering to filter similar connections in the incoming direction while denying them in outgoing. Filter more efficiently and with greater precision and gain lots of statistics as well as put in different hacks like: - Masquareda certain connections for another IP's /ports/whatever. - Bring certain connections to the user agent for more specific examination. etc... This is all very schematic and primitive but i hope you get the idea. I do not remember a lot of things i planned, right now, i am sure this could be really extended and i do not have any notesfrom when i started thinking about that. Anyway this is my ideas and if anyone likes it i can bring the sources i started working on - there aren't much of them though. C ya. --Ugen