From nobody@FreeBSD.org  Mon Mar 17 20:18:39 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 89F34106568B
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 17 Mar 2008 20:18:39 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 7BC538FC22
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 17 Mar 2008 20:18:39 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m2HKFCbD085758
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 17 Mar 2008 20:15:12 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m2HKFCU0085757;
	Mon, 17 Mar 2008 20:15:12 GMT
	(envelope-from nobody)
Message-Id: <200803172015.m2HKFCU0085757@www.freebsd.org>
Date: Mon, 17 Mar 2008 20:15:12 GMT
From: Joao Rocha Braga Filho <goffredo@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Sugestion: TCP and UDP port_table in ipfw
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         121807
>Category:       kern
>Synopsis:       [request] TCP and UDP port_table in ipfw
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ipfw
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 17 20:20:01 UTC 2008
>Closed-Date:    
>Last-Modified:  Thu Sep 25 11:30:01 UTC 2008
>Originator:     Joao Rocha Braga Filho
>Release:        6.2, 6.3 and 7.0
>Organization:
Paraty.com
>Environment:
>Description:
Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit
in ipfw rule. It is good to use in QoS.

Example

ipfw add allow { tcp or udp } from any port_table(10) to any

ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535

# Deny bad ports
ipfw add deny { tcp or udp } from any to any port_table(11)

ipfw port_table 11 add 135,137-139,445

ipfw add queue 100 udp from any port_table(20) to any
ipfw port_table(20) add 123,53


>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: linimon 
State-Changed-When: Tue Mar 18 06:52:41 UTC 2008 
State-Changed-Why:  
Mark suspended awaiting patches. 


Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Mar 18 06:52:41 UTC 2008 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=121807 

From: Vadim Goncharov <vadim_nuclight@mail.ru>
To: Joao Rocha Braga Filho <goffredo@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw
Date: Wed, 19 Mar 2008 14:47:01 +0600

 Hi Joao Rocha Braga Filho! 
 
 On Mon, 17 Mar 2008 20:15:12 GMT; Joao Rocha Braga Filho <goffredo@gmail.com> wrote:
 
 > Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit in ipfw rule. It is good to use in QoS.
 > Example
 > ipfw add allow { tcp or udp } from any port_table(10) to any
 > ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535
 > # Deny bad ports
 > ipfw add deny { tcp or udp } from any to any port_table(11)
 > ipfw port_table 11 add 135,137-139,445
 > ipfw add queue 100 udp from any port_table(20) to any
 > ipfw port_table(20) add 123,53
 
 For what puprose should it _really_ serve? Limit-upping? Per-packet speed
 optimisation? More handy config preapring? Should that tables serve as
 a collection-only, or do have tableargs, and for what practical purpose that
 tableargs would be useful?
 
 If it is simply annoying to put long list in config several times, then it is
 correctly solved by shell vars:
 good_ports="20,21,25,110,443,993,995,1025-65535"
 
 ipfw add allow { tcp or udp } from any $good_ports to any
 ipfw add allow { tcp or udp } from ant to $my_server $good_ports
 
 If you care about both value-repeating, limit of 30 items and slightly about
 speed of packet processing, then you'd better classify your traffic with
 or-blocks on start of ruleset with tags:
 
 ipfw add 1 count tag 1 { src-port 20,21,25,110,443,993,995,1025-65535  \
      or src-port 1,2,3,4,5,6,7,8,9,10,11,12,13,...long-list2...,29,30  \
      or src-port ...list3... } // can have up to 8 full 30-port blocks per rule
 ipfw add 2 count tag 2 dst-port 135,137-139,445 // and so on
 
 Packet can have more than one tag at a time, so then you can write like:
 
 ipfw add queue 100 udp from any to any tagged 3
 ipfw add allow { tcp or udp } from any to any tagged 1,2
 
 
 And if your suggested port table is concerned on a per-packet performance, like
 our IP tables do, then how do you suggest it to be implemented in-kernel?
 Current tables for IP are radix trees, they consume a lot of kernel memory
 (which is a scarce resource) and process in term of mask - but it is not
 handy to specify ports in form like "128/8". And any form of tree will consume
 to a lot of memory per entry.
 
 It can be thought as a bit set, one bit for every port, very fast, but will
 consume 8K per one table - 1 meg for 128 such tables, unacceptable, again.
 
 So, I think it is best to use tags for your purposes.
 
 -- 
 WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
 [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

From: Ganbold <ganbold@micom.mng.net>
To: bug-followup@FreeBSD.org
Cc: goffredo@gmail.com, Vadim Goncharov <vadim_nuclight@mail.ru>
Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw
Date: Thu, 25 Sep 2008 19:20:27 +0800

 Hi,
 
 Vadim Goncharov wrote:
 >  
 >  > Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit in ipfw rule. It is good to use in QoS.
 >  > Example
 >  > ipfw add allow { tcp or udp } from any port_table(10) to any
 >  > ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535
 >  > # Deny bad ports
 >  > ipfw add deny { tcp or udp } from any to any port_table(11)
 >  > ipfw port_table 11 add 135,137-139,445
 >  > ipfw add queue 100 udp from any port_table(20) to any
 >  > ipfw port_table(20) add 123,53
 >  
 >  For what puprose should it _really_ serve? Limit-upping? Per-packet speed
 >  optimisation? More handy config preapring? Should that tables serve as
 >  a collection-only, or do have tableargs, and for what practical purpose that
 >  tableargs would be useful?
 >  
 >  If it is simply annoying to put long list in config several times, then it is
 >  correctly solved by shell vars:
 >  good_ports="20,21,25,110,443,993,995,1025-65535"
 >  
 >  ipfw add allow { tcp or udp } from any $good_ports to any
 >  ipfw add allow { tcp or udp } from ant to $my_server $good_ports
 >  
 >  If you care about both value-repeating, limit of 30 items and slightly about
 >  speed of packet processing, then you'd better classify your traffic with
 >  or-blocks on start of ruleset with tags:
 >  
 >  ipfw add 1 count tag 1 { src-port 20,21,25,110,443,993,995,1025-65535  \
 >       or src-port 1,2,3,4,5,6,7,8,9,10,11,12,13,...long-list2...,29,30  \
 >       or src-port ...list3... } // can have up to 8 full 30-port blocks per rule
 >  ipfw add 2 count tag 2 dst-port 135,137-139,445 // and so on
 >  
 >  Packet can have more than one tag at a time, so then you can write like:
 >  
 >  ipfw add queue 100 udp from any to any tagged 3
 >  ipfw add allow { tcp or udp } from any to any tagged 1,2
 >  
 >  
 >  And if your suggested port table is concerned on a per-packet performance, like
 >  our IP tables do, then how do you suggest it to be implemented in-kernel?
 >  Current tables for IP are radix trees, they consume a lot of kernel memory
 >  (which is a scarce resource) and process in term of mask - but it is not
 >  handy to specify ports in form like "128/8". And any form of tree will consume
 >  to a lot of memory per entry.
 >  
 >  It can be thought as a bit set, one bit for every port, very fast, but will
 >  consume 8K per one table - 1 meg for 128 such tables, unacceptable, again.
 >  
 >  So, I think it is best to use tags for your purposes.
 
 For small number of port entries I thought port lookup table
 functionality is quite useful. It gives benefit like no need to modify 
 existing rule,
 adding/deleting port entries is easy.
 
 I did some small tests and it seems like working.
 
 Patches are at:
 http://people.freebsd.org/~ganbold/ipfw_port_table/
 
 The output of some usage samples is at:
 http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt 
 
 
 Patches can be successfully applied to CURRENT. Didn't test RELENG_7 due to
 no RELENG_7  PC :)
 Please let me know your thoughts. I'm happy to discuss to improve the 
 patch.
 Correct me if I'm doing something wrong here.
 
 thanks,
 
 Ganbold
 
>Unformatted:
