Date: Thu, 29 May 2014 10:14:54 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Bill Yuan <bycn82@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: propose a new generic purpose rule option for ipfw Message-ID: <CA%2BhQ2%2BgQZQXOj8Ga%2Br%2BORMKX-WVXo=aTND-EA0WPF3Z%2BR30j-g@mail.gmail.com> In-Reply-To: <CAC%2BJH2x08jGWyaRKoE8PwXcwv555EhDP576-WJd5vZDrF%2Bnsbg@mail.gmail.com> References: <CAC%2BJH2x08jGWyaRKoE8PwXcwv555EhDP576-WJd5vZDrF%2Bnsbg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 29, 2014 at 9:25 AM, Bill Yuan <bycn82@gmail.com> wrote: > hi > > the rule of ipfw is kind of semantic, and it is powerful. so it means goo= d > for normal users. but not for developers of it, because simplicity actual= ly > =E2=80=8B...=E2=80=8B > > So i am proposing a new rule option `u32` and the usage will be "u32 > <position> <hex value>" > > e.g. > > >ipfw add 1 allow all from any to any u32 0 0x112233445566 layer2 > > It means if part of the traffic(start from position 0) is equal to the > 0x112233445566, then it means matched. > > Or maybe the usage will be more complex that the above. maybe "u32 > <position> <mask> <value>" > > e.g > > >ipfw add 1 allow all from any to any u32 0 0xFFFFFF000000FFFFFF000000 > 0x111111000000222222000000 > layer2 > the traffic will be AND the <mask> before comparing the <value>. > > > It sounds like "nothing impossible" with this feature!. > > It is a really powerful thing in my opinion. but it has requirement, to > master it requires the knowledge of the structure of the > packet/frame/whatever. > > Anyone like this feature? Like it ? please voice out. > > Sure your generic binary match could be a welcome addition to ipfw. But its usefulness is extremely limited in practice, as it only lets you match stuff in fixed position of a packet, and it is not even good to do other relatively simple things such as skip options and the like. If you have spare time you might try how hard would it be to hook the in-kernel bpf to ipfw. That would be a superset of what you propose, and avoids duplication of effort and features. This said, even bpf is not a generic firewall mechanism. Much of the power of a firewall comes from the availability of high level functions and data structures and metadata access functions to reduce the complexity and improve the quality of matches. Many of the ipfw options are just for that: address and port bitmaps, tables, reverse path lookup, metadata lookups and so on. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BgQZQXOj8Ga%2Br%2BORMKX-WVXo=aTND-EA0WPF3Z%2BR30j-g>