From owner-freebsd-net  Wed Dec 15 22:11: 9 1999
Delivered-To: freebsd-net@freebsd.org
Received: from netcom.com (netcom3.netcom.com [199.183.9.103])
	by hub.freebsd.org (Postfix) with ESMTP id 8B3BA14CAB
	for <freebsd-net@freebsd.org>; Wed, 15 Dec 1999 22:11:04 -0800 (PST)
	(envelope-from klh@netcom.com)
Received: (from klh@localhost)
	by netcom.com (8.9.3/8.9.3) id WAA11234;
	Wed, 15 Dec 1999 22:11:02 -0800 (PST)
Date: Wed, 15 Dec 99 22:11:02 PST
From: Ken Harrenstien <klh@netcom.com>
To: freebsd-net@freebsd.org
Cc: klh@netcom.com
Subject: ipfw feature requests
Message-ID: <CMM.0.90.4.945324662.klh@netcom3.netcom.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Trying this list because I'm not sure whether the bug report mechanism
should be used for feature requests...

IPFW is an amazingly useful and impressive piece of work.
Nevertheless, while wrestling a bit trying to write a new ruleset for
a 4-interface (!) firewall/gateway, I came up with the following
wishlist.  A cursory inspection of netinet/ip_fw.c suggests that these
might be possible to implement without too much pain, if TPTB decide
they are worthy...

[1] Provide some way to easily match packets that originate from or
    are destined for the local host, regardless of the IP address.
    Some approaches:

    [a] Add "local" as an acceptable keyword for <src> or <dst>.
    Thus "deny all from not local to local" suppresses attempts to contact
    the gateway as a host, while allowing packet forwarding to continue.

    [b] Add "local" as a pseudo-interface name, to match packets that have
    no interface.  Thus "out recv local" would match packets
    originating from the local host.  I wish this could also be used
    to catch packets destined for the local host, but unfortunately
    "in xmit local" won't work as "xmit" can only be used/checked with
    "out" packets, sigh...

    [c] Allow boolean negation of each interface specification; then you can
    say "not any" which would be synonymous with "local" per [b].
    Note that this feature would be very handy in general as it can
    be used with all of the existing interface specs.

[2] Add a keyword such as "unreg" or "rfc1918" for <src> and <dst>
    that would refer to all RFC1918 "unregistered" addresses, specifically
    10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.  (NATD has something
    like this, by the way.)

[3] Consider allowing more negation possibilities in general, e.g. for <proto>
    and <ifc> as well as <src> and <dst>.  <ports> and some of the
    options might also be candidates, but I realize this could get
    out of hand.  "not <ifc>" per [1c] would be the most useful for me.

Obviously none of these add new capabilities per se; they would just
reduce the number of rules necessary (and thus gain a slight measure
of both efficiency and clarity).

If these suggestions would be better sent somewhere else, just let me
know where.

Thanks!
--Ken


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message