kern/121807: Sugestion: TCP and UDP port_table in ipfw

[Ganbold]

The following reply was made to PR kern/121807; it has been noted by GNATS.

From: Ganbold <ganbold at micom.mng.net>
To: bug-followup at FreeBSD.org
Cc: goffredo at gmail.com, Vadim Goncharov <vadim_nuclight at 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