From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 1 21:09:33 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D9FDCE8; Fri, 1 Aug 2014 21:09:33 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D627B2778; Fri, 1 Aug 2014 21:09:32 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XDG7v-000MGI-Qa; Fri, 01 Aug 2014 20:56:19 +0400 Message-ID: <53DC01DE.3000000@FreeBSD.org> Date: Sat, 02 Aug 2014 01:08:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-ipfw , "freebsd-net@freebsd.org" Subject: ipfw named objejcts, table values and syntax change X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 21:09:33 -0000 Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw permits writing this: ipfw table tb1 create type cidr ipfw add allow ip from table(tl1) to any ipfw add allow ip from any lookup dst-ip tb1 ipfw table if1 create type iface ipfw add skipto tablearg ip from any to any via table(if1) or even this: ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 ipfw add allow ip from any to any flow table(fl1) all these changes fully preserve backward compatibility. (actually tables needs now to be created before use and their type needs to match with opcode used, but new ipfw(8) performs auto-creation for cidr tables). There is another thing I'm going to change and I'm not sure I can keep the same compatibility level. Table values, from one point of view, can be classified to the following types: - skipto argument - fwd argument (*) - link to another object (nat, pipe, queue) - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) There are the following reasons why I think it is necessary to implement explicit table values typing (like tables): - Implementing fwd tablearg for IPv6 hosts requires indirection table - Converting nat/pipe instance ids to names renders values unusable - retiring old hack with storing saved pointer of found object/rule inside rule w/o proper locking - making faster skipto So, as the result, table will have lookup key type (already done), value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some additional restrictions (like inability to add non-existing nat instance id). This change will break (at least) scenarios where people are using one table for both nat/pipe instances (and keep nat ids in sync with pipe ones). For example: ipfw table 1 add 10.0.10.0/24 110 ipfw table 1 add 10.0.20.0/24 120 ipfw add 100 nat tablearg from table(1) to any via vlanX in .. ipfw add 500 pipe tablearg from table(1) to any via ix0 out It looks like it is not so easy to bind values for given table to different objects (or different tasks) (and lack of compatibility kills hope for MFC). Ideas? From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 2 04:26:26 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30884E27; Sat, 2 Aug 2014 04:26:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EEC9A263E; Sat, 2 Aug 2014 04:26:25 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-253-202.lns20.per2.internode.on.net [121.45.253.202]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s724QKhE032342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 21:26:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53DC6866.2090205@freebsd.org> Date: Sat, 02 Aug 2014 12:26:14 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , freebsd-ipfw , "freebsd-net@freebsd.org" Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> In-Reply-To: <53DC01DE.3000000@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 04:26:26 -0000 On 8/2/14, 5:08 AM, Alexander V. Chernikov wrote: > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). I think this makes sense I have myself been responsible for adding 'odd' usages to tables e.g. fwd tablearg and have thought myself that "really we need to be able to specify tables more specifically" so don't expect me to argue against this :-) > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 2 06:33:05 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 262B880E; Sat, 2 Aug 2014 06:33:05 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5EC21D8; Sat, 2 Aug 2014 06:33:03 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id 10so3910485lbg.12 for ; Fri, 01 Aug 2014 23:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9AoiPl5h8zF57KbH4toC+mA857ISwLMk5fgq/yciFvk=; b=AZ+1EGkZBTCUAyjAR3LyenkQ56fHDz1uBjPceGfETDUi1f+F9VnVhheW61H1GZ1LKh qKvQf5U3QxO9nqbSHso9S0e4MwY6cS0vKDjhStrCmKR661Rtk6wgAfPGxkgn57mXR5qg Yy5ynXz9d9hQ55o5yNxouRXrJH2ARG3UNNks9NDW9C9OieBtL8fFDI3XOaKd85pRFwMp oHUTpdliy6xMivnu9af9H1AQnM45r9QzCkGWGeuotr6DtjWF59Vu5asXAaJQRd7Spg7s mlM8QRHHo6R79Spz4S2+9ZxY+fshAyiUe6TjZrQlNYkbLup6QxG7gt8uyFpQx717LTc4 m5+g== MIME-Version: 1.0 X-Received: by 10.152.245.9 with SMTP id xk9mr154107lac.80.1406961181905; Fri, 01 Aug 2014 23:33:01 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.177.234 with HTTP; Fri, 1 Aug 2014 23:33:01 -0700 (PDT) In-Reply-To: <53DC01DE.3000000@FreeBSD.org> References: <53DC01DE.3000000@FreeBSD.org> Date: Sat, 2 Aug 2014 08:33:01 +0200 X-Google-Sender-Auth: iscDiUoXhV8wSwUrZbHWN14NANg Message-ID: Subject: Re: ipfw named objejcts, table values and syntax change From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 06:33:05 -0000 On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit= ) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > =E2=80=8B=E2=80=8Bi don't buy the idea that you need typed arguments for all the cases above. Maybe the case that may make sense is the fwd argument (and in the future something else). We already discussed, i think, the fact that now it is legal to have references to non existing things (skipto, pipes etc.) implemented as u32. Removing that would break configurations. Efficiency is not affected, even for skipto, and while i agree that unprotected writes to the pointers in rules should not happen, these pointers are changed infrequently so a global read-mostly lock should be sufficient to protect all changes to the rules. cheers luigi > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@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) -----------------------------------------+------------------------------- From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 2 08:33:38 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 703429A1; Sat, 2 Aug 2014 08:33:38 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD002221; Sat, 2 Aug 2014 08:33:38 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XDQnv-00040n-Q2; Sat, 02 Aug 2014 08:20:23 +0400 Message-ID: <53DCA25C.1000108@FreeBSD.org> Date: Sat, 02 Aug 2014 12:33:32 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 08:33:38 -0000 On 02.08.2014 10:33, Luigi Rizzo wrote: > > > > On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov > > wrote: > > Hello all. > > I'm currently working on to enhance ipfw in some areas. > The most notable (and user-visible) change is named table support. > The other one is support for different lookup algorithms for different > key types. > > For example, new ipfw permits writing this: > > ipfw table tb1 create type cidr > ipfw add allow ip from table(tl1) to any > ipfw add allow ip from any lookup dst-ip tb1 > > ipfw table if1 create type iface > ipfw add skipto tablearg ip from any to any via table(if1) > > or even this: > ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port > ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 > ipfw add allow ip from any to any flow table(fl1) > > all these changes fully preserve backward compatibility. > (actually tables needs now to be created before use and their type needs > to match with opcode used, but new ipfw(8) performs auto-creation > for cidr tables). > > There is another thing I'm going to change and I'm not sure I can keep > the same compatibility level. > > Table values, from one point of view, can be classified to the following > types: > > - skipto argument > - fwd argument (*) > - link to another object (nat, pipe, queue) > - plain u32 (not bound to any object) > (divert/tee,netgraph,tag/utag,limit) > > There are the following reasons why I think it is necessary to implement > explicit table values typing (like tables): > - Implementing fwd tablearg for IPv6 hosts requires indirection table > - Converting nat/pipe instance ids to names renders values unusable > - retiring old hack with storing saved pointer of found object/rule > inside rule w/o proper locking > - making faster skipto > > > ​​i don't buy the idea that you need typed arguments > for all the cases above. Maybe the case that > may make sense is the fwd argument (and in the future > something else). > We already discussed, i think, the fact that now it > is legal to have references to non existing things > (skipto, pipes etc.) implemented as u32. > Removing that would break configurations. It depends on actual implementation. This can be preserved by auto-creating necessary objects in kernel and/or in userspace, so we can (and should) avoid breaking in this particular way. > > Efficiency is not affected, even for skipto, It depends on workload. While binary search is fast in terms of cpu, it is may be not so fast in terms of memory (since each of the rule is allocated by separate malloc() (and that is another thing which is worth discussing)). > and while i agree that unprotected writes to the pointers > in rules should not happen, these pointers are changed > infrequently so a global read-mostly lock should be > sufficient to protect all changes to the rules. > > cheers > luigi > > > So, as the result, table will have lookup key type (already done), > value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some > additional restrictions (like inability to add non-existing nat instance > id). > > This change will break (at least) scenarios where people are > using one table for both nat/pipe instances (and keep nat ids in sync > with pipe ones). For example: > > ipfw table 1 add 10.0.10.0/24 110 > ipfw table 1 add 10.0.20.0/24 120 > > ipfw add 100 nat tablearg from table(1) to any via vlanX in > .. > ipfw add 500 pipe tablearg from table(1) to any via ix0 out > > It looks like it is not so easy to bind values for given table to > different objects (or different tasks) (and lack of compatibility kills > hope for MFC). > > Ideas? > > > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org > " > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@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) > -----------------------------------------+-------------------------------