Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Thursday 2008-05-22 21:18, Patrick McHardy wrote:
>
>   
>
>> Additionally it natively supports sets, bitmaps and hashes, so your
>> 500 source IP rules can be represented as a single rule with,
>> depending on how the IPs are distributed, either O(1) or O(n) lookup
>> time.
>>     
>
> That sounds just like what ipsets does today.

Yes, but not for arbitary data. Even verdicts (including jumps) and
argument selection for other modules like MARK, ...

>  Also, netlink, at least
> when using the TLV infrastructure it provides, does not come without
> a cost—namely encoding and decoding to/from nlmsg structures. I
> suggest to test-run the current binary protocol (a concatenation of
> struct ipt_entries etc.) over netlink first before changing it to
> something dynamic. Also, from what I have read from the iproute2
> source so far, each attribute has an index, and that's rather bad for
> add-on modules which want to define arbitrary attributes.
>   

Netlink message size is limited, but you can of course use
lists of attributes or structures.

>   
>>> Are the plans for that online somewhere? Is there
>>> a envisioned time line?
>>>       
>> The plans come mostly from multiple discussions on this list
>> and in private, as well as my dislikes of certains aspects
>> of iptables (like the insane amount of modules).
>>     
>
> If it's just the number of source files, then that is an easy
> target; these can be collapsed into one file. That would
> reduce both compile time and the runtime overhead.
>
> Concrete thoughts: combine
> - xt_{CLASSIFY,CONNMARK,CONNSECMARK,MARK,SECMARK,connmark,mark}
> - xt_{ah,esp,policy}
> - xt_{conntrack,state}, though I'd say let's obsolete xt_state
> - xt_{RATEEST,rateest}
> - xt_{connbytes,connlimit,length,limit,hashlimit,quota,statistic}
> - xt_{ECN,DSCP,HL,TTL,ecn,hl,dscp,ttl}
> - xt_{comment,string,time,u32}
> - xt_{addrtype,pkttype}
> - xt_{hbh,dst,frag,eui64,ipv6header}

Roughly, there will be:

- data module: any packet data: headers, payload
- meta module: meta-data associated with packet, maybe also conntrack things
  and others
- maybe conntrack module if not contained in meta module
- existing stateful modules like limit, hashlimit, ...

And whatever is still missing. The logic how to use them will
be completely in userspace. Meaning the data module doesn't
care at all what kind of data it looks at, the set lookup
doesn't care whether its a port number, an IP address or
an ifindex, ...

>   
>>> I'm asking because I'm thinking about whether or not
>>> it's feasible and/or sensibly to write some kind
>>> of target module that I'm choosing to call "jumpset" for now, that
>>> would act as a fast (>O(log(n)) "jump diststribution point".
>>>       
>> Thats one of the things I also want to add (halfway finished yet).
>> Jumps are regular verdicts in my new design and verdicts can be
>> gathered though lookups in sets, hashes etc. So you could do:
>>
>> unnamed ... -j { 192.168.0.1:chain_1, 192.168.0.2:chain_2, ...}
>>     
>
> This comes at the expense of ease-of-use. But you can persuade me to
> agree on something à la
> 	iptables -N 'chainx[0]'
> 	iptables -N 'chainx[1]'
> 	iptables -s 192.168.17.0/24 -j 'chainx[]'
>   

Thats not any simpler. Besides such optimization also may be
performed by the userspace tool, the user doesn't necessarily
has to do them himself. Though this is not planned for an
initial version.

>   
>> I also want to have the same working for mark etc:
>>
>> unnamed ... -j MARK --set-mark { 192.168.0.1:1, 192.168.0.2: 2, .. }
>>     
>
> See IPMARK.
>
>   
>> or alternatively:
>>
>> unnamed ... -j MARK --set-mark ip-dst & 0xFF
>>     
>
> See IPMARK!
>
> (Hint: http://dev.medozas.de/gitweb.cgi?p=xtables-addons )
> Hint2:
> 	... -j IPMARK --addr dst
> 	... -j MARK --and-mask 0xFF
>   

1. So?

2. You don't get it. Thats another special-casing module, exactly
the think I *don't* like. How many more of these (with slightly
differing semantic and features) should we add?


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html