New Firewall (hpf) for DragonFlyBSD

[Sebastien Petit]

> On Friday 09 January 2004 18:06, Simon 'corecode' Schubert wrote:
> > On 09.01.2004, at 15:28, Seb wrote:
> > > Here you can found patch for using High Performance Firewall under
> > > DragonFlyBSD. This firewall is a new type and exprimental. It's a
> > > constant
> > > time firewall, so CPU consumption is not dependent of rules number.
> > > This a
> > > turboACL like implementation so the kernel code is very very little.
> > > Actually, hpf recognize some ipfw syntax but an ipfilter parser can be
> > > developped. Dynamic rules are not supported for the moment and some
> > > options
> > > too. You can see at http://www.phear.org/~spe/syntaxe.txt what type of
> > > syntax is recognized.
> >
> > I'm sorry, maybe I'm just ignorant, but doesn't such a tree need 256^14
> > (or 13) entries?
> >

No, the tree represents your rules and is optimized, multiple nodes can link
on only one another node. btw, you can have (with no optimization) 14KBytes
per rule on IA32 maximum. In reality, with optimization tree, the average
size per rule is less than 14 Bytes.

> > Also, using ints to store pointers won't work on all architectures.

This code is i386 oriented but can be changed for storing pointers with 8
bytes or more. This is an experimental code, not a definitve one. I try to
see how I can update it for working under 64 bits architectures. What's the
architecture concerned by the problem of int for storing pointers ?

>
> Yapp - apart from being highly unreadable - your code is _really_ i386
centric
> and does not care about storage sizes or byte order at all. Furthermore
it's
> ignorant on real life things like incomplete/short mbufs, encapsulation
etc.
> pp.

Unreadable is a big word. This is just a traverses tree. I try to see if
there is a problem with byte order (htons(), ntohs()).
btw, I work on hpf actually for deleting problems about incomplete/short
mbufs and encapsulation.

>
> I am really curious how you plan to support IPv6, btw ;)
>

Ipv6 is not difficult, it's just another tree adapted to this protocol, with
a 128 bytes deep for ip src/dst. But I don't support IPv6 for the moment,
it's just for IPv4 on first revisions.

> Nonetheless, it's an interesting approach for very special purpose, but
not
> (yet) fit for real-life applications IMO.

You're right, it'as an experimental code, not a definitive one for
production servers. Try to see this code as proof of concept, bug can be
corrected for other architecture than IA32 rapidly. I work actually for
correcting these problems.
Thank you for your help.

Regards,
Sebastien.
--
spe at xxxxxxxxxxxxxxxx