Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Feb 2000 15:59:30 +0100 (CET)
From:      Luigi Rizzo <luigi@info.iet.unipi.it>
To:        Darren Reed <avalon@coombs.anu.edu.au>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: post 4.0...adoption of pfil(9) from NetBSD ?
Message-ID:  <200002191459.PAA85263@info.iet.unipi.it>
In-Reply-To: <200002191352.AAA06539@cairo.anu.edu.au> from Darren Reed at "Feb 20, 2000 00:52:01 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> Changing routing information is not a problem.  For starters,
> with inbound packets, there is none.

for outbound there is, and one of the biggest problems i had
with dummynet (as an example) was that some code passed
around route structures held in the stack, so you couldn't just keep
a reference and reuse it later. Bad engineering you can say,
and i agree, but fixing this requires fixing the source, not
just defining a filter interface.

> > E.g ip_input.c, the handling of diverted packets is
> > scattered all around. I don;t know how easy would it be to
> > pack all of this in one place, before or after the proto_input
> > routine.
> 
> "divert" is just a mess :-)

i know. But who has the time to fix it!

> I'm not saying merge anything.  But in the case of ipfilter, easier
> to merge ipv6 in than create a whole new 'ipfilter6'.

that's up to the maintainer. does not make a big difference
(well, maybe just the syntax becomes a bit more complex -- ipfw syntax
in this respect is already a mess).

> If you look at how linux's iptables works, there are separate modules
> for each of ip, tcp, udp, icmp, etc.  A packet is filtered by calling
> the appropriate filter routine for that protocol.  In comparison to
> ipfw which does all its port checking, etc, in `one place'.

but layer boundaries are just on paper, in reality especially a firewall
looks all over the headers (and maybe in even more places).
When you filter TCP, you still look at the IP addresses. In ipfw, you
can even look at the UID of the associated PCB.
By registering filters per protocol at different layers, you have a problem:
suppose your rules are the following (in ipfw style, first match wins):

	1: deny ip from A to any
	2: allow tcp from any 23 to any

when you get a TCP packet, when do you invoke the filter, in
tcp_input() or in ip_input() ? You should probably do the call
at the highest possible level in the stack (TCP in this case),
but then you should duplicate rule 1 in the TCP chain or
you are in trouble.

Furthermore you need hooks in all protocol at all levels, and you
depend on upper-level protocols to be implemented properly or
filtering fails -- e.g. if the protocol PGM (to name another one
i am working on) forgets to call the filter, then all PGM packet
will skip the IP check.

What we have now in ipfw is a bit more messy (as you do a lot of
work trying to classify packets) but at least understanding the ruleset is
rather easy, and the places in the kernel where the match is done
are more limited.

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002191459.PAA85263>