propose a new generic purpose rule option for ipfw

[Andreas Nilsson]

On Thu, May 29, 2014 at 3:39 PM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

>
>
>
> 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?
>>
>
> Good enough for me.

I might be able to get some time on a xena 10g device to check some numbers
if there is any interest for coming changesets.

Best regards
Andreas


> ​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)
> -----------------------------------------+-------------------------------
>