Date: Thu, 29 Feb 1996 18:18:30 -5600 (PST) From: Archie Cobbs <archie@tribe.com> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: hackers@freebsd.org Subject: Re: IP filtering strawman, comments please. Message-ID: <199603010218.SAA05571@bubba.tribe.com> In-Reply-To: <12238.825366315@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 09:25:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
The new packet filtering paradigm sounds great!
> And finally, what should be done when the rule matches:
>
> "drop" the packet is discarded.
> "refuse" as drop, but an ICMP packet is sent if applicable.
> "pass" the packet is OK and continues it's merry way.
> "count" the counters for this rule is updated, but the rule doesn't
> match the packet, and the next rule is tried.
> "divert" the packet is sent to a (specific) instance of the tun#
> interface, where a user-mode process can have fun with it.
Howabout:
"remap X" Change the (source/dest) network number to X from whatever
it was. This would provide very easy network address translation
in the case that the two netmask widths are identical. This could
be a big feature if people have to start renumbering their
networks but aren't ready yet... cf. rfc1900.
The more general case (such as remapping an entire network
into a single IP address) is slightly harder, since you have
to remember what UDP/TCP ports you have mapped to as well,
time them out, sniff FTP packets, etc... but it can and has
been done...
"divert" would be great for security auditing purposes.
> Comments ?
I'm willing to help.
_______________________________________________________________________________
Archie L. Cobbs, archie@tribe.com * Tribe Computer Works http://www.tribe.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603010218.SAA05571>