Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark

On Wednesday 25 January 2012 12:49:32 Pablo Neira Ayuso wrote:

On Wed, Jan 25, 2012 at 11:14:33AM +0100, Hans Schillstrom wrote:

quoted

Here is help text and man page just to clarify the changes:
Is this clear enough ?

HMARK target options, i.e. modify hash calculation by:
  --hmark-method <method>            Overall L3/L4 and fragment behavior
                 L3                  Fragment safe, do not use ports or protocol
                                     i.e  Fragments don't need special care.

                 L3-4 (Default)      Fragment unsafe, use ports and protocol
                                     if defrag is off in conntrack
                                        no hmark produced on any part of fragments.

This is fine.

quoted

  Limit/modify the calculated hash mark by:
  --hmark-mod value                  nfmark modulus value
  --hmark-offs value                 Last action add value to nfmark

            ^^^^
no need to be cryptic here, just say offset.

OK

quoted

 Fine tuning of what will be included in hash calculation
  --hmark-smask length               Source address mask length

            ^^^^^

OK

I'd say hmark-src-mask to keep it consistent with the options in
iptables.

quoted

  --hmark-dmask length               Dest address mask length

hmark-dst-mask

OK

quoted

  --hmark-sp-mask value              Mask src port with value

hmark-sport-mask

OK

quoted

  --hmark-dp-mask value              Mask dst port with value

hmark-dport-mask

OK

quoted

  --hmark-spi-mask value             For esp and ah AND spi with value

hmark-ah-spi-mask

No, it is for esp as well so I think spi is enough

quoted

  --hmark-sp-set value               OR src port with value

hmark-sport-or

quoted

  --hmark-dp-set value               OR dst port with value

hmark-dport-or

quoted

  --hmark-spi-set value              For esp and ah OR spi with value

These three can be useful? Providing lots of options is fine, but they
may confuse users. What do we gain from this?

In other words, is it possible to deploy consistent hashing with some
sane configuration using these options?

Ex if you want stickiness between ports ex 80 and 443
iptables  -p tcp --dport 443 -j HMARK --sport-mask 0 --dport-set 80 ....
iptables  ...  -j HMARK --sport-mask 0 ....

Usefull or not that can be discussed.

From my point of view it's not a "MUST"

quoted

  --hmark-proto-mask value           Mask Protocol with value

                                       ^^^^^^^^^^^ ^^^ ^^^ ^^^^
useful?

Yes, stickiness between protocols (in most cases --sport-mask needs to be zero)
ex sip uses both TCP and UDP port 5060

quoted

  --hmark-rnd                        Initial Random value to hash cacl.
 For NAT in IPv4 the original address can be used in the return path.

We'll have IPv6 NAT soon. Please, make sure we can extend HMARK to
support IPv6 support.

Sure, allready tesed.

quoted

 Make sure to qualify the statement in a proper way when using nat flags

this description is fine. I'd propose to change the option names
below:

quoted

  --hmark-dnat                       Replace src addr with original dst addr
  --hmark-snat                       Replace dst addr with original src addr

better:

--hmark-ct-orig-src
--hmark-ct-orig-dst

I agree, thanks

quoted

 In many cases hmark can be omitted i.e. --smask can be used

Thanks again.

-- 
Regards
Hans Schillstrom [off-list ref]