* Daniel Ouellet <[email protected]> [2009-04-08 21:12]:
>> Which will soon be no longer.
>
> I only have one small question left if I may. I do see plenty of changes
> from Henning and others on this and still plenty going in pf in CVS.
>
> I am not sure I follow it all yet and may be it's because it's not all
> finish, but scrub isn't going to be remove all together from pf is it?
>
> I am not clear as to what part of scrub is changing or being removed.
>
> Can just a quick summary, or even one line answer provide some details
> as to what is actually being removed, or changed from it?
>
> I can wait until the man page is changed too, but I wonder what is it
> actually really going on there if I may?
scrub tried to solve to problem spaces at once that should not have
been solved at once: fragment reassembly (which has to work
per-packet) and packet modification, to put it broad, which can and
should be done stateful. there is an historic reason for that, but it
is historic and no longer relevant.
fragment reassembly has been split off and is a simple on-off button
with just one option (no-df) now. fragment reassembly now _only_ ever
deals with fragments, nothing else. the alternate reassemblers have
been removed as well, only full reassembly remains. the others are no
longer relevant, since we see close to zero fragments these days
anyway, things in the kernel have changed so that the memory needed
for full reassembly is not that much of an issue any more (it is not
much anyway, and we have good limiting mechnisms in place) and
machines have gotten faster and better equipped with memory.
the remaining scrub functionality has been moved to options to
regular rules, and thus now happens stateful. it is cleaner and
considerably faster as well.
this started when I ran a lot of benchmarks at c2k8 and discovered how
surprisingly expensive scrub was. this lead to a lot of head scratching
and re-thinking, and discussions with other developers (mostly ryan
and mike frantzen), resulting in this new design. i worked it out and
put it in code form at the n2k9 hackathon in basel in january (need
more proof we need those hackathons to proceed?).
the performance gain is somewhere around 7% in the most simple and
most typical case ("scrub in" as only scrub rule), the more scrub
rules the more.
I developed match rules on top because rulesets would become too
complicated otherwise (had to add the same scrub statement too
all/many pass rules if you did max-mss or the like). and i had wanted
that for many years :)
--
Henning Brauer, [email protected], [email protected]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
