Plans for future iptables versions / jumpset feature

Plans for future iptables versions / jumpset feature

[Thomas Jacob]

Hello list,

In a reply to a post last week about netfilter/iptables's performance
(see below for link), Patrick McHardy wrote about him working 
on a successor to iptables that would be able to manipulate
single rules in a set without any need to replace the whole
ruleset, and that would also include native support
for match sets and the like:

http://marc.info/?l=netfilter-devel&m=121085934512644

Are the plans for that online somewhere? Is there
a envisioned time line?

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".

The idea is to have a mapping between a a potentially large set of IP
addresses and the chain/target space, so one could have a different
"next chain" for each  different source/target IP or possibly
source/target network. The internal implementation of the necessary
data structures would be something along the lines of the ipset
extension. 

The application would be being able to provide customized
rule sets for lots of different machines at just a few central netfilter
boxen. Or perhaps to block traffic from different attack sources in
completely different ways in an IDS/IPS system.

In some cases one could of course achieve a similar functionality by
constructing rule trees with the existing standard distribution but that
could create a huge number of rules that simply link to the next chain
and in general looks rather messy.

But if iptables will be fundamentally different next year or if
it will already contain something similar, it would probably not be very
productive to work on such a module.

Also if this whole idea is stupid, a waste of time, has already been
done or whatever, I'd really like to know.

Any thoughts on this would be very welcome.

    Regards,
        Thomas

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

Thomas Jacob wrote:
> Hello list,
>
> In a reply to a post last week about netfilter/iptables's performance
> (see below for link), Patrick McHardy wrote about him working 
> on a successor to iptables that would be able to manipulate
> single rules in a set without any need to replace the whole
> ruleset, and that would also include native support
> for match sets and the like:
>
> http://marc.info/?l=netfilter-devel&m=121085934512644
>
> 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).

The time line is vague, I originally wanted to have something
to publish this month, but other things are keeping me busy.
So to be safe I'll not promise anything before the next netfilter
workshop.

I might publish an outline of the new design though if I'll
find some time.

> 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, ...}

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, .. }

or alternatively:

unnamed ... -j MARK --set-mark ip-dst & 0xFF

> The idea is to have a mapping between a a potentially large set of IP
> addresses and the chain/target space, so one could have a different
> "next chain" for each  different source/target IP or possibly
> source/target network. The internal implementation of the necessary
> data structures would be something along the lines of the ipset
> extension. 
>
> The application would be being able to provide customized
> rule sets for lots of different machines at just a few central netfilter
> boxen. Or perhaps to block traffic from different attack sources in
> completely different ways in an IDS/IPS system.
>
> In some cases one could of course achieve a similar functionality by
> constructing rule trees with the existing standard distribution but that
> could create a huge number of rules that simply link to the next chain
> and in general looks rather messy.
>   

Doing this in iptables might get a bit hairy, but it shouldn't be
that hard.

> But if iptables will be fundamentally different next year or if
> it will already contain something similar, it would probably not be very
> productive to work on such a module.

It would be great to have this in shape by next year, but I won't
promise anything. Should be doable though.

Re: Plans for future iptables versions / jumpset feature

[Jan Engelhardt]

On Thursday 2008-05-22 21:18, Patrick McHardy wrote:

> Thomas Jacob wrote:
>> Hello list,
>>
>> In a reply to a post last week about netfilter/iptables's performance
>> (see below for link), Patrick McHardy wrote about him working on a successor
>> to iptables that would be able to manipulate
>> single rules in a set without any need to replace the whole
>> ruleset, and that would also include native support
>> for match sets and the like:
>>
>> http://marc.info/?l=netfilter-devel&m=121085934512644

There have been a few changes regarding insertion speed. Even if one
has 500 rules (see that URL), they can probably be optimized using
IPMARK or chaintrees. Also, one should use iptables-restore for
updates, at least when changing more than one rule in a go. Lots of
people fail to actually use it.

Patrick McHardy wrote (see URL):
>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. 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.

>> 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}

>> 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[]'

> 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
--
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

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

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

Re: Plans for future iptables versions / jumpset feature

[Thomas Jacob]

> There have been a few changes regarding insertion speed. Even if one
> has 500 rules (see that URL), they can probably be optimized using
> IPMARK or chaintrees. 

I was thinking more along the lines of >100k rules. Iptables
can easily handles those numbers at the moment, it's just a bit
awkward to deal with.

By chaintrees I presume you mean trees of iptables chains and not
some sort of tool named this way?

> Also, one should use iptables-restore for
> updates, at least when changing more than one rule in a go. Lots of
> people fail to actually use it.

To be sure, but I am also interested in improving the time required
to find to correct chain given 1000s or 10000s of ip to chain mappings
and of course the usability of a construct like that.

Re: Plans for future iptables versions / jumpset feature

[Thomas Jacob]

> 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, ...}

Great news, that's more or less what I'm looking to do.

Would those plans also include some way to incrementally
manipulate these verdict sets, maybe like:

unnamed ... -j dstset:targets

settool --name targets --add 192.168.0.10:chain_10

?

> It would be great to have this in shape by next year, but I won't
> promise anything. Should be doable though.

Looking forward to be an avid beta tester then ;-)

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

Thomas Jacob wrote:
>> 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, ...}
>>     
>
> Great news, that's more or less what I'm looking to do.
>
> Would those plans also include some way to incrementally
> manipulate these verdict sets, maybe like:
>
> unnamed ... -j dstset:targets
>
> settool --name targets --add 192.168.0.10:chain_10
>
> ?

Not implemented yet, but I'm probably going to add this as an option
(since it may affect the choice of data structure). For jumps its
tricky though because loop detection has to be performed.

>   
>> It would be great to have this in shape by next year, but I won't
>> promise anything. Should be doable though.
>>     
>
> Looking forward to be an avid beta tester then ;-)
>   

Great :)

Re: Plans for future iptables versions / jumpset feature

[Thomas Jacob]

On Thu, May 22, 2008 at 10:18:25PM +0200, Patrick McHardy wrote:
> Not implemented yet, but I'm probably going to add this as an option
> (since it may affect the choice of data structure). For jumps its
> tricky though because loop detection has to be performed.

I don't see why this always has to be performed. There so many ways
to break your system when you're root, so being required to define a loop
free rule sets after specifying some kind of "yes I really want to"-
option should be that much of a burden. As far as I understand
the code, the loop checking at the moment is done in userspace, so
nobody stops you from simply removing that part from the iptables
code.

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

Thomas Jacob wrote:
> On Thu, May 22, 2008 at 10:18:25PM +0200, Patrick McHardy wrote:
>   
>> Not implemented yet, but I'm probably going to add this as an option
>> (since it may affect the choice of data structure). For jumps its
>> tricky though because loop detection has to be performed.
>>     
>
> I don't see why this always has to be performed. There so many ways
> to break your system when you're root, so being required to define a loop
> free rule sets after specifying some kind of "yes I really want to"-
> option should be that much of a burden. As far as I understand
> the code, the loop checking at the moment is done in userspace, so
> nobody stops you from simply removing that part from the iptables
> code.
>   

No, its done in the kernel. I also don't buy this argument.
Sure, you can wreck your system if you really want to, but
it should be prevented to do so accidentally. Additionally,
if you consider setups with limited root powers, this becomes
a serious bug.

Re: Plans for future iptables versions / jumpset feature

[Thomas Jacob]

On Thu, May 22, 2008 at 10:51:59PM +0200, Patrick McHardy wrote:
> No, its done in the kernel. I also don't buy this argument.

Oh yes, mark_source_chains, sorry

> Sure, you can wreck your system if you really want to, but
> it should be prevented to do so accidentally. Additionally,
> if you consider setups with limited root powers, this becomes
> a serious bug.

Well if you can't wreck your system this way now, creating such
a possibility wouldn't be so good... agreed.

RE: Plans for future iptables versions / jumpset feature

[Nishit Shah]

Hi,
	I am also looking/working for same thing as something like
"jumpset", even discussed with Patrick in last workshop regarding how to do
it, but it looks difficult to me by just seeing at code or understanding the
code without the overall impact.
	It would be nice if someone can share the idea of how to do it or
give a lead for how to proceed.

Rgds,
Nishit Shah  

-----Original Message-----
From: netfilter-devel-owner@vger.kernel.org
[mailto:netfilter-devel-owner@vger.kernel.org] On Behalf Of Patrick McHardy
Sent: Friday, May 23, 2008 12:48 AM
To: Thomas Jacob
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Plans for future iptables versions / jumpset feature

Thomas Jacob wrote:
> Hello list,
>
> In a reply to a post last week about netfilter/iptables's performance
> (see below for link), Patrick McHardy wrote about him working 
> on a successor to iptables that would be able to manipulate
> single rules in a set without any need to replace the whole
> ruleset, and that would also include native support
> for match sets and the like:
>
> http://marc.info/?l=netfilter-devel&m=121085934512644
>
> 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).

The time line is vague, I originally wanted to have something
to publish this month, but other things are keeping me busy.
So to be safe I'll not promise anything before the next netfilter
workshop.

I might publish an outline of the new design though if I'll
find some time.

> 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, ...}

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, .. }

or alternatively:

unnamed ... -j MARK --set-mark ip-dst & 0xFF

> The idea is to have a mapping between a a potentially large set of IP
> addresses and the chain/target space, so one could have a different
> "next chain" for each  different source/target IP or possibly
> source/target network. The internal implementation of the necessary
> data structures would be something along the lines of the ipset
> extension. 
>
> The application would be being able to provide customized
> rule sets for lots of different machines at just a few central netfilter
> boxen. Or perhaps to block traffic from different attack sources in
> completely different ways in an IDS/IPS system.
>
> In some cases one could of course achieve a similar functionality by
> constructing rule trees with the existing standard distribution but that
> could create a huge number of rules that simply link to the next chain
> and in general looks rather messy.
>   

Doing this in iptables might get a bit hairy, but it shouldn't be
that hard.

> But if iptables will be fundamentally different next year or if
> it will already contain something similar, it would probably not be very
> productive to work on such a module.

It would be great to have this in shape by next year, but I won't
promise anything. Should be doable though.

--
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

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

Nishit Shah wrote:
> Hi,
> 	I am also looking/working for same thing as something like
> "jumpset", even discussed with Patrick in last workshop regarding how to do
> it, but it looks difficult to me by just seeing at code or understanding the
> code without the overall impact.
> 	It would be nice if someone can share the idea of how to do it or
> give a lead for how to proceed.

Basically, you'd change (in ipt_do_table):

                                 int newpos = t->verdict; 


to get the new position from the target module. This probably
requires to change the target function signature. Alternatively
you could try to encode it in the verdict. Loop detection
needs some way to get all possible jumps from the target
and check each possible path. Maybe the easiest way is probably
a target built into ip_tables.c

Re: Plans for future iptables versions / jumpset feature

[Thomas Jacob]

On Fri, 2008-05-23 at 14:15 +0200, Patrick McHardy wrote:
> Basically, you'd change (in ipt_do_table):
> 
>                                  int newpos = t->verdict; 
> 
> 
> to get the new position from the target module. This probably
> requires to change the target function signature. Alternatively
> you could try to encode it in the verdict. Loop detection
> needs some way to get all possible jumps from the target
> and check each possible path. Maybe the easiest way is probably
> a target built into ip_tables.c

Out of curiosity, if Nishit would actually do it (@Nishit: if you do,
maybe we could work together on this?) but there are really major
changes afoot for netfilter during the course of this year, wouldn't
those changes make such an extension obsolete and/or pretty
difficult to port to the new netfilter?

Re: Plans for future iptables versions / jumpset feature

[Patrick McHardy]

Thomas Jacob wrote:
> On Fri, 2008-05-23 at 14:15 +0200, Patrick McHardy wrote:
>> Basically, you'd change (in ipt_do_table):
>>
>>                                  int newpos = t->verdict; 
>>
>>
>> to get the new position from the target module. This probably
>> requires to change the target function signature. Alternatively
>> you could try to encode it in the verdict. Loop detection
>> needs some way to get all possible jumps from the target
>> and check each possible path. Maybe the easiest way is probably
>> a target built into ip_tables.c
> 
> Out of curiosity, if Nishit would actually do it (@Nishit: if you do,
> maybe we could work together on this?) but there are really major
> changes afoot for netfilter during the course of this year, wouldn't
> those changes make such an extension obsolete and/or pretty
> difficult to port to the new netfilter?

If its sanely designed, there shouldn't be much trouble porting
it, especially since this feature will be implemented anyways.