netdev - RE: [v3 PATCH 0/2] NETFILTER new target module, HMARK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 20 Oct 2011 17:16:20 +0200
From:	Hans Schillström <hans.schillstrom@...csson.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>
CC:	"kaber@...sh.net" <kaber@...sh.net>,
	"jengelh@...ozas.de" <jengelh@...ozas.de>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"hans@...illstrom.com" <hans@...illstrom.com>
Subject: RE: [v3 PATCH 0/2] NETFILTER new target module, HMARK

Hello
>Hi Hans,
>
>On Thu, Oct 13, 2011 at 09:02:08PM +0200, Hans Schillstrom wrote:
>> The target allows you to create rules in the "raw" and "mangle" tables
>> which alter the netfilter mark (nfmark) field within a given range.
>> First a 32 bit hash value is generated then modulus by <limit> and
>> finally an offset is added before it's written to nfmark.
>> Prior to routing, the nfmark can influence the routing method (see
>> "Use netfilter MARK value as routing key") and can also be used by
>> other subsystems to change their behaviour.
[snip]
>> Example:
>>                                       App Server (Real Server)
>>
>>                                            +---------+
>>                                         -->| Service |
>>      Gateway A                             +---------+
>>                           /
>>             +----------+ /     +----+      +---------+
>> --- if -A---| selector |---->  |ipvs|  --->| Service |
>>             +----------+ \     +----+      +---------+
>>                           \
>>                                +----+      +---------+
>>                                |ipvs|   -->| Service |
>>                                +----+      +---------+
>>       Gateway C
>>             +----------+ /     +----+
>> --- if-B ---| selector | --->  |ipvs|
>>             +----------+ \     +----+      +---------+
>>                                            | Service |
>>                                            +---------+
>>                           /
>>             +----------+ /     +----+     ..
>> --- if-B ---| selector | --->  |ipvs|      +---------+
>>             +----------+ \     +----+      | Service |
>>                           \                +---------+
>> #
>> # Example with four ipvs loadbalancers
>> #
>> iptables -t mangle -I PREROUTING -d $IPADDR -j HMARK --hmark-mod 4 --hmark-offs 100
>
>I think you can replace this rule by:
>
>iptables -t mangle -I PREROUTING -d $IPADDR -m cluster \
>        --cluster-total-nodes 4 --cluster-local-node 1
>        --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 100
>iptables -t mangle -I PREROUTING -d $IPADDR -m cluster \
>        --cluster-total-nodes 4 --cluster-local-node 2
>        --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 101
>iptables -t mangle -I PREROUTING -d $IPADDR -m cluster \
>        --cluster-total-nodes 4 --cluster-local-node 3
>        --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 103
>iptables -t mangle -I PREROUTING -d $IPADDR -m cluster \
>        --cluster-total-nodes 4 --cluster-local-node 4
>        --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 104
>
>The hashing is done by the cluster match, which is currently based on
>the source address.
>
>This match currently depends on the connection tracking system, so you
>could save the ctmark with CONNMARK. Thus, you only has to hash the
>first packet of the flow, instead of hashing every single packet.
>

In our case we have 256 destinations and 1-20 different HMARK targets so, the no of iptables rules will be > 5000
(20 x 256 rules ...) with cluster target.

One other important difference is that HMARK can spread the packages based on a 5 tuple not only source
and of course skip any field.  That is usually important for load distribution.

I also dig into ICMP errors so the packet can be marked based on the original packet
i.e. routed to the right machine.

I some way the cluster target and hmark targets are similar, in other where different.
One of the main ideas with hmark is to place it in-front of a a clusters (and load balancers) where you have multiple 10G lines in.
(and in that case contrack is not our friend...) i.e. do partitioning of the load balancers.

Regards
Hans



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