propose a new generic purpose rule option for ipfw

Luigi Rizzo rizzo at iet.unipi.it
Thu May 29 13:39:35 UTC 2014


On Thu, May 29, 2014 at 3:32 PM, Andreas Nilsson <andrnils at gmail.com> wrote:

> On Thu, May 29, 2014 at 3:10 PM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
>
>> On Thu, May 29, 2014 at 08:45:26PM +0800, bycn82 wrote:
>> ...
>> >
>> > Sure, that is the reason why developers are providing more and more
>> rule options. But the my question is do we have enough options to match all
>> the fixed position values?
>>
>> we do not have an option for fixed position matching.
>>
>> As i said, feel free to submit one and i will be happy to
>> import it if the code is clean (btw i am still waiting
>> for fixes to the other 'rate limiting' option you sent),
>> but keep in mind that 'fixed position' is mostly useless.
>>
>> More useful options would be one where you express the position as
>>
>>         '{MAC|VLAN|IP|UDP|TCP|...|PAYLOAD}+offset'
>>
>> so at least you can adapt to variant headers, or one where you can look
>> for a pattern in the entire packet or in a portion of it.
>>
>> cheers
>> luigi
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
> Wouldn't PAYLOAD require possibly reassembly of a fragmented packet?
>

​well, other firewalls do reassemble fragments, ipfw does not
(actually there was some code floating around in the past that
did implement a reassembly, not sure if it was committed).
With this in mind, PAYLOAD would not be that different
from TCP if you think that you can have a ton of IPV6 headers and
extensions.​ So if/when we implement reassembly, that would be
the default for any action that searches past the end of
the first fragment.

Except from fragmentation, all ipfw instructions already track
the beginning of the relevant header for the info at hand
(typically skipping ip options or ipv6 headers).
It costs something, but not a fortune.

cheers
luigi


> It certainly is a good feature, don't get me wrong. But what are the
> performance hits?
>
> Best regards
> Andreas
>



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo at iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2211611               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
-----------------------------------------+-------------------------------


More information about the freebsd-net mailing list