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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120125114932.GB6842@1984>
Date:	Wed, 25 Jan 2012 12:49:32 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Hans Schillstrom <hans.schillstrom@...csson.com>
Cc:	Hans Schillstrom <hans@...illstrom.com>,
	"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>
Subject: Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH
 based fwmark

On Wed, Jan 25, 2012 at 11:14:33AM +0100, Hans Schillstrom wrote:
> 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.

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

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

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

>   --hmark-dmask length               Dest address mask length

hmark-dst-mask

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

hmark-sport-mask

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

hmark-dport-mask

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

hmark-ah-spi-mask

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

hmark-sport-or

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

hmark-dport-or

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

>   --hmark-proto-mask value           Mask Protocol with value
                                       ^^^^^^^^^^^ ^^^ ^^^ ^^^^
useful?

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

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

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

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

Thanks again.
--
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