Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Robert Watson]

On Sat, 19 Feb 2000, Luigi Rizzo wrote:

> > 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.

Luigi,

Don't know if you've had a chance to look at the BSDI work at all, but
last I heard they were actually using an extended bpf to do a log of the
abstraction work for packet filtering, nat, and management.  Right now we
have a diverse set of packet filtering mechanisms, and as Darren points
out, filtering languages depend on the layer where they must be applied.
The BSDI solution allows bpf to be used to match a variety of protocols,
and rather than making layer-specific filtering code in the kernel, you
push in layer-specific bpf filters from userland.  As I understand it,
they also allow appropriately privileged bpf filters to do
live-modification of the packets in transit, allowing flexible
user-defined NAT behavior, etc.  You could imagine ipfw converting its
rule matching to bpf filters before pushing the code into kernel, etc.

I'm really not very familiar with the BSD/OS work, it was pointed out to
be at a recent DCFUG, but it might be worth looking into.

Another interesting question about filtering behavior is how it should be
integrated with NetGraph, as NetGraph provides the opportunity for much
greater flexibility in network stack construction.


  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Darren Reed]

In some mail from Luigi Rizzo, sie said:
> 
> > 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.

mmm, fixing the source.

> > 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.

So ?

> 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.

Urgh, I see you're not familiar with theirs either.  The filtering
is invoked from IP (just like ipfw) but rather than do "if tcp then
check ports and flags", it does "call per-protocol check".  Maybe
I'm just not explaining this clearly...

> 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.

Huh ?  I think you're not understanding what I'm saying.

> 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.

I wouldn't call it "limited" :)  There are more ipfw hooks required
than ipfilter hooks for basically the same job :-)

You would do well to download a linux kernel and see what they do,
as well as looking at how NetBSD now handles it.  My descriptions
have been heavily modified to be concise and are not doing either
OS justice.

Darren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Luigi Rizzo]

> 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, [EMAIL PROTECTED]  . 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Darren Reed]

In some mail from Luigi Rizzo, sie said:
> 
> > > The issue of one vs. multiple lists (per direction, interface,
> > > protocol, you name it) has been discussed some time ago.  For sure
> > > multiple lists are a (minor, given that we can start the ipfw lists
> > > with a few of "skipto") performance improvement over a single one,
> > > at the possible price of having some duplication in writing filters
> > > and even defining how many lists are appropriate.
> > 
> > To me, this outlines how bad the current system for ipfw support
> > has become.  Need something ? Just hack the appropriate part of
> > the kernel.  There's no real design in the infrastructure for
> 
> hmmm... this criticism, which i partly share, seems unrelated to
> the single vs. multiple list issue.
> 
> I agree with you that having a protocol-independent interface for
> the firewall would be nicer, but then you should also remember that
> things like divert, forward, tee and possibly also NAT can only
> be defined as hacks, and as such i am not very optimistic that one
> can find common mechanisms for calling the filter unless one
> tolerates some duplication of work.

NAT can easily be implemented as a `filter'.

I suspect all of the others you mention (divert/forward/tee) also
can be.  IP Filter has, for years, supported a "tee-like" feature
where it will send a duplicate of a packet out another interface.
It may even do "forward" but not "divert"...I don't follow ipfw
features very closely O:-)

> Example: when the filter forwards a packet to somewhere else,
> you might have to change the route info associated with the
> packet. When the filter duplicates or steals a packet, the things
> to do depend a lot on what the rest of the standard function
> does.

Changing routing information is not a problem.  For starters,
with inbound packets, there is none.

> 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 :-)

[...]
> My second comment is on the usefulness of a unified filter.
> ipfw is clearly IPv4 centric, ip6fw is IP6 centric, and maybe there
> is no ipxfilter.

Just because ipfw/ip6fw are only associated with a single protocol
does not mean they can't use a generic interface in place of one
specific to them.

I think it is short sighted to assume that whatever is there now
will be there in X years time or that nobody will want to use
their own whatever.  By building a generic framework (not that
of a unified filer), you support multiple filters out of the
box and each can work without any special changes to the kernel.

> Why ? because the authors of the 2/3 different filters
> know enough about their protocol but not enough about the others.
> Now we can work on each one separately, and at a much higher rate than
> we could achieve by having a single monolitic filter which people
> would be scared to touch fearing to break support of some of the
> other protocols (or, more likely, people would end up adding features
> to just one of the protos leaving the other ones unchanged).
> So, in my opinion a merging effort would be a threat to improvement
> (and the same applies to having to maintain portable software...
> i guess you know the problem very well with ipfilter!)

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

> Of course there are some common functionalities such as (to speak
> of a couple with which i am very familiar) traffic shaping, or
> keeping state. But the common infrastructure (a scheduler in the
> former case) is very very easy to share, while i see much more
> difficulty in maintaining a single unified filter for all protocols.

That depends on how you view and design it, doesn't it ?  In so far
as IP is concerned, the only significant difference is address size.

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'.

The idea with pfil(9) as it is in NetBSD now is to allow a filter
module to register if it wants to filter inbound (or outbound or
both) packets for a given protocol.  e.g. I could write a small
anti DDoS thing and filter inbound IPv4 packets only and not need
to make any changes to the standard kernel source.  Using this
approach, ipfw would register for in/fwd/out ipv4 packets and
ip6fw would register for in/fwd/out ipv6 packets.

Darren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Luigi Rizzo]

> > The issue of one vs. multiple lists (per direction, interface,
> > protocol, you name it) has been discussed some time ago.  For sure
> > multiple lists are a (minor, given that we can start the ipfw lists
> > with a few of "skipto") performance improvement over a single one,
> > at the possible price of having some duplication in writing filters
> > and even defining how many lists are appropriate.
> 
> To me, this outlines how bad the current system for ipfw support
> has become.  Need something ? Just hack the appropriate part of
> the kernel.  There's no real design in the infrastructure for

hmmm... this criticism, which i partly share, seems unrelated to
the single vs. multiple list issue.

I agree with you that having a protocol-independent interface for
the firewall would be nicer, but then you should also remember that
things like divert, forward, tee and possibly also NAT can only
be defined as hacks, and as such i am not very optimistic that one
can find common mechanisms for calling the filter unless one
tolerates some duplication of work.
Example: when the filter forwards a packet to somewhere else,
you might have to change the route info associated with the
packet. When the filter duplicates or steals a packet, the things
to do depend a lot on what the rest of the standard function
does.  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.
And honestly, once the initial hooks are in the proto_input routine,
it is unlikely that you have to touch them anymore. We don't add
a protocol stack everyday, i think we have 3 functional ones at
the moment.

My second comment is on the usefulness of a unified filter.
ipfw is clearly IPv4 centric, ip6fw is IP6 centric, and maybe there
is no ipxfilter. Why ? because the authors of the 2/3 different filters
know enough about their protocol but not enough about the others.
Now we can work on each one separately, and at a much higher rate than
we could achieve by having a single monolitic filter which people
would be scared to touch fearing to break support of some of the
other protocols (or, more likely, people would end up adding features
to just one of the protos leaving the other ones unchanged).
So, in my opinion a merging effort would be a threat to improvement
(and the same applies to having to maintain portable software...
i guess you know the problem very well with ipfilter!)

Of course there are some common functionalities such as (to speak
of a couple with which i am very familiar) traffic shaping, or
keeping state. But the common infrastructure (a scheduler in the
former case) is very very easy to share, while i see much more
difficulty in maintaining a single unified filter for all protocols.

cheers
luigi
---+-
  Luigi RIZZO, [EMAIL PROTECTED]  . 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Darren Reed]

In some mail from Luigi Rizzo, sie said:
> 
> > I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
> > to see what's required for IP-Filter (hoping for a clean interface)
> > and the response is "sigh".  The old ipfw mechanism needs to be
> > abandoned, IMHO.
> 
> can you comment a bit more ? I am a bit unclear on what
> exactly is thay you don't find appropriate in ipfw etc.

The problem is that the in kernel support for ipfw/ipfilter is
*specific* to each.  There is no mechanism for 3rd party people
to add their own without making the same ugly hacks as already
exists unless they choose to use the ipfw/ipfilter hook instead.

i.e. each time we want to filter a new protocol we need to hack
the various functions for a filter specific hook rather than
using a generic filter/calling mechanism.
 
> If you have an URL for a pfil(9) manpage i would appreciate it.

See below for man page from 1.4.

> Some comments:
> 
> The issue of one vs. multiple lists (per direction, interface,
> protocol, you name it) has been discussed some time ago.  For sure
> multiple lists are a (minor, given that we can start the ipfw lists
> with a few of "skipto") performance improvement over a single one,
> at the possible price of having some duplication in writing filters
> and even defining how many lists are appropriate.

To me, this outlines how bad the current system for ipfw support
has become.  Need something ? Just hack the appropriate part of
the kernel.  There's no real design in the infrastructure for
ipfw.  Sort of what Linux was like before they redesigned their
firewalling, etc, interfaces using netfilter.

I must point out that whilst pfil(9) as found in NetBSD does not
provide enough support for the various FreeBSDisms to be put in
as it is, I think it can be expanded upon, whilst still supporting
the same interface, to meet FreeBSD's needs.

Darren

PFIL(9)  NetBSD Kernel Manual  PFIL(9)

NAME
 pfil, pfil_hook_get, pfil_add_hook, pfil_remove_hook - packet filter in-
 terface

SYNOPSIS
 #include 
 #include 
 #include 
 #include 

 struct packet_filter_hook *
 pfil_hook_get(int);

 void
 pfil_add_hook(int (*func)(), int flags);

 void
 pfil_remove_hook(int (*func)(), int flags);

DESCRIPTION
 The pfil interface allows a function to be called on every incoming or
 outgoing packets.  The hooks for these are embedded in the ip_input() and
 ip_output() routines.  The pfil_hook_get() function returns the first
 member of a particular hook, either the in or out list.  The
 pfil_add_hook() function takes a function of the form below as it's first
 argument, and the flags for which lists to add the function to.  The pos-
 sible values for these flags are some combination of PFIL_IN and
 PFIL_OUT.  The pfil_remove_hook() removes a hook from the specified
 lists.

 The func argument is a function with the following prototype.

 func(void *data, int hlen, struct ifnet *net, int dir, struct mbuf **m)

 The data describes the packet.  Currently, this may only be a pointer to
 a ip structure.  The net and m arguments describe the network interface
 and the mbuf holding data for this packet.  The dir is the direction; 0
 for incoming packets and 1 for outgoing packets.  if the function returns
 non-zero, this signals an error and no further processing of this packet
 is performed.  The function should set errno to indicate the nature of
 the error.  It is the hook's responsibiliy to free the chain if the pack-
 et is being dropped.

 The pfil interface is enabled in the kernel via the PFIL_HOOKS option.

RETURN VALUES
 If successful pfil_hook_get() returns the first member of the packet fil-
 ter list, pfil_add_hook() and pfil_remove_hook() are expected to always
 succeed.

HISTORY
 The pfil interface first appeared in NetBSD 1.3.  The pfil input and out-
 put lists were originally implemented as 
 LIST structures; however this was changed in NetBSD 1.4 to TAILQ struc-
 tures.  This change was to allow the input and output filters to be pro-
 cessed in reverse order, to allow the same path to be taken, in or out of
 the kernel.

BUGS
 The current pfil implementation will need changes to suit a threaded ker-
 nel model.

SEE ALSO
 bpf(4)

NetBSD 1.4  August 4, 1996   1


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: post 4.0...adoption of pfil(9) from NetBSD ?

[Luigi Rizzo]

> I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
> to see what's required for IP-Filter (hoping for a clean interface)
> and the response is "sigh".  The old ipfw mechanism needs to be
> abandoned, IMHO.

can you comment a bit more ? I am a bit unclear on what
exactly is thay you don't find appropriate in ipfw etc.
If you have an URL for a pfil(9) manpage i would appreciate it.

Some comments:

The issue of one vs. multiple lists (per direction, interface,
protocol, you name it) has been discussed some time ago.  For sure
multiple lists are a (minor, given that we can start the ipfw lists
with a few of "skipto") performance improvement over a single one,
at the possible price of having some duplication in writing filters
and even defining how many lists are appropriate.

> The advantage to using pfil(9) from NetBSD (unless someone feels
> the distinct need to roll their own code to do something the same)
> is it provides a clean interface rather than requiring people to
> patch things like ip6_input.c, etc.

I think that if you want to do tricks such as
forward, divert, dummynet and the like, it is unavoidable to
have to hook in the middle of ${proto}_{input|output}.c, as
you end up doing protocol-specific things...

cheers
luigi

---+-
  Luigi RIZZO, [EMAIL PROTECTED]  . 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

post 4.0...adoption of pfil(9) from NetBSD ?

[Darren Reed]

I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
to see what's required for IP-Filter (hoping for a clean interface)
and the response is "sigh".  The old ipfw mechanism needs to be
abandoned, IMHO.

For those that aren't aware, pfil(9) in NetBSD used to provide two
lists for filtering IP packets going in.out.  It now provides input
and output filtering for both IPv4 and IPv6 with the list heads and
other meta data stored in protosw, making it possible to further
expand to develop UDP/TCP, etc, specific filters at some later time.
The only hurdle I can see for FreeBSD is a missing "forward" list,
but that's only a minor issue.

The advantage to using pfil(9) from NetBSD (unless someone feels
the distinct need to roll their own code to do something the same)
is it provides a clean interface rather than requiring people to
patch things like ip6_input.c, etc.

Bringing pfil(9) into FreeBSD is most definately a post FreeBSD-4.0
exercise.

Comments ?

Darren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message