Date: Thu, 29 May 2014 20:45:26 +0800 From: "bycn82" <bycn82@gmail.com> To: "'Luigi Rizzo'" <rizzo@iet.unipi.it> Cc: 'FreeBSD Net' <freebsd-net@freebsd.org> Subject: RE: propose a new generic purpose rule option for ipfw Message-ID: <001b01cf7b3b$dfd1cfb0$9f756f10$@gmail.com> In-Reply-To: <CA%2BhQ2%2BgQZQXOj8Ga%2Br%2BORMKX-WVXo=aTND-EA0WPF3Z%2BR30j-g@mail.gmail.com> References: <CAC%2BJH2x08jGWyaRKoE8PwXcwv555EhDP576-WJd5vZDrF%2Bnsbg@mail.gmail.com> <CA%2BhQ2%2BgQZQXOj8Ga%2Br%2BORMKX-WVXo=aTND-EA0WPF3Z%2BR30j-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
=20 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. =20 Sure. When the user need to fulfill a feature and there is a rule option = for it. Then in this scenario . the user should definitely use the = option. Except the user this testing this feature. =20 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. =20 By the way, what is in-kernel bpf. I ve read your dummynet already, = still have some place not clear. =20 This said, even bpf is not a generic firewall mechanism. =20 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. =20 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? =20 cheers luigi =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001b01cf7b3b$dfd1cfb0$9f756f10$>