On 23:42:20 Nov 12, Erik Osterholm wrote:
> My understanding (and please correct me if I'm wrong) is that
> keeping state requires fragmented packet reassembly, which can break
> some applications.
You mean that you cannot support "broken applications" if you do
Packet reassembly happens if you use a scrub rule as well.
The main problem with fragmentation leaving aside all performance and
security considerations is that you cannot figure out anything useful
from the IP fragments.
The headers simply lack enough information for you to deduce anything.
Reassembly does have an overhead..you can perhaps mention a delay
involved in waiting for all fragments to arrive. But AFAIK it only
helps if you reassemble. Never hurts.
I am not aware of any breakage due to reassembly. ( But I could be
Now I specifically asked about scrub because scrub does a lot of other
things which might "correctly" break "broken applications."
I just wanted to give him enough rope. Very likely scrub causes no harm.
Neither would keeping state...
> Also, I've always followed the conventional wisdom
> that bridges shouldn't keep state. A posting from the maintainer
> supports this:
> Maybe this has changed--I'm not sure, but so far I haven't seen
> performance issues with pf and if_bridge without keeping state, so I
> haven't been worried about it.
I just read the post you linked. Thanks. :)
I would imagine that bridges would make things difficult for pf.
I have never worked with bridges , so I cannot comment.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"