All of lore.kernel.org
 help / color / mirror / Atom feed
* [v7 PATCH 0/3] NETFILTER new target module, HMARK
@ 2012-01-13  9:52 Hans Schillstrom
  2012-01-13  9:52 ` [PATCH 1/3] NETFILTER added flags to ipv6_find_hdr() Hans Schillstrom
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-13  9:52 UTC (permalink / raw)
  To: kaber, pablo, jengelh, netfilter-devel, netdev; +Cc: hans, Hans Schillstrom

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

The mark match can also be used to match nfmark produced by this module.
See the kernel module for more info.

REVISION
Version 7
	ahuum, IPv6 descending into icmp error hdr didn't work as expected
        with ipv6_find_hdr() Now it works as expected.

Version 6
        Removed ipv6_find_hdr() wrapper (Pablo)
	NAT / Conntrack compilation switches.

Version 5
	Use length of mask an smask and dmask and whole IPv6 addr (Jan E)
	Modify ipv6_find_hdr() and use it while traversing the IPv6 header.
        Manual changes.
	More or less all comments implemented.

Version 4
	Split of IPv6 and IPv4, use IP_CT_IS_REPLY, as Pablo suggested.
	removed one pskb_may_pull()
	xtoption parse used in the user space part.

Version 3
        Handling of SCTP for IPv6 added.

Version 2
	NAT Added for IPv4
	IPv6 ICMP handling enhanced.
	Usage example added

Version 1
	Initial RFC


We (Ericsson) use hmark in-front of ipvs as a pre-loadbalancer and
handles up to 70 ipvs running in parallel in clusters.
However hmark is not restricted to run in front of IPVS it can also be used as
"poor mans" load balancer.
With this version is also NAT supported as an option, with very high flows
you might not want to use conntrack.

The idea is to generate a direction independent fw mark range to use as input to
the routing (i.e. ip rule add fwmark ...).
Pretty straight forward and simple.


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

ip rule add fwmark 100 table 100
ip rule add fwmark 101 table 101
ip rule add fwmark 102 table 102
ip rule add fwmark 103 table 103

ip ro ad table 100 default via x.y.z.1 dev bond1
ip ro ad table 101 default via x.y.z.2 dev bond1
ip ro ad table 102 default via x.y.z.3 dev bond1
ip ro ad table 103 default via x.y.z.4 dev bond1


If conntrack doesn't handle the return path,
do the oposite with HMARK and send it back right to ipvs.

Another exmaple of usage could be if you have cluster originated connections
and want to spread the connections over a number of interfaces
(NAT will complpicate things for you in this case)



                     \  Blade 1
                      \ +----------+      +---------+
                    <-- | selector | <--- | Service |
                      / +----------+      +---------+
                     /
   +------+
-- | Gw-A |          \  Blade 2
   +------+           \ +----------+      +---------+
   +------+         <-- | selector | <--- | Service |
-- | Gw-B |           / +----------+      +---------+
   +------+          /
   +------+
-- | Gw-C |          \
   +------+           \ +----------+      +---------+
                    <-- | selector | <--- | Service |
                      / +----------+      +---------+
                     /

                     \  Blande -n
                      \ +----------+      +---------+
                    <-- | selector | <--- | Service |
                      / +----------+      +---------+
                     /


Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 1/3] NETFILTER added flags to ipv6_find_hdr()
  2012-01-13  9:52 [v7 PATCH 0/3] NETFILTER new target module, HMARK Hans Schillstrom
@ 2012-01-13  9:52 ` Hans Schillstrom
  2012-01-13  9:52 ` [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark Hans Schillstrom
  2012-01-13  9:52 ` [v7 PATCH 3/3] NETFILTER userspace part for target HMARK Hans Schillstrom
  2 siblings, 0 replies; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-13  9:52 UTC (permalink / raw)
  To: kaber, pablo, jengelh, netfilter-devel, netdev; +Cc: hans, Hans Schillstrom

Two new flags to ipv6_find_hdr,
One that tells us that this is a fragment.
One that stops at AH if any i.e. treat it like a transport header.
i.e. make handling of ESP and AH the same.
Param offset can now point to an inner icmp ipv5 header.

Version 3:
    offset param into ipv6_find_hdr set to zero.

Version 2:
    wrapper removed and changes made at every call.

Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
---
 include/linux/netfilter_ipv6/ip6_tables.h |    8 +++++-
 net/ipv6/netfilter/ip6_tables.c           |   35 ++++++++++++++++++++++++----
 net/ipv6/netfilter/ip6t_ah.c              |    4 +-
 net/ipv6/netfilter/ip6t_frag.c            |    4 +-
 net/ipv6/netfilter/ip6t_hbh.c             |    4 +-
 net/ipv6/netfilter/ip6t_rt.c              |    4 +-
 net/netfilter/xt_TPROXY.c                 |    4 +-
 net/netfilter/xt_socket.c                 |    4 +-
 8 files changed, 49 insertions(+), 18 deletions(-)

diff --git a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h
index f549adc..e1ad013 100644
--- a/include/linux/netfilter_ipv6/ip6_tables.h
+++ b/include/linux/netfilter_ipv6/ip6_tables.h
@@ -288,9 +288,15 @@ extern unsigned int ip6t_do_table(struct sk_buff *skb,
 
 /* Check for an extension */
 extern int ip6t_ext_hdr(u8 nexthdr);
+enum {
+	IP6T_FH_FRAG,
+	IP6T_FH_AUTH,
+	IP6T_FH_F_FRAG = 1 << IP6T_FH_FRAG,
+	IP6T_FH_F_AUTH = 1 << IP6T_FH_AUTH,
+};
 /* find specified header and get offset to it */
 extern int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
-			 int target, unsigned short *fragoff);
+			 int target, unsigned short *fragoff, int *fragflg);
 
 #ifdef CONFIG_COMPAT
 #include <net/compat.h>
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 94874b0..9dab6a8 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -146,7 +146,7 @@ ip6_packet_match(const struct sk_buff *skb,
 		int protohdr;
 		unsigned short _frag_off;
 
-		protohdr = ipv6_find_hdr(skb, protoff, -1, &_frag_off);
+		protohdr = ipv6_find_hdr(skb, protoff, -1, &_frag_off, NULL);
 		if (protohdr < 0) {
 			if (_frag_off == 0)
 				*hotdrop = true;
@@ -375,6 +375,7 @@ ip6t_do_table(struct sk_buff *skb,
 		const struct xt_entry_match *ematch;
 
 		IP_NF_ASSERT(e);
+		acpar.thoff = 0;
 		if (!ip6_packet_match(skb, indev, outdev, &e->ipv6,
 		    &acpar.thoff, &acpar.fragoff, &acpar.hotdrop)) {
  no_match:
@@ -2290,6 +2291,8 @@ static void __exit ip6_tables_fini(void)
  * find the offset to specified header or the protocol number of last header
  * if target < 0. "last header" is transport protocol header, ESP, or
  * "No next header".
+ * Note, *offset is used as input param. an if != 0
+ * it must be an offset to an inner ipv6 header ex. icmp error
  *
  * If target header is found, its offset is set in *offset and return protocol
  * number. Otherwise, return -1.
@@ -2302,17 +2305,34 @@ static void __exit ip6_tables_fini(void)
  * *offset is meaningless and fragment offset is stored in *fragoff if fragoff
  * isn't NULL.
  *
+ * if flags != NULL AND
+ *    it's a fragment the frag flag "IP6T_FH_F_FRAG" will be set
+ *    it's an AH header and IP6T_FH_F_AUTH is set and target < 0
+ *      stop at AH (i.e. treat is as a transport header)
  */
 int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
-		  int target, unsigned short *fragoff)
+		  int target, unsigned short *fragoff, int *flags)
 {
 	unsigned int start = skb_network_offset(skb) + sizeof(struct ipv6hdr);
 	u8 nexthdr = ipv6_hdr(skb)->nexthdr;
-	unsigned int len = skb->len - start;
+	unsigned int len;
 
 	if (fragoff)
 		*fragoff = 0;
 
+	if (*offset) {
+		struct ipv6hdr _ip6, *ip6;
+
+		ip6 = skb_header_pointer(skb, *offset, sizeof(_ip6), &_ip6);
+		if (!ip6 || (ip6->version != 6)) {
+			printk(KERN_ERR "IPv6 header not found\n");
+			return -EBADMSG;
+		}
+		start = *offset + sizeof(struct ipv6hdr);
+		nexthdr = ip6->nexthdr;
+	}
+	len = skb->len - start;
+
 	while (nexthdr != target) {
 		struct ipv6_opt_hdr _hdr, *hp;
 		unsigned int hdrlen;
@@ -2329,6 +2349,9 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 		if (nexthdr == NEXTHDR_FRAGMENT) {
 			unsigned short _frag_off;
 			__be16 *fp;
+
+			if (flags)	/* Indicate that this is a fragment */
+				*flags |= IP6T_FH_F_FRAG;
 			fp = skb_header_pointer(skb,
 						start+offsetof(struct frag_hdr,
 							       frag_off),
@@ -2349,9 +2372,11 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 				return -ENOENT;
 			}
 			hdrlen = 8;
-		} else if (nexthdr == NEXTHDR_AUTH)
+		} else if (nexthdr == NEXTHDR_AUTH) {
+			if (flags && (*flags & IP6T_FH_F_AUTH) && (target < 0))
+				break;
 			hdrlen = (hp->hdrlen + 2) << 2;
-		else
+		} else
 			hdrlen = ipv6_optlen(hp);
 
 		nexthdr = hp->nexthdr;
diff --git a/net/ipv6/netfilter/ip6t_ah.c b/net/ipv6/netfilter/ip6t_ah.c
index 89cccc5..04099ab 100644
--- a/net/ipv6/netfilter/ip6t_ah.c
+++ b/net/ipv6/netfilter/ip6t_ah.c
@@ -41,11 +41,11 @@ static bool ah_mt6(const struct sk_buff *skb, struct xt_action_param *par)
 	struct ip_auth_hdr _ah;
 	const struct ip_auth_hdr *ah;
 	const struct ip6t_ah *ahinfo = par->matchinfo;
-	unsigned int ptr;
+	unsigned int ptr = 0;
 	unsigned int hdrlen = 0;
 	int err;
 
-	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_AUTH, NULL);
+	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_AUTH, NULL, NULL);
 	if (err < 0) {
 		if (err != -ENOENT)
 			par->hotdrop = true;
diff --git a/net/ipv6/netfilter/ip6t_frag.c b/net/ipv6/netfilter/ip6t_frag.c
index eda898f..3b5735e 100644
--- a/net/ipv6/netfilter/ip6t_frag.c
+++ b/net/ipv6/netfilter/ip6t_frag.c
@@ -40,10 +40,10 @@ frag_mt6(const struct sk_buff *skb, struct xt_action_param *par)
 	struct frag_hdr _frag;
 	const struct frag_hdr *fh;
 	const struct ip6t_frag *fraginfo = par->matchinfo;
-	unsigned int ptr;
+	unsigned int ptr = 0;
 	int err;
 
-	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_FRAGMENT, NULL);
+	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_FRAGMENT, NULL, NULL);
 	if (err < 0) {
 		if (err != -ENOENT)
 			par->hotdrop = true;
diff --git a/net/ipv6/netfilter/ip6t_hbh.c b/net/ipv6/netfilter/ip6t_hbh.c
index 59df051..01df142 100644
--- a/net/ipv6/netfilter/ip6t_hbh.c
+++ b/net/ipv6/netfilter/ip6t_hbh.c
@@ -50,7 +50,7 @@ hbh_mt6(const struct sk_buff *skb, struct xt_action_param *par)
 	const struct ipv6_opt_hdr *oh;
 	const struct ip6t_opts *optinfo = par->matchinfo;
 	unsigned int temp;
-	unsigned int ptr;
+	unsigned int ptr = 0;
 	unsigned int hdrlen = 0;
 	bool ret = false;
 	u8 _opttype;
@@ -62,7 +62,7 @@ hbh_mt6(const struct sk_buff *skb, struct xt_action_param *par)
 
 	err = ipv6_find_hdr(skb, &ptr,
 			    (par->match == &hbh_mt6_reg[0]) ?
-			    NEXTHDR_HOP : NEXTHDR_DEST, NULL);
+			    NEXTHDR_HOP : NEXTHDR_DEST, NULL, NULL);
 	if (err < 0) {
 		if (err != -ENOENT)
 			par->hotdrop = true;
diff --git a/net/ipv6/netfilter/ip6t_rt.c b/net/ipv6/netfilter/ip6t_rt.c
index d8488c5..2c99b94 100644
--- a/net/ipv6/netfilter/ip6t_rt.c
+++ b/net/ipv6/netfilter/ip6t_rt.c
@@ -42,14 +42,14 @@ static bool rt_mt6(const struct sk_buff *skb, struct xt_action_param *par)
 	const struct ipv6_rt_hdr *rh;
 	const struct ip6t_rt *rtinfo = par->matchinfo;
 	unsigned int temp;
-	unsigned int ptr;
+	unsigned int ptr = 0;
 	unsigned int hdrlen = 0;
 	bool ret = false;
 	struct in6_addr _addr;
 	const struct in6_addr *ap;
 	int err;
 
-	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_ROUTING, NULL);
+	err = ipv6_find_hdr(skb, &ptr, NEXTHDR_ROUTING, NULL, NULL);
 	if (err < 0) {
 		if (err != -ENOENT)
 			par->hotdrop = true;
diff --git a/net/netfilter/xt_TPROXY.c b/net/netfilter/xt_TPROXY.c
index 35a959a..146033a 100644
--- a/net/netfilter/xt_TPROXY.c
+++ b/net/netfilter/xt_TPROXY.c
@@ -282,10 +282,10 @@ tproxy_tg6_v1(struct sk_buff *skb, const struct xt_action_param *par)
 	struct sock *sk;
 	const struct in6_addr *laddr;
 	__be16 lport;
-	int thoff;
+	int thoff = 0;
 	int tproto;
 
-	tproto = ipv6_find_hdr(skb, &thoff, -1, NULL);
+	tproto = ipv6_find_hdr(skb, &thoff, -1, NULL, NULL);
 	if (tproto < 0) {
 		pr_debug("unable to find transport header in IPv6 packet, dropping\n");
 		return NF_DROP;
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 72bb07f..9ea482d 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -263,10 +263,10 @@ socket_mt6_v1(const struct sk_buff *skb, struct xt_action_param *par)
 	struct sock *sk;
 	struct in6_addr *daddr, *saddr;
 	__be16 dport, sport;
-	int thoff, tproto;
+	int thoff = 0, tproto;
 	const struct xt_socket_mtinfo1 *info = (struct xt_socket_mtinfo1 *) par->matchinfo;
 
-	tproto = ipv6_find_hdr(skb, &thoff, -1, NULL);
+	tproto = ipv6_find_hdr(skb, &thoff, -1, NULL, NULL);
 	if (tproto < 0) {
 		pr_debug("unable to find transport header in IPv6 packet, dropping\n");
 		return NF_DROP;
-- 
1.7.2.3

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-13  9:52 [v7 PATCH 0/3] NETFILTER new target module, HMARK Hans Schillstrom
  2012-01-13  9:52 ` [PATCH 1/3] NETFILTER added flags to ipv6_find_hdr() Hans Schillstrom
@ 2012-01-13  9:52 ` Hans Schillstrom
  2012-01-22 21:44   ` Pablo Neira Ayuso
  2012-01-13  9:52 ` [v7 PATCH 3/3] NETFILTER userspace part for target HMARK Hans Schillstrom
  2 siblings, 1 reply; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-13  9:52 UTC (permalink / raw)
  To: kaber, pablo, jengelh, netfilter-devel, netdev; +Cc: hans, Hans Schillstrom

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

man page
   HMARK
       This  module  does  the same as MARK, i.e. set an fwmark,
       but the mark is based on a hash value.  The hash is based on
       saddr, daddr, sport, dport and proto. The same mark will be produced
       independet of direction if no masks is set or the same masks is used for
       src and dest. The hash mark could be adjusted by modulus and finaly an
       offset could be added, i.e the final mark will be within a range.
       ICMP errors will have hash calc based on the original message.
       Note:
        - None of the parameters effect the packet it self
          only the calculated hash value.
       Fragmentation:
        - If a packet is fragmented NONE of the Fragments will include
          ports in the hash calculation.
          When fragments arrives on different machines HMARK will produce
          same fwmark for all frags inpendent of machine so they can be routed
          to the same destination.
        - If nf_defrag_ipv{4,6} is loaded the packets will be defragmented
          before reaching HMARK, i.e. in that case ports (if any) will be used.
          (ICMP Time exceeded will be sent if fragments are lost)

       Parameters: For all masks default is all "1:s", to disable a field
                   use mask 0. For IPv6 it's just the last 32 bits that
                   is included in the hash.

       --hmark-smask length (0-32 or 0-128)
              The value to AND the source address with (saddr & value).

       --hmark-dmask length (0-32 or 0-128)
              The value to AND the dest. address with (daddr & value).

       --hmark-sp-mask value
              A 16 bit value to AND the src port with (sport & value).

       --hmark-dp-mask value
              A 16 bit value to AND the dest port with (dport & value).

       --hmark-sp-set value
              A 16 bit value to OR the src port with (sport | value).

       --hmark-dp-set value
              A 16 bit value to OR the dest port with (dport | value).

       --hmark-spi-mask value
              Value to AND the spi field with (spi & value) valid for proto esp or ah.

       --hmark-spi-set value
              Value to OR the spi field with (spi | value) valid for proto esp or ah.

       --hmark-proto-mask value
              A 16 bit value to AND the L4 proto field with (proto & value).

       --hmark-rnd value
              A 32 bit intitial value for hash calc, default is 0xc175a3b8.

       --hmark-dnat (only IPv4)
              Replace src addr/port with original dst addr/port before calc, hash

       --hmark-snat (only IPv4)
              Replace dst addr/port with original src addr/port before calc, hash

       Final processing of the mark in order of execution.

       --hmark-mod value (must be > 0)
              The easiest way to describe this is:  hash = hash mod <value>

       --hmark-offs alue (must be > 0)
              The easiest way to describe this is:  hash = hash + <value>

       Examples:

       Default rule handles all TCP, UDP, SCTP, ESP & AH

Rev 7
      IPv6 descending into icmp error hdr didn't work as expected
      with ipv6_find_hdr() Now it works as expected.

Rev 6
      Compile options with or without conntrack fixed.
      __ipv6_find_hdr() replaced by ipv6_find_hdr()

Rev 5
      IPv6 rewritten uses __ipv6_find_hdr() (P. Mc Hardy)
      Full mask and address used for IPv6 smask and dmask (J.Engelhart)
      Changes due to comments by Pablo Neira Ayuso  and Eric Dumazet
      i.e uses of skb_header_pointer() and Null check of info->hmod
      Man page changes

Rev 4
      different targets for IPv4 and IPv6
      Changes based on review by Pablo.

Rev 3
      Support added to SCTP for IPv6
Rev 2
      IPv6 header scan changed to follow RFC 2640
      IPv4 icmp echo fragmented does now use proto as ipv6
      IPv6 pskb_may_pull() check is done in every time in header loop.
      IPv4 nat support added.
      default added in IPv6 loop and null check of hp

Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
---
 include/linux/netfilter/xt_hmark.h |   62 +++++++
 net/netfilter/Kconfig              |   17 ++
 net/netfilter/Makefile             |    1 +
 net/netfilter/xt_hmark.c           |  337 ++++++++++++++++++++++++++++++++++++
 4 files changed, 417 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/netfilter/xt_hmark.h
 create mode 100644 net/netfilter/xt_hmark.c

diff --git a/include/linux/netfilter/xt_hmark.h b/include/linux/netfilter/xt_hmark.h
new file mode 100644
index 0000000..366ecce
--- /dev/null
+++ b/include/linux/netfilter/xt_hmark.h
@@ -0,0 +1,62 @@
+#ifndef XT_HMARK_H_
+#define XT_HMARK_H_
+
+#include <linux/types.h>
+
+/*
+ * Flags must not start at 0, since it's used as none.
+ */
+enum {
+	XT_HMARK_SADR_AND = 1,	/* SNAT & DNAT are used by the kernel module */
+	XT_HMARK_DADR_AND,
+	XT_HMARK_SPI_AND,
+	XT_HMARK_SPI_OR,
+	XT_HMARK_SPORT_AND,
+	XT_HMARK_DPORT_AND,
+	XT_HMARK_SPORT_OR,
+	XT_HMARK_DPORT_OR,
+	XT_HMARK_PROTO_AND,
+	XT_HMARK_RND,
+	XT_HMARK_MODULUS,
+	XT_HMARK_OFFSET,
+	XT_HMARK_USE_SNAT,
+	XT_HMARK_USE_DNAT,
+	XT_F_HMARK_USE_SNAT = 1 << XT_HMARK_USE_SNAT,
+	XT_F_HMARK_USE_DNAT = 1 << XT_HMARK_USE_DNAT,
+	XT_F_HMARK_SADR_AND = 1 << XT_HMARK_SADR_AND,
+	XT_F_HMARK_DADR_AND = 1 << XT_HMARK_DADR_AND,
+	XT_F_HMARK_SPI_AND = 1 << XT_HMARK_SPI_AND,
+	XT_F_HMARK_SPI_OR = 1 << XT_HMARK_SPI_OR,
+	XT_F_HMARK_SPORT_AND = 1 << XT_HMARK_SPORT_AND,
+	XT_F_HMARK_DPORT_AND = 1 << XT_HMARK_DPORT_AND,
+	XT_F_HMARK_SPORT_OR = 1 << XT_HMARK_SPORT_OR,
+	XT_F_HMARK_DPORT_OR = 1 << XT_HMARK_DPORT_OR,
+	XT_F_HMARK_PROTO_AND = 1 << XT_HMARK_PROTO_AND,
+	XT_F_HMARK_RND = 1 << XT_HMARK_RND,
+	XT_F_HMARK_MODULUS = 1 << XT_HMARK_MODULUS,
+	XT_F_HMARK_OFFSET = 1 << XT_HMARK_OFFSET,
+};
+
+union hports {
+	struct {
+		__u16	src;
+		__u16	dst;
+	} p16;
+	__u32	v32;
+};
+
+struct xt_hmark_info {
+	union nf_inet_addr	smask;		/* Source address mask */
+	union nf_inet_addr	dmask;		/* Dest address mask */
+	union hports		pmask;
+	union hports		pset;
+	__u32			spimask;
+	__u32			spiset;
+	__u16			flags;		/* Print out only */
+	__u16			prmask;		/* L4 Proto mask */
+	__u32			hashrnd;
+	__u32			hmod;		/* Modulus */
+	__u32			hoffs;		/* Offset */
+};
+
+#endif /* XT_HMARK_H_ */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index f8ac4ef..dfe84e1 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -488,6 +488,23 @@ config NETFILTER_XT_TARGET_HL
 	since you can easily create immortal packets that loop
 	forever on the network.
 
+config NETFILTER_XT_TARGET_HMARK
+	tristate '"HMARK" target support'
+	depends on NETFILTER_ADVANCED
+	---help---
+	This option adds the "HMARK" target.
+
+	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 behavior.
+
+	The mark match can also be used to match nfmark produced by this module.
+
 config NETFILTER_XT_TARGET_IDLETIMER
 	tristate  "IDLETIMER target support"
 	depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 40f4c3d..21bc5e8 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_CT) += xt_CT.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_DSCP) += xt_DSCP.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_HL) += xt_HL.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_HMARK) += xt_hmark.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_LED) += xt_LED.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_NFLOG) += xt_NFLOG.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
diff --git a/net/netfilter/xt_hmark.c b/net/netfilter/xt_hmark.c
new file mode 100644
index 0000000..fd73d15
--- /dev/null
+++ b/net/netfilter/xt_hmark.c
@@ -0,0 +1,337 @@
+/*
+ * xt_hmark - Netfilter module to set mark as hash value
+ *
+ * (C) 2011 Hans Schillstrom <hans.schillstrom@ericsson.com>
+ *
+ *Description:
+ *	This module calculates a hash value that can be modified by modulus
+ *	and an offset, i.e. it is possible to produce a skb->mark within a range.
+ *	The hash value is based on a direction independent five tuple:
+ *	src & dst addr src & dst ports and protocol.
+ *	However src & dst port can be masked and are not used for fragmented
+ *	packets, ESP and AH don't have ports so SPI will be used instead.
+ *	AH will not use ports even if it might be possible.
+ *	Tunnels - only the outer saddr and daddr will beused,
+ *
+ *	For ICMP error messages the hash mark values will be calculated on
+ *	the source packet i.e. the packet caused the error (If sufficient
+ *	amount of data exists).
+ *
+ *Note:	None of the fragments will include ports/spi in the calculation of
+ *	the hash value. (i.e. all frags must the same hash value.)
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *	it under the terms of the GNU General Public License version 2 as
+ *	published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <net/ip.h>
+#include <linux/icmp.h>
+
+#include <linux/netfilter/xt_hmark.h>
+#include <linux/netfilter/x_tables.h>
+#if defined(CONFIG_NF_NAT)
+#include <net/netfilter/nf_nat.h>
+#endif
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#	define WITH_IPV6 1
+#include <net/ipv6.h>
+#include <linux/netfilter_ipv6/ip6_tables.h>
+#endif
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Hans Schillstrom <hans.schillstrom@ericsson.com>");
+MODULE_DESCRIPTION("Xtables: packet range mark operations by hash value");
+MODULE_ALIAS("ipt_HMARK");
+MODULE_ALIAS("ip6t_HMARK");
+
+/*
+ * ICMP, get inner header so calc can be made on the source message
+ *
+ * iphsz: ip header size in bytes
+ * nhoff: network header offset
+ * return; updated nhoff if an icmp error
+ */
+static int get_inner_hdr(struct sk_buff *skb, int iphsz, int nhoff)
+{
+	const struct icmphdr *icmph;
+	struct icmphdr _ih;
+
+	/* Not enough header? */
+	icmph = skb_header_pointer(skb, nhoff + iphsz, sizeof(_ih), &_ih);
+	if (icmph == NULL)
+		return nhoff;
+
+	if (icmph->type > NR_ICMP_TYPES)
+		return nhoff;
+
+	/* Error message? */
+	if (icmph->type != ICMP_DEST_UNREACH &&
+	    icmph->type != ICMP_SOURCE_QUENCH &&
+	    icmph->type != ICMP_TIME_EXCEEDED &&
+	    icmph->type != ICMP_PARAMETERPROB &&
+	    icmph->type != ICMP_REDIRECT)
+		return nhoff;
+
+	return nhoff + iphsz + sizeof(_ih);
+}
+
+#ifdef WITH_IPV6
+/* Dummy header used for size calculation of an error header */
+struct _icmpv6_errh {
+	__u8		icmp6_type;
+	__u8		icmp6_code;
+	__u16		icmp6_cksum;
+	__u32		icmp6_nu;
+};
+/*
+ * Get ipv6 header offset if icmp type < 128 i.e. an error.
+ * @param: offset  input: where ICMPv6 header starts
+ *                output: where ipv6 header starts / unchanged.
+ *
+ * Returns true if it's an icmp error
+ *              and updates *offset to where ipv6 header starts
+ */
+static int get_inner6_hdr(struct sk_buff *skb, int *offset)
+{
+	struct icmp6hdr *icmp6h, _ih6;
+
+	icmp6h = skb_header_pointer(skb, *offset, sizeof(_ih6), &_ih6);
+	if (icmp6h == NULL)
+		return 0;
+
+	if (icmp6h->icmp6_type && icmp6h->icmp6_type < 128) {
+		*offset +=  sizeof(struct _icmpv6_errh);
+		return 1;
+	}
+	return 0;
+}
+/*
+ * Calculate hash based fw-mark, on the five tuple if possible.
+ * special cases :
+ *  - Fragments do not use ports not even on the first fragment,
+ *    nf_defrag_ipv6.ko don't defrag for us like it do in ipv4.
+ *    This might be changed in the future.
+ *  - On ICMP errors the inner header will be used.
+ *  - Tunnels no ports
+ *  - ESP & AH uses SPI
+ * @returns XT_CONTINUE
+ */
+__u32 hmark_v6(struct sk_buff *skb, const struct xt_action_param *par)
+{
+	struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
+	struct ipv6hdr *ip6, _ip6;
+	int poff, flag = IP6T_FH_F_AUTH; /* Ports offset, find_hdr flags */
+	u32 addr1, addr2, hash, nhoffs=0;
+	u8 nexthdr;
+	union hports uports = { .v32 = 0 };
+	unsigned short fragoff = 0;
+
+	if (!info->hmod)
+		return XT_CONTINUE;
+
+	ip6 = (struct ipv6hdr *) (skb->data + skb_network_offset(skb));
+
+	/* Try to get transport header */
+	nexthdr = ipv6_find_hdr(skb, &nhoffs, -1, &fragoff, &flag);
+	if (nexthdr < 0)
+		return XT_CONTINUE;
+	/* dont check for icmp on fragments */
+	if ((flag & IP6T_FH_F_FRAG) || (nexthdr != IPPROTO_ICMPV6))
+		goto noicmp;
+	/* ICMP: if an error then move ptr to inner header */
+	if (get_inner6_hdr(skb, &nhoffs)) {
+		/* Get IPv6 header ptr just to get the saddr & daddr later */
+		ip6 = skb_header_pointer(skb, nhoffs, sizeof(_ip6), &_ip6);
+		if (!ip6)
+			return XT_CONTINUE;
+		/* Treat AH as ESP */
+		flag = IP6T_FH_F_AUTH;
+		nexthdr = ipv6_find_hdr(skb, &nhoffs, -1, &fragoff, &flag);
+		if (nexthdr < 0)
+			return XT_CONTINUE;
+	}
+noicmp:
+	/* Mask of the address and xor it into a u32 */
+	addr1 = (__force u32)
+		(ip6->saddr.s6_addr32[0] & info->smask.in6.s6_addr32[0]) ^
+		(ip6->saddr.s6_addr32[1] & info->smask.in6.s6_addr32[1]) ^
+		(ip6->saddr.s6_addr32[2] & info->smask.in6.s6_addr32[2]) ^
+		(ip6->saddr.s6_addr32[3] & info->smask.in6.s6_addr32[3]);
+	addr2 = (__force u32)
+		(ip6->daddr.s6_addr32[0] & info->dmask.in6.s6_addr32[0]) ^
+		(ip6->daddr.s6_addr32[1] & info->dmask.in6.s6_addr32[1]) ^
+		(ip6->daddr.s6_addr32[2] & info->dmask.in6.s6_addr32[2]) ^
+		(ip6->daddr.s6_addr32[3] & info->dmask.in6.s6_addr32[3]);
+
+	/* Is next header valid for port or SPI calculation ? */
+	poff = proto_ports_offset(nexthdr);
+	if ((flag & IP6T_FH_F_FRAG) || poff < 0)
+		goto no6ports;
+	nhoffs += poff;
+	/* Since uports is modified, skb_header_pointer() can't be used */
+	 if(!pskb_may_pull(skb, nhoffs + 4))
+		goto no6ports;
+	uports.v32 = * (__force u32 *) (skb->data + nhoffs);
+
+	if ((nexthdr == IPPROTO_ESP) || (nexthdr == IPPROTO_AH)) {
+		uports.v32 = (uports.v32 & info->spimask) | info->spiset;
+	} else {
+		uports.v32 = (uports.v32 & info->pmask.v32) | info->pset.v32;
+		/* get a consistent hash (same value on both flow directions) */
+		if (uports.p16.dst < uports.p16.src)
+			swap(uports.p16.dst, uports.p16.src);
+	}
+
+no6ports:
+	nexthdr &= info->prmask;
+	/* get a consistent hash (same value on both flow directions) */
+	if (addr2 < addr1)
+		swap(addr1, addr2);
+
+	hash = jhash_3words(addr1, addr2, uports.v32, info->hashrnd) ^ nexthdr;
+	skb->mark = (hash % info->hmod) + info->hoffs;
+	return XT_CONTINUE;
+}
+#endif
+/*
+ * Calculate hash based fw-mark, on the five tuple if possible.
+ * special cases :
+ *  - Fragments do not use ports not even on the first fragment,
+ *    unless nf_defrag_xx.ko is used.
+ *  - On ICMP errors the inner header will be used.
+ *  - Tunnels no ports
+ *  - ESP & AH uses SPI
+ * @returns XT_CONTINUE
+ */
+unsigned int hmark_v4(struct sk_buff *skb, const struct xt_action_param *par)
+{
+	struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
+	int nhoff, poff, frag = 0;
+	struct iphdr *ip, _ip;
+	u8 ip_proto;
+	u32 addr1, addr2, hash;
+	u16 snatport = 0, dnatport = 0;
+#if defined(CONFIG_NF_NAT)
+	enum ip_conntrack_info ctinfo;
+	struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+#endif
+	union hports uports;
+
+	if (!info->hmod)
+		return XT_CONTINUE;
+
+	nhoff = skb_network_offset(skb);
+	uports.v32 = 0;
+
+	ip = (struct iphdr *) (skb->data + nhoff);
+	if (ip->protocol == IPPROTO_ICMP) {
+		/* calc hash on inner header if an icmp error */
+		nhoff = get_inner_hdr(skb, ip->ihl * 4, nhoff);
+		ip = skb_header_pointer(skb, nhoff, sizeof(_ip), &_ip);
+		if (!ip)
+			return XT_CONTINUE;
+	}
+
+	ip_proto = ip->protocol;
+	if (ip->frag_off & htons(IP_MF | IP_OFFSET))
+		frag = 1;
+
+	addr1 = (__force u32) ip->saddr & info->smask.ip;
+	addr2 = (__force u32) ip->daddr & info->dmask.ip;
+
+#if defined(CONFIG_NF_NAT)
+	if (ct && test_bit(IP_CT_IS_REPLY, &ct->status)) {
+		struct nf_conntrack_tuple *otuple;
+
+		otuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
+		/*
+		 * On the "return flow", to get the original address
+		 */
+		if ((ct->status & IPS_DST_NAT) &&
+			(info->flags & XT_HMARK_USE_DNAT)) {
+			addr1 = (__force u32) otuple->dst.u3.in.s_addr;
+			dnatport = otuple->dst.u.udp.port;
+		}
+		if ((ct->status & IPS_SRC_NAT) &&
+			(info->flags & XT_HMARK_USE_SNAT)) {
+			addr2 = (__force u32) otuple->src.u3.in.s_addr;
+			snatport = otuple->src.u.udp.port;
+		}
+	}
+#endif
+	/* Check if ports can be used in hash calculation. */
+	poff = proto_ports_offset(ip_proto);
+	if (frag || poff < 0)
+		goto noports;
+
+	nhoff += (ip->ihl * 4) + poff;
+	if (!pskb_may_pull(skb, nhoff + 4))
+		goto noports;
+
+	uports.v32 = * (__force u32 *) (skb->data + nhoff);
+	if (ip_proto == IPPROTO_ESP || ip_proto == IPPROTO_AH) {
+		uports.v32 = (uports.v32 & info->spimask) | info->spiset;
+	} else {
+		if (snatport)	/* Replace nat'ed port(s) */
+			uports.p16.dst = snatport;
+		if (dnatport)
+			uports.p16.src = dnatport;
+		uports.v32 = (uports.v32 & info->pmask.v32) |
+				info->pset.v32;
+		/* get a consistent hash (same value on both flow directions) */
+		if (uports.p16.dst < uports.p16.src)
+			swap(uports.p16.src, uports.p16.dst);
+	}
+
+noports:
+	ip_proto &= info->prmask;
+	/* get a consistent hash (same value on both flow directions) */
+	if (addr2 < addr1)
+		swap(addr1, addr2);
+
+	hash = jhash_3words(addr1, addr2, uports.v32, info->hashrnd) ^ ip_proto;
+	skb->mark = (hash % info->hmod) + info->hoffs;
+	return XT_CONTINUE;
+}
+
+static struct xt_target hmark_tg_reg[] __read_mostly = {
+	{
+		.name           = "HMARK",
+		.revision       = 0,
+		.family         = NFPROTO_IPV4,
+		.target         = hmark_v4,
+		.targetsize     = sizeof(struct xt_hmark_info),
+		.me             = THIS_MODULE,
+	},
+#ifdef WITH_IPV6
+	{
+		.name           = "HMARK",
+		.revision       = 0,
+		.family         = NFPROTO_IPV6,
+		.target         = hmark_v6,
+		.targetsize     = sizeof(struct xt_hmark_info),
+		.me             = THIS_MODULE,
+	},
+#endif
+};
+
+static int __init hmark_mt_init(void)
+{
+	int ret;
+
+	ret = xt_register_targets(hmark_tg_reg, ARRAY_SIZE(hmark_tg_reg));
+	if (ret < 0)
+		return ret;
+	return 0;
+}
+
+static void __exit hmark_mt_exit(void)
+{
+	xt_unregister_targets(hmark_tg_reg, ARRAY_SIZE(hmark_tg_reg));
+}
+
+module_init(hmark_mt_init);
+module_exit(hmark_mt_exit);
-- 
1.7.2.3

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [v7 PATCH 3/3] NETFILTER userspace part for target HMARK
  2012-01-13  9:52 [v7 PATCH 0/3] NETFILTER new target module, HMARK Hans Schillstrom
  2012-01-13  9:52 ` [PATCH 1/3] NETFILTER added flags to ipv6_find_hdr() Hans Schillstrom
  2012-01-13  9:52 ` [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark Hans Schillstrom
@ 2012-01-13  9:52 ` Hans Schillstrom
  2 siblings, 0 replies; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-13  9:52 UTC (permalink / raw)
  To: kaber, pablo, jengelh, netfilter-devel, netdev; +Cc: hans, Hans Schillstrom

    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.

    The mark match can also be used to match nfmark produced by this module.
    Ver 7
      -
    Ver 6
      -
    Ver 5
      smask and dmask changed to length

    Ver 4
      xtoptions used for parsing.

    Ver 3
       -

    Ver 2
      IPv4 NAT added
      iptables ver 1.4.12.1 adaptions.

Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
---
 extensions/libxt_HMARK.c           |  335 ++++++++++++++++++++++++++++++++++++
 extensions/libxt_HMARK.man         |   65 +++++++
 include/linux/netfilter/xt_hmark.h |   62 +++++++
 3 files changed, 462 insertions(+), 0 deletions(-)
 create mode 100644 extensions/libxt_HMARK.c
 create mode 100644 extensions/libxt_HMARK.man
 create mode 100644 include/linux/netfilter/xt_hmark.h

diff --git a/extensions/libxt_HMARK.c b/extensions/libxt_HMARK.c
new file mode 100644
index 0000000..ec74a19
--- /dev/null
+++ b/extensions/libxt_HMARK.c
@@ -0,0 +1,335 @@
+/*
+ * Shared library add-on to iptables to add HMARK target support.
+ *
+ * The kernel module calculates a hash value that can be modified by modulus
+ * and an offset. The hash value is based on a direction independent
+ * five tuple: src & dst addr src & dst ports and protocol.
+ * However src & dst port can be masked and are not used for fragmented
+ * packets, ESP and AH don't have ports so SPI will be used instead.
+ * For ICMP error messages the hash mark values will be calculated on
+ * the source packet i.e. the packet caused the error (If sufficient
+ * amount of data exists).
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <stdbool.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <xtables.h>
+#include <linux/netfilter/xt_hmark.h>
+
+
+#define DEF_HRAND 0xc175a3b8	/* Default "random" value to jhash */
+
+static void HMARK_help(void)
+{
+	printf(
+"HMARK target options, i.e. modify hash calculation by:\n"
+"  --hmark-smask length               Source address mask length\n"
+"  --hmark-dmask length               Dest address mask length\n"
+"  --hmark-sp-mask value              Mask src port with value\n"
+"  --hmark-dp-mask value              Mask dst port with value\n"
+"  --hmark-spi-mask value             For esp and ah AND spi with value\n"
+"  --hmark-sp-set value               OR src port with value\n"
+"  --hmark-dp-set value               OR dst port with value\n"
+"  --hmark-spi-set value              For esp and ah OR spi with value\n"
+"  --hmark-proto-mask value           Mask Protocol with value\n"
+"  --hmark-rnd                        Random value to hash cacl.\n"
+"  Limit/modify the calculated hash mark by:\n"
+"  --hmark-mod value                  nfmark modulus value\n"
+"  --hmark-offs value                 Last action add value to nfmark\n"
+" For NAT in IPv4 the original address can be used in the return path.\n"
+" Make sure to qualify the statement in a proper way when using nat flags\n"
+"  --hmark-dnat                       Replace src addr with original dst addr\n"
+"  --hmark-snat                       Replace dst addr with original src addr\n"
+" In many cases hmark can be omitted i.e. --smask can be used\n");
+}
+
+#define hi struct xt_hmark_info
+
+static const struct xt_option_entry HMARK_opts[] = {
+	{ .name = "hmark-smask",      .type = XTTYPE_PLENMASK, .id = XT_HMARK_SADR_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, smask)
+	},
+	{ .name = "hmark-dmask",      .type = XTTYPE_PLENMASK, .id = XT_HMARK_DADR_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, dmask)
+	},
+	{ .name = "hmark-sp-mask",    .type = XTTYPE_UINT16, .id = XT_HMARK_SPORT_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, pmask.p16.src)
+	},
+	{ .name = "hmark-dp-mask",    .type = XTTYPE_UINT16, .id = XT_HMARK_DPORT_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, pmask.p16.dst)
+	},
+	{ .name = "hmark-spi-mask",   .type = XTTYPE_UINT32, .id = XT_HMARK_SPI_AND,
+	  .flags = XTOPT_PUT,  XTOPT_POINTER(hi, spimask)
+	},
+	{ .name = "hmark-sp-set",     .type = XTTYPE_UINT16, .id = XT_HMARK_SPORT_OR,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, pset.p16.src)
+	},
+	{ .name = "hmark-dp-set",     .type = XTTYPE_UINT16, .id = XT_HMARK_DPORT_OR,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, pset.p16.dst)
+	},
+	{ .name = "hmark-spi-set",    .type = XTTYPE_UINT32, .id = XT_HMARK_SPI_OR,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, spiset)
+	},
+	{ .name = "hmark-proto-mask", .type = XTTYPE_UINT16, .id = XT_HMARK_PROTO_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, prmask)
+	},
+	{ .name = "hmark-rnd",        .type = XTTYPE_UINT32, .id = XT_HMARK_RND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, hashrnd)
+	},
+	{ .name = "hmark-mod",        .type = XTTYPE_UINT32, .id = XT_HMARK_MODULUS,
+	  .flags = XTOPT_PUT | XTOPT_MAND, XTOPT_POINTER(hi, hmod)
+	},
+	{ .name = "hmark-offs",       .type = XTTYPE_UINT32, .id = XT_HMARK_OFFSET,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, hoffs)
+	},
+	{ .name = "hmark-dnat",       .type = XTTYPE_NONE,   .id = XT_HMARK_USE_DNAT },
+	{ .name = "hmark-snat",       .type = XTTYPE_NONE,   .id = XT_HMARK_USE_SNAT },
+
+	{ .name = "smask",      .type = XTTYPE_PLENMASK, .id = XT_HMARK_SADR_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, smask)
+	},
+	{ .name = "dmask",      .type = XTTYPE_PLENMASK, .id = XT_HMARK_DADR_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, dmask)
+	},
+	{ .name = "sp-mask",    .type = XTTYPE_UINT16, .id = XT_HMARK_SPORT_AND,
+	  .flags = XTOPT_PUT,  XTOPT_POINTER(hi, pmask.p16.src)
+	},
+	{ .name = "dp-mask",    .type = XTTYPE_UINT16, .id = XT_HMARK_DPORT_AND,
+	  .flags = XTOPT_PUT,  XTOPT_POINTER(hi, pmask.p16.dst)
+	},
+	{ .name = "spi-mask",   .type = XTTYPE_UINT32, .id = XT_HMARK_SPI_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, spimask)
+	},
+	{ .name = "sp-set",     .type = XTTYPE_UINT16, .id = XT_HMARK_SPORT_OR,
+	  .flags = XTOPT_PUT,  XTOPT_POINTER(hi, pset.p16.src)
+	},
+	{ .name = "dp-set",     .type = XTTYPE_UINT16, .id = XT_HMARK_DPORT_OR,
+	  .flags = XTOPT_PUT,  XTOPT_POINTER(hi, pset.p16.dst)
+	},
+	{ .name = "spi-set",    .type = XTTYPE_UINT32, .id = XT_HMARK_SPI_OR,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, spiset)
+	},
+	{ .name = "proto-mask", .type = XTTYPE_UINT16, .id = XT_HMARK_PROTO_AND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, prmask)
+	},
+	{ .name = "rnd",        .type = XTTYPE_UINT32, .id = XT_HMARK_RND,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, hashrnd)
+	},
+	{ .name = "mod",        .type = XTTYPE_UINT32, .id = XT_HMARK_MODULUS,
+	  .flags = XTOPT_PUT | XTOPT_MAND, XTOPT_POINTER(hi, hmod)
+	},
+	{ .name = "offs",       .type = XTTYPE_UINT32, .id = XT_HMARK_OFFSET,
+	  .flags = XTOPT_PUT, XTOPT_POINTER(hi, hoffs)
+	},
+	{ .name = "dnat",       .type = XTTYPE_NONE,   .id = XT_HMARK_USE_DNAT },
+	{ .name = "snat",       .type = XTTYPE_NONE,   .id = XT_HMARK_USE_SNAT },
+	XTOPT_TABLEEND,
+};
+
+static void HMARK_parse(struct xt_option_call *cb)
+{
+	struct xt_hmark_info *info = cb->data;
+
+	if (!cb->xflags) {
+		memset(info, 0xff, sizeof(struct xt_hmark_info));
+		info->pset.v32 = 0;
+		info->flags = 0;
+		info->spiset = 0;
+		info->hoffs = 0;
+		info->hashrnd = DEF_HRAND;
+	}
+	xtables_option_parse(cb);
+
+	switch (cb->entry->id) {
+	case XT_HMARK_SPI_AND:
+		info->spimask = htonl(cb->val.u32);
+		break;
+	case XT_HMARK_SPI_OR:
+		info->spiset = htonl(cb->val.u32);
+		break;
+	case XT_HMARK_SPORT_AND:
+		info->pmask.p16.src = htons(cb->val.u16);
+		break;
+	case XT_HMARK_DPORT_AND:
+		info->pmask.p16.dst = htons(cb->val.u16);
+		break;
+	case XT_HMARK_SPORT_OR:
+		info->pset.p16.src = htons(cb->val.u16);
+		break;
+	case XT_HMARK_DPORT_OR:
+		info->pset.p16.dst = htons(cb->val.u16);
+		break;
+	case XT_HMARK_MODULUS:
+		if (info->hmod == 0) {
+			xtables_error(PARAMETER_PROBLEM,
+				      "xxx modulus 0 ? "
+				      "thats a div by 0");
+			info->hmod = 0xffffffff;
+		}
+		break;
+	}
+	info->flags = cb->xflags;
+}
+
+static void HMARK_check(struct xt_fcheck_call *cb)
+{
+	if (!(cb->xflags & XT_F_HMARK_MODULUS))
+		xtables_error(PARAMETER_PROBLEM, "HMARK: the --hmark-mod, "
+			   "is not set, that means the nfmark will be in range"
+			   " 0 - 0xffffffff");
+}
+/*
+ * Common print for IPv4 & IPv6
+ */
+static void HMARK_print(const struct xt_hmark_info *info)
+{
+	if (info->flags & (1 << XT_HMARK_SPORT_AND))
+		printf("sp-mask 0x%x ", htons(info->pmask.p16.src));
+	if (info->flags & (1 << XT_HMARK_DPORT_AND))
+		printf("dp-mask 0x%x ", htons(info->pmask.p16.dst));
+	if (info->flags & (1 << XT_HMARK_SPI_AND))
+		printf("spi-mask 0x%x ", htonl(info->spimask));
+	if (info->flags & (1 << XT_HMARK_SPORT_OR))
+		printf("sp-set 0x%x ", htons(info->pset.p16.src));
+	if (info->flags & (1 << XT_HMARK_DPORT_OR))
+		printf("dp-set 0x%x ", htons(info->pset.p16.dst));
+	if (info->flags & (1 << XT_HMARK_SPI_OR))
+		printf("spi-set 0x%x ", htonl(info->spiset));
+	if (info->flags & (1 << XT_HMARK_PROTO_AND))
+		printf("proto-mask 0x%x ", info->prmask);
+	if (info->flags & (1 << XT_HMARK_RND))
+		printf("rnd 0x%x ", info->hashrnd);
+}
+
+static void HMARK_ip6_print(const void *ip, const struct xt_entry_target *target,
+			int numeric)
+{
+	const struct xt_hmark_info *info =
+			(const struct xt_hmark_info *)target->data;
+
+	printf(" HMARK ");
+	if (info->flags & (1 << XT_HMARK_MODULUS))
+		printf("%% 0x%x ", info->hmod);
+	if (info->flags & (1 << XT_HMARK_OFFSET))
+		printf("+ 0x%x ", info->hoffs);
+	if (info->flags & (1 << XT_HMARK_USE_SNAT))
+		printf("snat, ");
+	if (info->flags & (1 << XT_HMARK_SADR_AND))
+		printf("smask %s ", xtables_ip6mask_to_numeric(&info->smask.in6) + 1);
+	if (info->flags & (1 << XT_HMARK_USE_DNAT))
+		printf("dnat, ");
+	if (info->flags & (1 << XT_HMARK_DADR_AND))
+		printf("dmask %s ", xtables_ip6mask_to_numeric(&info->dmask.in6) + 1);
+	HMARK_print(info);
+}
+static void HMARK_ip4_print(const void *ip, const struct xt_entry_target *target, int numeric)
+{
+	const struct xt_hmark_info *info = (const struct xt_hmark_info *)target->data;
+
+	printf(" HMARK ");
+	if (info->flags & (1 << XT_HMARK_MODULUS))
+		printf("%% 0x%x ", info->hmod);
+	if (info->flags & (1 << XT_HMARK_OFFSET))
+		printf("+ 0x%x ", info->hoffs);
+	if (info->flags & (1 << XT_HMARK_USE_SNAT))
+		printf("snat, ");
+	if (info->flags & (1 << XT_HMARK_SADR_AND))
+		printf("smask %s ", xtables_ipmask_to_numeric(&info->smask.in) + 1);
+	if (info->flags & (1 << XT_HMARK_USE_DNAT))
+		printf("dnat, ");
+	if (info->flags & (1 << XT_HMARK_DADR_AND))
+		printf("dmask %s ", xtables_ipmask_to_numeric(&info->dmask.in) + 1);
+	HMARK_print(info);
+}
+static void HMARK_save(const struct xt_hmark_info *info)
+{
+	if (info->flags & (1 << XT_HMARK_SPORT_AND))
+		printf(" --hmark-sp-mask 0x%x", htons(info->pmask.p16.src));
+	if (info->flags & (1 << XT_HMARK_DPORT_AND))
+		printf(" --hmark-dp-mask 0x%x", htons(info->pmask.p16.dst));
+	if (info->flags & (1 << XT_HMARK_SPI_AND))
+		printf(" --hmark-spi-mask 0x%x", htonl(info->spimask));
+	if (info->flags & (1 << XT_HMARK_SPORT_OR))
+		printf(" --hmark-sp-set 0x%x", htons(info->pset.p16.src));
+	if (info->flags & (1 << XT_HMARK_DPORT_OR))
+		printf(" --hmark-dp-set 0x%x", htons(info->pset.p16.dst));
+	if (info->flags & (1 << XT_HMARK_SPI_OR))
+		printf(" --hmark-spi-set 0x%x", htonl(info->spiset));
+	if (info->flags & (1 << XT_HMARK_PROTO_AND))
+		printf(" --hmark-proto-mask 0x%x", info->prmask);
+	if (info->flags & (1 << XT_HMARK_RND))
+		printf(" --hmark-rnd 0x%x", info->hashrnd);
+	if (info->flags & (1 << XT_HMARK_MODULUS))
+		printf(" --hmark-mod 0x%x", info->hmod);
+	if (info->flags & (1 << XT_HMARK_OFFSET))
+		printf(" --hmark-offs 0x%x", info->hoffs);
+	if (info->flags & (1 << XT_HMARK_USE_DNAT))
+		printf(" --hmark-dnat");
+	if (info->flags & (1 << XT_HMARK_USE_SNAT))
+		printf(" --hmark-snat");
+}
+
+static void HMARK_ip6_save(const void *ip, const struct xt_entry_target *target)
+{
+	const struct xt_hmark_info *info =
+		(const struct xt_hmark_info *)target->data;
+
+	if (info->flags & (1 << XT_HMARK_SADR_AND))
+		printf(" --hmark-smask %s", xtables_ip6mask_to_numeric(&info->smask.in6) + 1);
+	if (info->flags & (1 << XT_HMARK_DADR_AND))
+		printf(" --hmark-dmask %s", xtables_ip6mask_to_numeric(&info->dmask.in6) + 1);
+	HMARK_save(info);
+}
+
+static void HMARK_ip4_save(const void *ip, const struct xt_entry_target *target)
+{
+	const struct xt_hmark_info *info =
+		(const struct xt_hmark_info *)target->data;
+
+	if (info->flags & (1 << XT_HMARK_SADR_AND))
+		printf(" --hmark-smask %s", xtables_ipmask_to_numeric(&info->smask.in) + 1);
+	if (info->flags & (1 << XT_HMARK_DADR_AND))
+		printf(" --hmark-dmask %s", xtables_ipmask_to_numeric(&info->dmask.in) + 1);
+	HMARK_save(info);
+}
+
+static struct xtables_target mark_tg_reg[] = {
+	{
+		.family        = NFPROTO_IPV4,
+		.name          = "HMARK",
+		.version       = XTABLES_VERSION,
+		.revision      = 0,
+		.size          = XT_ALIGN(sizeof(struct xt_hmark_info)),
+		.userspacesize = XT_ALIGN(sizeof(struct xt_hmark_info)),
+		.help          = HMARK_help,
+		.print         = HMARK_ip4_print,
+		.save          = HMARK_ip4_save,
+		.x6_parse      = HMARK_parse,
+		.x6_fcheck     = HMARK_check,
+		.x6_options    = HMARK_opts,
+	},
+	{
+		.family        = NFPROTO_IPV6,
+		.name          = "HMARK",
+		.version       = XTABLES_VERSION,
+		.revision      = 0,
+		.size          = XT_ALIGN(sizeof(struct xt_hmark_info)),
+		.userspacesize = XT_ALIGN(sizeof(struct xt_hmark_info)),
+		.help          = HMARK_help,
+		.print         = HMARK_ip6_print,
+		.save          = HMARK_ip6_save,
+		.x6_parse      = HMARK_parse,
+		.x6_fcheck     = HMARK_check,
+		.x6_options    = HMARK_opts,
+	},
+};
+
+void _init(void)
+{
+	xtables_register_targets(mark_tg_reg, ARRAY_SIZE(mark_tg_reg));
+}
+
diff --git a/extensions/libxt_HMARK.man b/extensions/libxt_HMARK.man
new file mode 100644
index 0000000..74beb64
--- /dev/null
+++ b/extensions/libxt_HMARK.man
@@ -0,0 +1,65 @@
+This module does the same as MARK, i.e. set an fwmark, but the mark is based on a hash value.
+The hash is based on saddr, daddr, sport, dport and proto. The same mark will be produced independet of direction if no masks is set or the same masks is used for src and dest.
+The hash mark could be adjusted by modulus and finally an offset could be added, i.e the final mark will be within a range.
+ICMP error will use the the original message for hash calculation not the icmp it self.
+Fragmented packets will not use ports/spi not even the first packet.
+
+Note: IPv4 packets with nf_defrag_ipv4 loaded will be defragmented before they reach hmark,
+      IPv6 nf_defrag is not implemented this way, hence fragmented ipv6 packets will reach hmark.
+      None of the parameters effect the packet it self only the calculated hash value.
+.PP
+Parameters:
+For all masks default is all "1:s", to disable a field use mask 0
+For IPv6 it's just the last 32 bits that is included in the hash
+.TP
+\fB\-\-hmark\-smask\fP \fIlength\fP
+The length of the mask to AND the source address with (saddr & value).
+.TP
+\fB\-\-hmark\-dmask\fP \fIlength\fP
+The length of the mask to AND the dest. address with (daddr & value).
+.TP
+\fB\-\-hmark\-sp\-mask\fP \fIvalue\fP
+A 16 bit value to AND the src port with (sport & value).
+.TP
+\fB\-\-hmark\-dp\-mask\fP \fIvalue\fP
+A 16 bit value to AND the dest port with (dport & value).
+.TP
+\fB\-\-hmark\-sp\-set\fP \fIvalue\fP
+A 16 bit value to OR the src port with (sport | value).
+.TP
+\fB\-\-hmark\-dp\-set\fP \fIvalue\fP
+A 16 bit value to OR the dest port with (dport | value).
+.TP
+\fB\-\-hmark\-spi\-mask\fP \fIvalue\fP
+Value to AND the spi field with (spi & value) valid for proto esp or ah.
+.TP
+\fB\-\-hmark\-spi\-set\fP \fIvalue\fP
+Value to OR the spi field with (spi | value) valid for proto esp or ah.
+.TP
+\fB\-\-hmark\-proto\-mask\fP \fIvalue\fP
+An 8 bit value to AND the L4 proto field with (proto & value).
+.TP
+\fB\-\-hmark\-rnd\fP \fIvalue\fP
+A 32 bit initial value for hash calc, default is 0xc175a3b8.
+.PP
+Final processing of the mark in order of execution.
+.TP
+\fB\-\-hmark\-mod\fP \fvalue (must be > 0)\fP
+The easiest way to describe this is:  hash = hash mod <value>
+.TP
+\fB\-\-hmark\-offs\fP \fvalue\fP
+The easiest way to describe this is:  hash = hash + <value>
+.PP
+\fIExamples:\fP
+.PP
+Default rule handles all TCP, UDP, SCTP, ESP & AH
+.IP
+iptables \-t mangle \-A PREROUTING \-m state \-\-state NEW,ESTABLISHED,RELATED
+ \-j HMARK \-\-hmark-offs 10000 \-\-hmark-mod 10
+.PP
+Handle SCTP and hash dest port only and produce a nfmark between 100-119.
+.IP
+iptables \-t mangle \-A PREROUTING -p SCTP \-j HMARK \-\-smask 0 \-\-dmask 0
+ \-\-sp\-mask 0 \-\-offs 100 \-\-mod 20
+.PP
+
diff --git a/include/linux/netfilter/xt_hmark.h b/include/linux/netfilter/xt_hmark.h
new file mode 100644
index 0000000..366ecce
--- /dev/null
+++ b/include/linux/netfilter/xt_hmark.h
@@ -0,0 +1,62 @@
+#ifndef XT_HMARK_H_
+#define XT_HMARK_H_
+
+#include <linux/types.h>
+
+/*
+ * Flags must not start at 0, since it's used as none.
+ */
+enum {
+	XT_HMARK_SADR_AND = 1,	/* SNAT & DNAT are used by the kernel module */
+	XT_HMARK_DADR_AND,
+	XT_HMARK_SPI_AND,
+	XT_HMARK_SPI_OR,
+	XT_HMARK_SPORT_AND,
+	XT_HMARK_DPORT_AND,
+	XT_HMARK_SPORT_OR,
+	XT_HMARK_DPORT_OR,
+	XT_HMARK_PROTO_AND,
+	XT_HMARK_RND,
+	XT_HMARK_MODULUS,
+	XT_HMARK_OFFSET,
+	XT_HMARK_USE_SNAT,
+	XT_HMARK_USE_DNAT,
+	XT_F_HMARK_USE_SNAT = 1 << XT_HMARK_USE_SNAT,
+	XT_F_HMARK_USE_DNAT = 1 << XT_HMARK_USE_DNAT,
+	XT_F_HMARK_SADR_AND = 1 << XT_HMARK_SADR_AND,
+	XT_F_HMARK_DADR_AND = 1 << XT_HMARK_DADR_AND,
+	XT_F_HMARK_SPI_AND = 1 << XT_HMARK_SPI_AND,
+	XT_F_HMARK_SPI_OR = 1 << XT_HMARK_SPI_OR,
+	XT_F_HMARK_SPORT_AND = 1 << XT_HMARK_SPORT_AND,
+	XT_F_HMARK_DPORT_AND = 1 << XT_HMARK_DPORT_AND,
+	XT_F_HMARK_SPORT_OR = 1 << XT_HMARK_SPORT_OR,
+	XT_F_HMARK_DPORT_OR = 1 << XT_HMARK_DPORT_OR,
+	XT_F_HMARK_PROTO_AND = 1 << XT_HMARK_PROTO_AND,
+	XT_F_HMARK_RND = 1 << XT_HMARK_RND,
+	XT_F_HMARK_MODULUS = 1 << XT_HMARK_MODULUS,
+	XT_F_HMARK_OFFSET = 1 << XT_HMARK_OFFSET,
+};
+
+union hports {
+	struct {
+		__u16	src;
+		__u16	dst;
+	} p16;
+	__u32	v32;
+};
+
+struct xt_hmark_info {
+	union nf_inet_addr	smask;		/* Source address mask */
+	union nf_inet_addr	dmask;		/* Dest address mask */
+	union hports		pmask;
+	union hports		pset;
+	__u32			spimask;
+	__u32			spiset;
+	__u16			flags;		/* Print out only */
+	__u16			prmask;		/* L4 Proto mask */
+	__u32			hashrnd;
+	__u32			hmod;		/* Modulus */
+	__u32			hoffs;		/* Offset */
+};
+
+#endif /* XT_HMARK_H_ */
-- 
1.7.2.3


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-13  9:52 ` [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark Hans Schillstrom
@ 2012-01-22 21:44   ` Pablo Neira Ayuso
  2012-01-22 23:20     ` Hans Schillstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Pablo Neira Ayuso @ 2012-01-22 21:44 UTC (permalink / raw)
  To: Hans Schillstrom; +Cc: kaber, jengelh, netfilter-devel, netdev, hans

Hi Hans,

This starts looking good :-). Some comments on your patch:

On Fri, Jan 13, 2012 at 10:52:17AM +0100, Hans Schillstrom wrote:
>        Fragmentation:
>         - If a packet is fragmented NONE of the Fragments will include
>           ports in the hash calculation.
>           When fragments arrives on different machines HMARK will produce
>           same fwmark for all frags inpendent of machine so they can be routed
>           to the same destination.

I've got one scenario that may break with this assumption:

1) your traffic follows one path over router A and B to reach your
   firewall F which requires no fragmentation at all.
2) path to router B becomes broken while there are established flows
   with firewall F.
3) router A decides to forward packets to router C, which fragment
   packets because it is using smaller MTU than router A.
4) packets arrive to firewall F, then hashing is calculated based on
   addresses, not ports, and you load-sharing becomes inconsistent.

This can rarely happen, but it does, it would break.

To fix this, I think that HMARK requires that you have to specify the
hashing strategy. If you want to support fragments, use only
addresses. If you're sure you will not get fragments, use layer 3 and
layer 4 information.

>         - If nf_defrag_ipv{4,6} is loaded the packets will be defragmented
>           before reaching HMARK, i.e. in that case ports (if any) will be used.
>           (ICMP Time exceeded will be sent if fragments are lost)
> 
>        Parameters: For all masks default is all "1:s", to disable a field
>                    use mask 0. For IPv6 it's just the last 32 bits that
>                    is included in the hash.
> 
>        --hmark-smask length (0-32 or 0-128)
>               The value to AND the source address with (saddr & value).
> 
>        --hmark-dmask length (0-32 or 0-128)
>               The value to AND the dest. address with (daddr & value).
> 
>        --hmark-sp-mask value
>               A 16 bit value to AND the src port with (sport & value).
> 
>        --hmark-dp-mask value
>               A 16 bit value to AND the dest port with (dport & value).
> 
>        --hmark-sp-set value
>               A 16 bit value to OR the src port with (sport | value).
> 
>        --hmark-dp-set value
>               A 16 bit value to OR the dest port with (dport | value).
> 
>        --hmark-spi-mask value
>               Value to AND the spi field with (spi & value) valid for proto esp or ah.
> 
>        --hmark-spi-set value
>               Value to OR the spi field with (spi | value) valid for proto esp or ah.
> 
>        --hmark-proto-mask value
>               A 16 bit value to AND the L4 proto field with (proto & value).
> 
>        --hmark-rnd value
>               A 32 bit intitial value for hash calc, default is 0xc175a3b8.
> 
>        --hmark-dnat (only IPv4)
>               Replace src addr/port with original dst addr/port before calc, hash
> 
>        --hmark-snat (only IPv4)
>               Replace dst addr/port with original src addr/port before calc, hash
> 
>        Final processing of the mark in order of execution.
> 
>        --hmark-mod value (must be > 0)
>               The easiest way to describe this is:  hash = hash mod <value>
> 
>        --hmark-offs alue (must be > 0)
>               The easiest way to describe this is:  hash = hash + <value>
> 
>        Examples:
> 
>        Default rule handles all TCP, UDP, SCTP, ESP & AH
> 
> Rev 7
>       IPv6 descending into icmp error hdr didn't work as expected
>       with ipv6_find_hdr() Now it works as expected.
> 
> Rev 6
>       Compile options with or without conntrack fixed.
>       __ipv6_find_hdr() replaced by ipv6_find_hdr()
> 
> Rev 5
>       IPv6 rewritten uses __ipv6_find_hdr() (P. Mc Hardy)
>       Full mask and address used for IPv6 smask and dmask (J.Engelhart)
>       Changes due to comments by Pablo Neira Ayuso  and Eric Dumazet
>       i.e uses of skb_header_pointer() and Null check of info->hmod
>       Man page changes
> 
> Rev 4
>       different targets for IPv4 and IPv6
>       Changes based on review by Pablo.
> 
> Rev 3
>       Support added to SCTP for IPv6
> Rev 2
>       IPv6 header scan changed to follow RFC 2640
>       IPv4 icmp echo fragmented does now use proto as ipv6
>       IPv6 pskb_may_pull() check is done in every time in header loop.
>       IPv4 nat support added.
>       default added in IPv6 loop and null check of hp
> 
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> ---
>  include/linux/netfilter/xt_hmark.h |   62 +++++++
>  net/netfilter/Kconfig              |   17 ++
>  net/netfilter/Makefile             |    1 +
>  net/netfilter/xt_hmark.c           |  337 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 417 insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/netfilter/xt_hmark.h
>  create mode 100644 net/netfilter/xt_hmark.c
> 
> diff --git a/include/linux/netfilter/xt_hmark.h b/include/linux/netfilter/xt_hmark.h
> new file mode 100644
> index 0000000..366ecce
> --- /dev/null
> +++ b/include/linux/netfilter/xt_hmark.h
> @@ -0,0 +1,62 @@
> +#ifndef XT_HMARK_H_
> +#define XT_HMARK_H_
> +
> +#include <linux/types.h>
> +
> +/*
> + * Flags must not start at 0, since it's used as none.
> + */
> +enum {
> +	XT_HMARK_SADR_AND = 1,	/* SNAT & DNAT are used by the kernel module */
> +	XT_HMARK_DADR_AND,
> +	XT_HMARK_SPI_AND,
> +	XT_HMARK_SPI_OR,
> +	XT_HMARK_SPORT_AND,
> +	XT_HMARK_DPORT_AND,
> +	XT_HMARK_SPORT_OR,
> +	XT_HMARK_DPORT_OR,
> +	XT_HMARK_PROTO_AND,
> +	XT_HMARK_RND,
> +	XT_HMARK_MODULUS,
> +	XT_HMARK_OFFSET,
> +	XT_HMARK_USE_SNAT,
> +	XT_HMARK_USE_DNAT,
> +	XT_F_HMARK_USE_SNAT = 1 << XT_HMARK_USE_SNAT,
> +	XT_F_HMARK_USE_DNAT = 1 << XT_HMARK_USE_DNAT,
> +	XT_F_HMARK_SADR_AND = 1 << XT_HMARK_SADR_AND,
> +	XT_F_HMARK_DADR_AND = 1 << XT_HMARK_DADR_AND,
> +	XT_F_HMARK_SPI_AND = 1 << XT_HMARK_SPI_AND,
> +	XT_F_HMARK_SPI_OR = 1 << XT_HMARK_SPI_OR,
> +	XT_F_HMARK_SPORT_AND = 1 << XT_HMARK_SPORT_AND,
> +	XT_F_HMARK_DPORT_AND = 1 << XT_HMARK_DPORT_AND,
> +	XT_F_HMARK_SPORT_OR = 1 << XT_HMARK_SPORT_OR,
> +	XT_F_HMARK_DPORT_OR = 1 << XT_HMARK_DPORT_OR,
> +	XT_F_HMARK_PROTO_AND = 1 << XT_HMARK_PROTO_AND,
> +	XT_F_HMARK_RND = 1 << XT_HMARK_RND,
> +	XT_F_HMARK_MODULUS = 1 << XT_HMARK_MODULUS,
> +	XT_F_HMARK_OFFSET = 1 << XT_HMARK_OFFSET,
> +};
> +
> +union hports {
> +	struct {
> +		__u16	src;
> +		__u16	dst;
> +	} p16;
> +	__u32	v32;
> +};
> +
> +struct xt_hmark_info {
> +	union nf_inet_addr	smask;		/* Source address mask */
> +	union nf_inet_addr	dmask;		/* Dest address mask */
> +	union hports		pmask;
> +	union hports		pset;
> +	__u32			spimask;
> +	__u32			spiset;
> +	__u16			flags;		/* Print out only */
> +	__u16			prmask;		/* L4 Proto mask */
> +	__u32			hashrnd;
> +	__u32			hmod;		/* Modulus */
> +	__u32			hoffs;		/* Offset */
> +};
> +
> +#endif /* XT_HMARK_H_ */
> diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
> index f8ac4ef..dfe84e1 100644
> --- a/net/netfilter/Kconfig
> +++ b/net/netfilter/Kconfig
> @@ -488,6 +488,23 @@ config NETFILTER_XT_TARGET_HL
>  	since you can easily create immortal packets that loop
>  	forever on the network.
>  
> +config NETFILTER_XT_TARGET_HMARK
> +	tristate '"HMARK" target support'
> +	depends on NETFILTER_ADVANCED
> +	---help---
> +	This option adds the "HMARK" target.
> +
> +	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 behavior.
> +
> +	The mark match can also be used to match nfmark produced by this module.
> +
>  config NETFILTER_XT_TARGET_IDLETIMER
>  	tristate  "IDLETIMER target support"
>  	depends on NETFILTER_ADVANCED
> diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
> index 40f4c3d..21bc5e8 100644
> --- a/net/netfilter/Makefile
> +++ b/net/netfilter/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_CT) += xt_CT.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_DSCP) += xt_DSCP.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_HL) += xt_HL.o
> +obj-$(CONFIG_NETFILTER_XT_TARGET_HMARK) += xt_hmark.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_LED) += xt_LED.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_NFLOG) += xt_NFLOG.o
>  obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
> diff --git a/net/netfilter/xt_hmark.c b/net/netfilter/xt_hmark.c
> new file mode 100644
> index 0000000..fd73d15
> --- /dev/null
> +++ b/net/netfilter/xt_hmark.c
> @@ -0,0 +1,337 @@
> +/*
> + * xt_hmark - Netfilter module to set mark as hash value
> + *
> + * (C) 2011 Hans Schillstrom <hans.schillstrom@ericsson.com>
> + *
> + *Description:
> + *	This module calculates a hash value that can be modified by modulus
> + *	and an offset, i.e. it is possible to produce a skb->mark within a range.
> + *	The hash value is based on a direction independent five tuple:
> + *	src & dst addr src & dst ports and protocol.
> + *	However src & dst port can be masked and are not used for fragmented
> + *	packets, ESP and AH don't have ports so SPI will be used instead.
> + *	AH will not use ports even if it might be possible.
> + *	Tunnels - only the outer saddr and daddr will beused,
> + *
> + *	For ICMP error messages the hash mark values will be calculated on
> + *	the source packet i.e. the packet caused the error (If sufficient
> + *	amount of data exists).
> + *
> + *Note:	None of the fragments will include ports/spi in the calculation of
> + *	the hash value. (i.e. all frags must the same hash value.)
> + *
> + *	This program is free software; you can redistribute it and/or modify
> + *	it under the terms of the GNU General Public License version 2 as
> + *	published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/skbuff.h>
> +#include <net/ip.h>
> +#include <linux/icmp.h>
> +
> +#include <linux/netfilter/xt_hmark.h>
> +#include <linux/netfilter/x_tables.h>
> +#if defined(CONFIG_NF_NAT)
> +#include <net/netfilter/nf_nat.h>
> +#endif
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#	define WITH_IPV6 1
> +#include <net/ipv6.h>
> +#include <linux/netfilter_ipv6/ip6_tables.h>
> +#endif
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Hans Schillstrom <hans.schillstrom@ericsson.com>");
> +MODULE_DESCRIPTION("Xtables: packet range mark operations by hash value");
> +MODULE_ALIAS("ipt_HMARK");
> +MODULE_ALIAS("ip6t_HMARK");
> +
> +/*
> + * ICMP, get inner header so calc can be made on the source message
> + *
> + * iphsz: ip header size in bytes
> + * nhoff: network header offset
> + * return; updated nhoff if an icmp error
> + */

Please, remove these comments:

1) These functions are static, they provide no API for other users.
2) By reading the code, you can notice what it does. It's redundant.

> +static int get_inner_hdr(struct sk_buff *skb, int iphsz, int nhoff)
> +{
> +	const struct icmphdr *icmph;
> +	struct icmphdr _ih;
> +
> +	/* Not enough header? */
> +	icmph = skb_header_pointer(skb, nhoff + iphsz, sizeof(_ih), &_ih);
> +	if (icmph == NULL)
> +		return nhoff;
> +
> +	if (icmph->type > NR_ICMP_TYPES)
> +		return nhoff;
> +
> +	/* Error message? */
> +	if (icmph->type != ICMP_DEST_UNREACH &&
> +	    icmph->type != ICMP_SOURCE_QUENCH &&
> +	    icmph->type != ICMP_TIME_EXCEEDED &&
> +	    icmph->type != ICMP_PARAMETERPROB &&
> +	    icmph->type != ICMP_REDIRECT)
> +		return nhoff;
> +
> +	return nhoff + iphsz + sizeof(_ih);
> +}
> +
> +#ifdef WITH_IPV6
> +/* Dummy header used for size calculation of an error header */
> +struct _icmpv6_errh {
> +	__u8		icmp6_type;
> +	__u8		icmp6_code;
> +	__u16		icmp6_cksum;
> +	__u32		icmp6_nu;
> +};

Interesting, by quick search, I don't find this structure defined
elsewhere, why?

> +/*
> + * Get ipv6 header offset if icmp type < 128 i.e. an error.
> + * @param: offset  input: where ICMPv6 header starts
> + *                output: where ipv6 header starts / unchanged.
> + *
> + * Returns true if it's an icmp error
> + *              and updates *offset to where ipv6 header starts
> + */
> +static int get_inner6_hdr(struct sk_buff *skb, int *offset)
> +{
> +	struct icmp6hdr *icmp6h, _ih6;
> +
> +	icmp6h = skb_header_pointer(skb, *offset, sizeof(_ih6), &_ih6);
> +	if (icmp6h == NULL)
> +		return 0;
> +
> +	if (icmp6h->icmp6_type && icmp6h->icmp6_type < 128) {
> +		*offset +=  sizeof(struct _icmpv6_errh);
> +		return 1;
> +	}
> +	return 0;
> +}
> +/*
> + * Calculate hash based fw-mark, on the five tuple if possible.
> + * special cases :
> + *  - Fragments do not use ports not even on the first fragment,
> + *    nf_defrag_ipv6.ko don't defrag for us like it do in ipv4.
> + *    This might be changed in the future.
> + *  - On ICMP errors the inner header will be used.
> + *  - Tunnels no ports
> + *  - ESP & AH uses SPI
> + * @returns XT_CONTINUE
> + */
> +__u32 hmark_v6(struct sk_buff *skb, const struct xt_action_param *par)
> +{
> +	struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
> +	struct ipv6hdr *ip6, _ip6;
> +	int poff, flag = IP6T_FH_F_AUTH; /* Ports offset, find_hdr flags */
> +	u32 addr1, addr2, hash, nhoffs=0;
> +	u8 nexthdr;
> +	union hports uports = { .v32 = 0 };
> +	unsigned short fragoff = 0;
> +
> +	if (!info->hmod)
> +		return XT_CONTINUE;

why this? check in user-space that libxt_HMARK does not send this to
kernel-space and check it again in checkentry().

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-22 21:44   ` Pablo Neira Ayuso
@ 2012-01-22 23:20     ` Hans Schillstrom
  2012-01-23  9:12       ` Pablo Neira Ayuso
  0 siblings, 1 reply; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-22 23:20 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

[-- Attachment #1: Type: Text/Plain, Size: 15672 bytes --]

Hello Pablo

On Sunday, January 22, 2012 22:44:34 Pablo Neira Ayuso wrote:
> Hi Hans,
> 
> This starts looking good :-). Some comments on your patch:

Thanks

> 
> On Fri, Jan 13, 2012 at 10:52:17AM +0100, Hans Schillstrom wrote:
> >        Fragmentation:
> >         - If a packet is fragmented NONE of the Fragments will include
> >           ports in the hash calculation.
> >           When fragments arrives on different machines HMARK will produce
> >           same fwmark for all frags inpendent of machine so they can be routed
> >           to the same destination.
> 

The text should clarify that this is valid for the fragments not the "flow"

> I've got one scenario that may break with this assumption:
> 
> 1) your traffic follows one path over router A and B to reach your
>    firewall F which requires no fragmentation at all.
> 2) path to router B becomes broken while there are established flows
>    with firewall F.
> 3) router A decides to forward packets to router C, which fragment
>    packets because it is using smaller MTU than router A.
> 4) packets arrive to firewall F, then hashing is calculated based on
>    addresses, not ports, and you load-sharing becomes inconsistent.
> 
> This can rarely happen, but it does, it would break.
> 
> To fix this, I think that HMARK requires that you have to specify the
> hashing strategy. If you want to support fragments, use only
> addresses. If you're sure you will not get fragments, use layer 3 and
> layer 4 information.

I know but if you use conntrack, fragments will not be seen by HMARK
(except for IPv6 until Patric has fix the IPv6 defrag)

We handle this by not having stateful FW:s when connected to external routers.
Fragments will take an extra turn to a container with conntrack and there
HMARK works as on the unfragmented packets in the flow.

> 
> >         - If nf_defrag_ipv{4,6} is loaded the packets will be defragmented
> >           before reaching HMARK, i.e. in that case ports (if any) will be used.
> >           (ICMP Time exceeded will be sent if fragments are lost)
> > 
> >        Parameters: For all masks default is all "1:s", to disable a field
> >                    use mask 0. For IPv6 it's just the last 32 bits that
> >                    is included in the hash.
> > 
> >        --hmark-smask length (0-32 or 0-128)
> >               The value to AND the source address with (saddr & value).
> > 
> >        --hmark-dmask length (0-32 or 0-128)
> >               The value to AND the dest. address with (daddr & value).
> > 
> >        --hmark-sp-mask value
> >               A 16 bit value to AND the src port with (sport & value).
> > 
> >        --hmark-dp-mask value
> >               A 16 bit value to AND the dest port with (dport & value).
> > 
> >        --hmark-sp-set value
> >               A 16 bit value to OR the src port with (sport | value).
> > 
> >        --hmark-dp-set value
> >               A 16 bit value to OR the dest port with (dport | value).
> > 
> >        --hmark-spi-mask value
> >               Value to AND the spi field with (spi & value) valid for proto esp or ah.
> > 
> >        --hmark-spi-set value
> >               Value to OR the spi field with (spi | value) valid for proto esp or ah.
> > 
> >        --hmark-proto-mask value
> >               A 16 bit value to AND the L4 proto field with (proto & value).
> > 
> >        --hmark-rnd value
> >               A 32 bit intitial value for hash calc, default is 0xc175a3b8.
> > 
> >        --hmark-dnat (only IPv4)
> >               Replace src addr/port with original dst addr/port before calc, hash
> > 
> >        --hmark-snat (only IPv4)
> >               Replace dst addr/port with original src addr/port before calc, hash
> > 
> >        Final processing of the mark in order of execution.
> > 
> >        --hmark-mod value (must be > 0)
> >               The easiest way to describe this is:  hash = hash mod <value>
> > 
> >        --hmark-offs alue (must be > 0)
> >               The easiest way to describe this is:  hash = hash + <value>
> > 
> >        Examples:
> > 
> >        Default rule handles all TCP, UDP, SCTP, ESP & AH
> > 
> > Rev 7
> >       IPv6 descending into icmp error hdr didn't work as expected
> >       with ipv6_find_hdr() Now it works as expected.
> > 
> > Rev 6
> >       Compile options with or without conntrack fixed.
> >       __ipv6_find_hdr() replaced by ipv6_find_hdr()
> > 
> > Rev 5
> >       IPv6 rewritten uses __ipv6_find_hdr() (P. Mc Hardy)
> >       Full mask and address used for IPv6 smask and dmask (J.Engelhart)
> >       Changes due to comments by Pablo Neira Ayuso  and Eric Dumazet
> >       i.e uses of skb_header_pointer() and Null check of info->hmod
> >       Man page changes
> > 
> > Rev 4
> >       different targets for IPv4 and IPv6
> >       Changes based on review by Pablo.
> > 
> > Rev 3
> >       Support added to SCTP for IPv6
> > Rev 2
> >       IPv6 header scan changed to follow RFC 2640
> >       IPv4 icmp echo fragmented does now use proto as ipv6
> >       IPv6 pskb_may_pull() check is done in every time in header loop.
> >       IPv4 nat support added.
> >       default added in IPv6 loop and null check of hp
> > 
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> > ---
> >  include/linux/netfilter/xt_hmark.h |   62 +++++++
> >  net/netfilter/Kconfig              |   17 ++
> >  net/netfilter/Makefile             |    1 +
> >  net/netfilter/xt_hmark.c           |  337 ++++++++++++++++++++++++++++++++++++
> >  4 files changed, 417 insertions(+), 0 deletions(-)
> >  create mode 100644 include/linux/netfilter/xt_hmark.h
> >  create mode 100644 net/netfilter/xt_hmark.c
> > 
> > diff --git a/include/linux/netfilter/xt_hmark.h b/include/linux/netfilter/xt_hmark.h
> > new file mode 100644
> > index 0000000..366ecce
> > --- /dev/null
> > +++ b/include/linux/netfilter/xt_hmark.h
> > @@ -0,0 +1,62 @@
> > +#ifndef XT_HMARK_H_
> > +#define XT_HMARK_H_
> > +
> > +#include <linux/types.h>
> > +
> > +/*
> > + * Flags must not start at 0, since it's used as none.
> > + */
> > +enum {
> > +	XT_HMARK_SADR_AND = 1,	/* SNAT & DNAT are used by the kernel module */
> > +	XT_HMARK_DADR_AND,
> > +	XT_HMARK_SPI_AND,
> > +	XT_HMARK_SPI_OR,
> > +	XT_HMARK_SPORT_AND,
> > +	XT_HMARK_DPORT_AND,
> > +	XT_HMARK_SPORT_OR,
> > +	XT_HMARK_DPORT_OR,
> > +	XT_HMARK_PROTO_AND,
> > +	XT_HMARK_RND,
> > +	XT_HMARK_MODULUS,
> > +	XT_HMARK_OFFSET,
> > +	XT_HMARK_USE_SNAT,
> > +	XT_HMARK_USE_DNAT,
> > +	XT_F_HMARK_USE_SNAT = 1 << XT_HMARK_USE_SNAT,
> > +	XT_F_HMARK_USE_DNAT = 1 << XT_HMARK_USE_DNAT,
> > +	XT_F_HMARK_SADR_AND = 1 << XT_HMARK_SADR_AND,
> > +	XT_F_HMARK_DADR_AND = 1 << XT_HMARK_DADR_AND,
> > +	XT_F_HMARK_SPI_AND = 1 << XT_HMARK_SPI_AND,
> > +	XT_F_HMARK_SPI_OR = 1 << XT_HMARK_SPI_OR,
> > +	XT_F_HMARK_SPORT_AND = 1 << XT_HMARK_SPORT_AND,
> > +	XT_F_HMARK_DPORT_AND = 1 << XT_HMARK_DPORT_AND,
> > +	XT_F_HMARK_SPORT_OR = 1 << XT_HMARK_SPORT_OR,
> > +	XT_F_HMARK_DPORT_OR = 1 << XT_HMARK_DPORT_OR,
> > +	XT_F_HMARK_PROTO_AND = 1 << XT_HMARK_PROTO_AND,
> > +	XT_F_HMARK_RND = 1 << XT_HMARK_RND,
> > +	XT_F_HMARK_MODULUS = 1 << XT_HMARK_MODULUS,
> > +	XT_F_HMARK_OFFSET = 1 << XT_HMARK_OFFSET,
> > +};
> > +
> > +union hports {
> > +	struct {
> > +		__u16	src;
> > +		__u16	dst;
> > +	} p16;
> > +	__u32	v32;
> > +};
> > +
> > +struct xt_hmark_info {
> > +	union nf_inet_addr	smask;		/* Source address mask */
> > +	union nf_inet_addr	dmask;		/* Dest address mask */
> > +	union hports		pmask;
> > +	union hports		pset;
> > +	__u32			spimask;
> > +	__u32			spiset;
> > +	__u16			flags;		/* Print out only */
> > +	__u16			prmask;		/* L4 Proto mask */
> > +	__u32			hashrnd;
> > +	__u32			hmod;		/* Modulus */
> > +	__u32			hoffs;		/* Offset */
> > +};
> > +
> > +#endif /* XT_HMARK_H_ */
> > diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
> > index f8ac4ef..dfe84e1 100644
> > --- a/net/netfilter/Kconfig
> > +++ b/net/netfilter/Kconfig
> > @@ -488,6 +488,23 @@ config NETFILTER_XT_TARGET_HL
> >  	since you can easily create immortal packets that loop
> >  	forever on the network.
> >  
> > +config NETFILTER_XT_TARGET_HMARK
> > +	tristate '"HMARK" target support'
> > +	depends on NETFILTER_ADVANCED
> > +	---help---
> > +	This option adds the "HMARK" target.
> > +
> > +	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 behavior.
> > +
> > +	The mark match can also be used to match nfmark produced by this module.
> > +
> >  config NETFILTER_XT_TARGET_IDLETIMER
> >  	tristate  "IDLETIMER target support"
> >  	depends on NETFILTER_ADVANCED
> > diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
> > index 40f4c3d..21bc5e8 100644
> > --- a/net/netfilter/Makefile
> > +++ b/net/netfilter/Makefile
> > @@ -57,6 +57,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_CT) += xt_CT.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_DSCP) += xt_DSCP.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_HL) += xt_HL.o
> > +obj-$(CONFIG_NETFILTER_XT_TARGET_HMARK) += xt_hmark.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_LED) += xt_LED.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_NFLOG) += xt_NFLOG.o
> >  obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
> > diff --git a/net/netfilter/xt_hmark.c b/net/netfilter/xt_hmark.c
> > new file mode 100644
> > index 0000000..fd73d15
> > --- /dev/null
> > +++ b/net/netfilter/xt_hmark.c
> > @@ -0,0 +1,337 @@
> > +/*
> > + * xt_hmark - Netfilter module to set mark as hash value
> > + *
> > + * (C) 2011 Hans Schillstrom <hans.schillstrom@ericsson.com>
> > + *
> > + *Description:
> > + *	This module calculates a hash value that can be modified by modulus
> > + *	and an offset, i.e. it is possible to produce a skb->mark within a range.
> > + *	The hash value is based on a direction independent five tuple:
> > + *	src & dst addr src & dst ports and protocol.
> > + *	However src & dst port can be masked and are not used for fragmented
> > + *	packets, ESP and AH don't have ports so SPI will be used instead.
> > + *	AH will not use ports even if it might be possible.
> > + *	Tunnels - only the outer saddr and daddr will beused,
> > + *
> > + *	For ICMP error messages the hash mark values will be calculated on
> > + *	the source packet i.e. the packet caused the error (If sufficient
> > + *	amount of data exists).
> > + *
> > + *Note:	None of the fragments will include ports/spi in the calculation of
> > + *	the hash value. (i.e. all frags must the same hash value.)
> > + *
> > + *	This program is free software; you can redistribute it and/or modify
> > + *	it under the terms of the GNU General Public License version 2 as
> > + *	published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/skbuff.h>
> > +#include <net/ip.h>
> > +#include <linux/icmp.h>
> > +
> > +#include <linux/netfilter/xt_hmark.h>
> > +#include <linux/netfilter/x_tables.h>
> > +#if defined(CONFIG_NF_NAT)
> > +#include <net/netfilter/nf_nat.h>
> > +#endif
> > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> > +#	define WITH_IPV6 1
> > +#include <net/ipv6.h>
> > +#include <linux/netfilter_ipv6/ip6_tables.h>
> > +#endif
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Hans Schillstrom <hans.schillstrom@ericsson.com>");
> > +MODULE_DESCRIPTION("Xtables: packet range mark operations by hash value");
> > +MODULE_ALIAS("ipt_HMARK");
> > +MODULE_ALIAS("ip6t_HMARK");
> > +
> > +/*
> > + * ICMP, get inner header so calc can be made on the source message
> > + *
> > + * iphsz: ip header size in bytes
> > + * nhoff: network header offset
> > + * return; updated nhoff if an icmp error
> > + */
> 
> Please, remove these comments:

No problems

> 
> 1) These functions are static, they provide no API for other users.
> 2) By reading the code, you can notice what it does. It's redundant.
> 
> > +static int get_inner_hdr(struct sk_buff *skb, int iphsz, int nhoff)
> > +{
> > +	const struct icmphdr *icmph;
> > +	struct icmphdr _ih;
> > +
> > +	/* Not enough header? */
> > +	icmph = skb_header_pointer(skb, nhoff + iphsz, sizeof(_ih), &_ih);
> > +	if (icmph == NULL)
> > +		return nhoff;
> > +
> > +	if (icmph->type > NR_ICMP_TYPES)
> > +		return nhoff;
> > +
> > +	/* Error message? */
> > +	if (icmph->type != ICMP_DEST_UNREACH &&
> > +	    icmph->type != ICMP_SOURCE_QUENCH &&
> > +	    icmph->type != ICMP_TIME_EXCEEDED &&
> > +	    icmph->type != ICMP_PARAMETERPROB &&
> > +	    icmph->type != ICMP_REDIRECT)
> > +		return nhoff;
> > +
> > +	return nhoff + iphsz + sizeof(_ih);
> > +}
> > +
> > +#ifdef WITH_IPV6
> > +/* Dummy header used for size calculation of an error header */
> > +struct _icmpv6_errh {
> > +	__u8		icmp6_type;
> > +	__u8		icmp6_code;
> > +	__u16		icmp6_cksum;
> > +	__u32		icmp6_nu;
> > +};
> 
> Interesting, by quick search, I don't find this structure defined
> elsewhere, why?
> 
I have no idea ...
the closest is "struct icmp6hdr" but it contains everything

> > +/*
> > + * Get ipv6 header offset if icmp type < 128 i.e. an error.
> > + * @param: offset  input: where ICMPv6 header starts
> > + *                output: where ipv6 header starts / unchanged.
> > + *
> > + * Returns true if it's an icmp error
> > + *              and updates *offset to where ipv6 header starts
> > + */
> > +static int get_inner6_hdr(struct sk_buff *skb, int *offset)
> > +{
> > +	struct icmp6hdr *icmp6h, _ih6;
> > +
> > +	icmp6h = skb_header_pointer(skb, *offset, sizeof(_ih6), &_ih6);
> > +	if (icmp6h == NULL)
> > +		return 0;
> > +
> > +	if (icmp6h->icmp6_type && icmp6h->icmp6_type < 128) {
> > +		*offset +=  sizeof(struct _icmpv6_errh);
> > +		return 1;
> > +	}
> > +	return 0;
> > +}
> > +/*
> > + * Calculate hash based fw-mark, on the five tuple if possible.
> > + * special cases :
> > + *  - Fragments do not use ports not even on the first fragment,
> > + *    nf_defrag_ipv6.ko don't defrag for us like it do in ipv4.
> > + *    This might be changed in the future.
> > + *  - On ICMP errors the inner header will be used.
> > + *  - Tunnels no ports
> > + *  - ESP & AH uses SPI
> > + * @returns XT_CONTINUE
> > + */
> > +__u32 hmark_v6(struct sk_buff *skb, const struct xt_action_param *par)
> > +{
> > +	struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
> > +	struct ipv6hdr *ip6, _ip6;
> > +	int poff, flag = IP6T_FH_F_AUTH; /* Ports offset, find_hdr flags */
> > +	u32 addr1, addr2, hash, nhoffs=0;
> > +	u8 nexthdr;
> > +	union hports uports = { .v32 = 0 };
> > +	unsigned short fragoff = 0;
> > +
> > +	if (!info->hmod)
> > +		return XT_CONTINUE;
> 
> why this? check in user-space that libxt_HMARK does not send this to
> kernel-space and check it again in checkentry().

Well, better safe than ... divide by zero

OK, it very very unlikely that it becomes zero
so if you want I can remove that check.

Thanks
/Hans

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-22 23:20     ` Hans Schillstrom
@ 2012-01-23  9:12       ` Pablo Neira Ayuso
  2012-01-23  9:49         ` Hans Schillstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Pablo Neira Ayuso @ 2012-01-23  9:12 UTC (permalink / raw)
  To: Hans Schillstrom
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> The text should clarify that this is valid for the fragments not the "flow"
> 
> > I've got one scenario that may break with this assumption:
> > 
> > 1) your traffic follows one path over router A and B to reach your
> >    firewall F which requires no fragmentation at all.
> > 2) path to router B becomes broken while there are established flows
> >    with firewall F.
> > 3) router A decides to forward packets to router C, which fragment
> >    packets because it is using smaller MTU than router A.
> > 4) packets arrive to firewall F, then hashing is calculated based on
> >    addresses, not ports, and you load-sharing becomes inconsistent.
> > 
> > This can rarely happen, but it does, it would break.
> > 
> > To fix this, I think that HMARK requires that you have to specify the
> > hashing strategy. If you want to support fragments, use only
> > addresses. If you're sure you will not get fragments, use layer 3 and
> > layer 4 information.
> 
> I know but if you use conntrack, fragments will not be seen by HMARK
> (except for IPv6 until Patric has fix the IPv6 defrag)

Please, read the scenario, I'm not talking about conntrack this time.

> We handle this by not having stateful FW:s when connected to external routers.
> Fragments will take an extra turn to a container with conntrack and there
> HMARK works as on the unfragmented packets in the flow.

Yes, I got the idea. Indeed HMARK can be very useful in other situations,
like cluster-based OSPF setups with stateful firewalls following a
similar approach.

However, you don't reply to my scenario. What I'm telling is that,
even with conntrack disabled, HMARK is not consistent if you start
receiving fragments at some point.

[...]
> > > +/*
> > > + * ICMP, get inner header so calc can be made on the source message
> > > + *
> > > + * iphsz: ip header size in bytes
> > > + * nhoff: network header offset
> > > + * return; updated nhoff if an icmp error
> > > + */
> > 
> > Please, remove these comments:
> 
> No problems

Thanks.

> > > +struct _icmpv6_errh {
> > > +	__u8		icmp6_type;
> > > +	__u8		icmp6_code;
> > > +	__u16		icmp6_cksum;
> > > +	__u32		icmp6_nu;
> > > +};
> > 
> > Interesting, by quick search, I don't find this structure defined
> > elsewhere, why?
> > 
> I have no idea ...
> the closest is "struct icmp6hdr" but it contains everythingi

have a look at offsetof, you can use the existing structure but tell
skb_copy_header to copy only the part you're interested. Add a comment
telling what you're only copying part of the header to warn others (in
this case, the comment becomes useful since it clarifies something
that you may not notice at a first glance by looking at the code).

[...]
> > > +	if (!info->hmod)
> > > +		return XT_CONTINUE;
> > 
> > why this? check in user-space that libxt_HMARK does not send this to
> > kernel-space and check it again in checkentry().
> 
> Well, better safe than ... divide by zero
> 
> OK, it very very unlikely that it becomes zero
> so if you want I can remove that check.

*Extremely unlikely*, I'd say :-). If you double check that hmod is
non-zero in user-space and checkentry(), we will not hit that branch
ever. Moreover, that branch is in the hot path while the others are
only configure-time paths.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-23  9:12       ` Pablo Neira Ayuso
@ 2012-01-23  9:49         ` Hans Schillstrom
  2012-01-23 17:01           ` Pablo Neira Ayuso
  0 siblings, 1 reply; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-23  9:49 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

On Monday 23 January 2012 10:12:41 Pablo Neira Ayuso wrote:
> On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> > The text should clarify that this is valid for the fragments not the "flow"
> > 
> > > I've got one scenario that may break with this assumption:
> > > 
> > > 1) your traffic follows one path over router A and B to reach your
> > >    firewall F which requires no fragmentation at all.

I missed the last part here  "requires no fragmentation at all"

> > > 2) path to router B becomes broken while there are established flows
> > >    with firewall F.
> > > 3) router A decides to forward packets to router C, which fragment
> > >    packets because it is using smaller MTU than router A.
> > > 4) packets arrive to firewall F, then hashing is calculated based on
> > >    addresses, not ports, and you load-sharing becomes inconsistent.
> > > 
> > > This can rarely happen, but it does, it would break.
> > > 
> > > To fix this, I think that HMARK requires that you have to specify the
> > > hashing strategy. If you want to support fragments, use only
> > > addresses. If you're sure you will not get fragments, use layer 3 and
> > > layer 4 information.

This can be acomplished by setting --hmark-sp-mask and --hmark-dp-mask to Zero
Then you don't use port in the hash calc.

> > 
> > I know but if you use conntrack, fragments will not be seen by HMARK
> > (except for IPv6 until Patric has fix the IPv6 defrag)
> 
> Please, read the scenario, I'm not talking about conntrack this time.
> 
> > We handle this by not having stateful FW:s when connected to external routers.
> > Fragments will take an extra turn to a container with conntrack and there
> > HMARK works as on the unfragmented packets in the flow.
> 
> Yes, I got the idea. Indeed HMARK can be very useful in other situations,
> like cluster-based OSPF setups with stateful firewalls following a
> similar approach.
> 
> However, you don't reply to my scenario. What I'm telling is that,
> even with conntrack disabled, HMARK is not consistent if you start
> receiving fragments at some point.
 
Yes, after reading once again I see what you mean.
I think that masking src & dst ports will be sufficient, 
i.e. no new param will be needed for hashing strategy.

> [...]
> > > > +/*
> > > > + * ICMP, get inner header so calc can be made on the source message
> > > > + *
> > > > + * iphsz: ip header size in bytes
> > > > + * nhoff: network header offset
> > > > + * return; updated nhoff if an icmp error
> > > > + */
> > > 
> > > Please, remove these comments:
> > 
> > No problems
> 
> Thanks.
> 
> > > > +struct _icmpv6_errh {
> > > > +	__u8		icmp6_type;
> > > > +	__u8		icmp6_code;
> > > > +	__u16		icmp6_cksum;
> > > > +	__u32		icmp6_nu;
> > > > +};
> > > 
> > > Interesting, by quick search, I don't find this structure defined
> > > elsewhere, why?
> > > 
> > I have no idea ...
> > the closest is "struct icmp6hdr" but it contains everythingi
> 
> have a look at offsetof, you can use the existing structure but tell
> skb_copy_header to copy only the part you're interested. Add a comment
> telling what you're only copying part of the header to warn others (in
> this case, the comment becomes useful since it clarifies something
> that you may not notice at a first glance by looking at the code).
> 

OK I'll do that.

> [...]
> > > > +	if (!info->hmod)
> > > > +		return XT_CONTINUE;
> > > 
> > > why this? check in user-space that libxt_HMARK does not send this to
> > > kernel-space and check it again in checkentry().
> > 
> > Well, better safe than ... divide by zero
> > 
> > OK, it very very unlikely that it becomes zero
> > so if you want I can remove that check.
> 
> *Extremely unlikely*, I'd say :-). If you double check that hmod is
> non-zero in user-space and checkentry(), we will not hit that branch
> ever. Moreover, that branch is in the hot path while the others are
> only configure-time paths.

Got the message :-)
I'll remove it.

-- 
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-23  9:49         ` Hans Schillstrom
@ 2012-01-23 17:01           ` Pablo Neira Ayuso
  2012-01-24 17:56             ` Hans Schillstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Pablo Neira Ayuso @ 2012-01-23 17:01 UTC (permalink / raw)
  To: Hans Schillstrom
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

Hi Hans,

On Mon, Jan 23, 2012 at 10:49:16AM +0100, Hans Schillstrom wrote:
> On Monday 23 January 2012 10:12:41 Pablo Neira Ayuso wrote:
> > On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> > > The text should clarify that this is valid for the fragments not the "flow"
> > > 
> > > > I've got one scenario that may break with this assumption:
> > > > 
> > > > 1) your traffic follows one path over router A and B to reach your
> > > >    firewall F which requires no fragmentation at all.
> 
> I missed the last part here  "requires no fragmentation at all"
> 
> > > > 2) path to router B becomes broken while there are established flows
> > > >    with firewall F.
> > > > 3) router A decides to forward packets to router C, which fragment
> > > >    packets because it is using smaller MTU than router A.
> > > > 4) packets arrive to firewall F, then hashing is calculated based on
> > > >    addresses, not ports, and you load-sharing becomes inconsistent.
> > > > 
> > > > This can rarely happen, but it does, it would break.
> > > > 
> > > > To fix this, I think that HMARK requires that you have to specify the
> > > > hashing strategy. If you want to support fragments, use only
> > > > addresses. If you're sure you will not get fragments, use layer 3 and
> > > > layer 4 information.
> 
> This can be acomplished by setting --hmark-sp-mask and --hmark-dp-mask to Zero
> Then you don't use port in the hash calc.

OK, it would be great if we can provide a cleaner interface. The
current behaviour uses layer3-layer4 tuple hashing plus defaulting to
layer3 in case of fragments.

I'd prefer explicit configuration options:

--hashmark-method layer3
        use only address for hashing, this is fragment safe.

--hashmark-method layer3-layer4
        use addresses and ports for hashing, fragments not supported
        unless defrag is enabled.

Still, if you want to support the current behaviour, it should be
something like:

--hashmark-method layer3-layer4-fragments
        use addresses and ports for hashing, for fragments default to
        layer3 hashing. Document scenario in which hash consistency
        may break.

The behaviour of the target has to be specified by the configurations.
Defaulting to internal assumptions seems obscure to me.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-23 17:01           ` Pablo Neira Ayuso
@ 2012-01-24 17:56             ` Hans Schillstrom
  2012-01-24 18:15               ` Pablo Neira Ayuso
  0 siblings, 1 reply; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-24 17:56 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

On Monday 23 January 2012 18:01:50 Pablo Neira Ayuso wrote:
> Hi Hans,
> 
> On Mon, Jan 23, 2012 at 10:49:16AM +0100, Hans Schillstrom wrote:
> > On Monday 23 January 2012 10:12:41 Pablo Neira Ayuso wrote:
> > > On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> > > > The text should clarify that this is valid for the fragments not the "flow"
> > > > 
> > > > > I've got one scenario that may break with this assumption:
> > > > > 
> > > > > 1) your traffic follows one path over router A and B to reach your
> > > > >    firewall F which requires no fragmentation at all.
> > 
> > I missed the last part here  "requires no fragmentation at all"
> > 
> > > > > 2) path to router B becomes broken while there are established flows
> > > > >    with firewall F.
> > > > > 3) router A decides to forward packets to router C, which fragment
> > > > >    packets because it is using smaller MTU than router A.
> > > > > 4) packets arrive to firewall F, then hashing is calculated based on
> > > > >    addresses, not ports, and you load-sharing becomes inconsistent.
> > > > > 
> > > > > This can rarely happen, but it does, it would break.
> > > > > 
> > > > > To fix this, I think that HMARK requires that you have to specify the
> > > > > hashing strategy. If you want to support fragments, use only
> > > > > addresses. If you're sure you will not get fragments, use layer 3 and
> > > > > layer 4 information.
> > 
> > This can be acomplished by setting --hmark-sp-mask and --hmark-dp-mask to Zero
> > Then you don't use port in the hash calc.
> 
> OK, it would be great if we can provide a cleaner interface. The
> current behaviour uses layer3-layer4 tuple hashing plus defaulting to
> layer3 in case of fragments.
> 
> I'd prefer explicit configuration options:
> 
> --hashmark-method layer3
>         use only address for hashing, this is fragment safe.
> 
> --hashmark-method layer3-layer4
>         use addresses and ports for hashing, fragments not supported
>         unless defrag is enabled.
> 
> Still, if you want to support the current behaviour, it should be
> something like:
> 
> --hashmark-method layer3-layer4-fragments
>         use addresses and ports for hashing, for fragments default to
>         layer3 hashing. Document scenario in which hash consistency
>         may break.
> 
> The behaviour of the target has to be specified by the configurations.
> Defaulting to internal assumptions seems obscure to me.
> 
OK this is resonable, and it makes the fragment problem visible.

I'll make the changes to day and have a test run for a couple of days.
or should I wait ?

Tanks
Hans 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-24 17:56             ` Hans Schillstrom
@ 2012-01-24 18:15               ` Pablo Neira Ayuso
  2012-01-25 10:14                 ` Hans Schillstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Pablo Neira Ayuso @ 2012-01-24 18:15 UTC (permalink / raw)
  To: Hans Schillstrom
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

On Tue, Jan 24, 2012 at 06:56:10PM +0100, Hans Schillstrom wrote:
> On Monday 23 January 2012 18:01:50 Pablo Neira Ayuso wrote:
> > Hi Hans,
> > 
> > On Mon, Jan 23, 2012 at 10:49:16AM +0100, Hans Schillstrom wrote:
> > > On Monday 23 January 2012 10:12:41 Pablo Neira Ayuso wrote:
> > > > On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> > > > > The text should clarify that this is valid for the fragments not the "flow"
> > > > > 
> > > > > > I've got one scenario that may break with this assumption:
> > > > > > 
> > > > > > 1) your traffic follows one path over router A and B to reach your
> > > > > >    firewall F which requires no fragmentation at all.
> > > 
> > > I missed the last part here  "requires no fragmentation at all"
> > > 
> > > > > > 2) path to router B becomes broken while there are established flows
> > > > > >    with firewall F.
> > > > > > 3) router A decides to forward packets to router C, which fragment
> > > > > >    packets because it is using smaller MTU than router A.
> > > > > > 4) packets arrive to firewall F, then hashing is calculated based on
> > > > > >    addresses, not ports, and you load-sharing becomes inconsistent.
> > > > > > 
> > > > > > This can rarely happen, but it does, it would break.
> > > > > > 
> > > > > > To fix this, I think that HMARK requires that you have to specify the
> > > > > > hashing strategy. If you want to support fragments, use only
> > > > > > addresses. If you're sure you will not get fragments, use layer 3 and
> > > > > > layer 4 information.
> > > 
> > > This can be acomplished by setting --hmark-sp-mask and --hmark-dp-mask to Zero
> > > Then you don't use port in the hash calc.
> > 
> > OK, it would be great if we can provide a cleaner interface. The
> > current behaviour uses layer3-layer4 tuple hashing plus defaulting to
> > layer3 in case of fragments.
> > 
> > I'd prefer explicit configuration options:
> > 
> > --hashmark-method layer3
> >         use only address for hashing, this is fragment safe.
> > 
> > --hashmark-method layer3-layer4
> >         use addresses and ports for hashing, fragments not supported
> >         unless defrag is enabled.
> > 
> > Still, if you want to support the current behaviour, it should be
> > something like:
> > 
> > --hashmark-method layer3-layer4-fragments
> >         use addresses and ports for hashing, for fragments default to
> >         layer3 hashing. Document scenario in which hash consistency
> >         may break.
> > 
> > The behaviour of the target has to be specified by the configurations.
> > Defaulting to internal assumptions seems obscure to me.
> > 
> OK this is resonable, and it makes the fragment problem visible.
> 
> I'll make the changes to day and have a test run for a couple of days.

Fine, thanks Hans.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-24 18:15               ` Pablo Neira Ayuso
@ 2012-01-25 10:14                 ` Hans Schillstrom
  2012-01-25 11:49                   ` Pablo Neira Ayuso
  0 siblings, 1 reply; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-25 10:14 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

On Tuesday 24 January 2012 19:15:40 Pablo Neira Ayuso wrote:
> On Tue, Jan 24, 2012 at 06:56:10PM +0100, Hans Schillstrom wrote:
> > On Monday 23 January 2012 18:01:50 Pablo Neira Ayuso wrote:
> > > Hi Hans,
> > > 
> > > On Mon, Jan 23, 2012 at 10:49:16AM +0100, Hans Schillstrom wrote:
> > > > On Monday 23 January 2012 10:12:41 Pablo Neira Ayuso wrote:
> > > > > On Mon, Jan 23, 2012 at 12:20:15AM +0100, Hans Schillstrom wrote:
> > > > > > The text should clarify that this is valid for the fragments not the "flow"
> > > > > > 
> > > > > > > I've got one scenario that may break with this assumption:
> > > > > > > 
> > > > > > > 1) your traffic follows one path over router A and B to reach your
> > > > > > >    firewall F which requires no fragmentation at all.
> > > > 
> > > > I missed the last part here  "requires no fragmentation at all"
> > > > 
> > > > > > > 2) path to router B becomes broken while there are established flows
> > > > > > >    with firewall F.
> > > > > > > 3) router A decides to forward packets to router C, which fragment
> > > > > > >    packets because it is using smaller MTU than router A.
> > > > > > > 4) packets arrive to firewall F, then hashing is calculated based on
> > > > > > >    addresses, not ports, and you load-sharing becomes inconsistent.
> > > > > > > 
> > > > > > > This can rarely happen, but it does, it would break.
> > > > > > > 
> > > > > > > To fix this, I think that HMARK requires that you have to specify the
> > > > > > > hashing strategy. If you want to support fragments, use only
> > > > > > > addresses. If you're sure you will not get fragments, use layer 3 and
> > > > > > > layer 4 information.
> > > > 
> > > > This can be acomplished by setting --hmark-sp-mask and --hmark-dp-mask to Zero
> > > > Then you don't use port in the hash calc.
> > > 
> > > OK, it would be great if we can provide a cleaner interface. The
> > > current behaviour uses layer3-layer4 tuple hashing plus defaulting to
> > > layer3 in case of fragments.
> > > 
> > > I'd prefer explicit configuration options:
> > > 
> > > --hashmark-method layer3
> > >         use only address for hashing, this is fragment safe.
> > > 
> > > --hashmark-method layer3-layer4
> > >         use addresses and ports for hashing, fragments not supported
> > >         unless defrag is enabled.
> > > 
> > > Still, if you want to support the current behaviour, it should be
> > > something like:
> > > 

We skip this option, 
fragments can be catched by iptables rules and feeded to a HMARK rule
with --hmark-method L3 option
It's more clear.

> > > --hashmark-method layer3-layer4-fragments
> > >         use addresses and ports for hashing, for fragments default to
> > >         layer3 hashing. Document scenario in which hash consistency
> > >         may break.
> > > 
> > > The behaviour of the target has to be specified by the configurations.
> > > Defaulting to internal assumptions seems obscure to me.
> > > 
> > OK this is resonable, and it makes the fragment problem visible.
> > 
> > I'll make the changes to day and have a test run for a couple of days.
> 
> Fine, thanks Hans.

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.
  Limit/modify the calculated hash mark by:
  --hmark-mod value                  nfmark modulus value
  --hmark-offs value                 Last action add value to nfmark

 Fine tuning of what will be included in hash calculation
  --hmark-smask length               Source address mask length
  --hmark-dmask length               Dest address mask length
  --hmark-sp-mask value              Mask src port with value
  --hmark-dp-mask value              Mask dst port with value
  --hmark-spi-mask value             For esp and ah AND spi with value
  --hmark-sp-set value               OR src port with value
  --hmark-dp-set value               OR dst port with value
  --hmark-spi-set value              For esp and ah OR spi with value
  --hmark-proto-mask value           Mask Protocol with value
  --hmark-rnd                        Initial Random value to hash cacl.
 For NAT in IPv4 the original address can be used in the return path.
 Make sure to qualify the statement in a proper way when using nat flags
  --hmark-dnat                       Replace src addr with original dst addr
  --hmark-snat                       Replace dst addr with original src addr
 In many cases hmark can be omitted i.e. --smask can be used


MAN PAGE

   HMARK
       This module does the same as MARK, i.e. set an fwmark, but the mark is based on a hash value.
       The hash is based on saddr, daddr, sport, dport and proto. The same mark will be produced independent 
       of direction if no masks is set or the same masks is used for src and dest.
       The hash mark could be adjusted by modulus and finally an offset could be added, i.e the final mark will
       be within a range.  ICMP error will use the the original message for hash calculation not the icmp it self.

       Note: None of the parameters effect the packet it self only the calculated hash value.
             IPv4 packets with nf_defrag_ipv4 loaded will be defragmented before they reach hmark,
             IPv6 nf_defrag is not implemented this way, hence fragmented ipv6 packets will reach hmark.
             Default behavior is to completely ignore any fragment if it reach hmark.
             --hmark-method L3 is fragment safe since neither ports or L4 protocol is used.
             

       Parameters: Short hand methods

       --hmark-method L3
              Do not use proto, ports or spi, only Layer 3 addresses, mask length of L3 addresses can still be used.  
              Fragment or not does not matter in this case since only L3 address can be used in calc. of hash value.

       --hmark-method L3-4
              Default method, Include L4 in calc. of hash value i.e. all masks below are valid.
              Fragments will be ignored. (i.e no hash value produced)

       For all masks default is all "1:s", to disable a field use mask 0 

       --hmark-smask length
              The length of the mask to AND the source address with (saddr & value).

       --hmark-dmask length
              The length of the mask to AND the dest. address with (daddr & value).

       --hmark-sp-mask value
              A 16 bit value to AND the src port with (sport & value).

       --hmark-dp-mask value
              A 16 bit value to AND the dest port with (dport & value).

       --hmark-sp-set value
              A 16 bit value to OR the src port with (sport | value).

       --hmark-dp-set value
              A 16 bit value to OR the dest port with (dport | value).

       --hmark-spi-mask value
              Value to AND the spi field with (spi & value) valid for proto esp or ah.

       --hmark-spi-set value
              Value to OR the spi field with (spi | value) valid for proto esp or ah.

       --hmark-proto-mask value
              An 8 bit value to AND the L4 proto field with (proto & value).

       --hmark-rnd value
              A 32 bit initial value for hash calc, default is 0xc175a3b8.

       Final processing of the mark in order of execution.

       --hmark-mod value (must be > 0)
              The easiest way to describe this is:  hash = hash mod <value>

       --hmark-offs value
              The easiest way to describe this is:  hash = hash + <value>

       Examples:

       Default rule handles all TCP, UDP, SCTP, ESP & AH

              iptables -t mangle -A PREROUTING -j HMARK --hmark-offs 10000 --hmark-mod 10

       Handle SCTP and hash dest port only and produce a nfmark between 100-119.

              iptables -t mangle -A PREROUTING -p SCTP -j HMARK --smask 0 --dmask 0 \
               --sp-mask 0 --offs 100 --mod 20

       No defragment by conntrack, None Fragments will have fwmark 100-119 
       Fragments will have fwmark 120-139 (based on saddr and daddr only)

              iptables -t mangle -A PREROUTING -j HMARK --method L3-4 --mod 20 --offs 100
              iptables -t mangle -A PRROUTING -m mark --mark 0 -j HMARK --method L3 --mod 20 --offs 120

       Fragment safe Layer 3 only that keep a class C netw together

              iptables -t mangle -A PREROUTING -j HMARK --method L3 --smask 24 --mod 20 --offs 100


-- 
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-25 10:14                 ` Hans Schillstrom
@ 2012-01-25 11:49                   ` Pablo Neira Ayuso
  2012-01-25 12:28                     ` Hans Schillstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Pablo Neira Ayuso @ 2012-01-25 11:49 UTC (permalink / raw)
  To: Hans Schillstrom
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
  2012-01-25 11:49                   ` Pablo Neira Ayuso
@ 2012-01-25 12:28                     ` Hans Schillstrom
  0 siblings, 0 replies; 14+ messages in thread
From: Hans Schillstrom @ 2012-01-25 12:28 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Hans Schillstrom, kaber, jengelh, netfilter-devel, netdev

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

OK
> 
> >  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.
> 
> >   --hmark-dmask length               Dest address mask length
> 
> hmark-dst-mask
OK
> 
> >   --hmark-sp-mask value              Mask src port with value
> 
> hmark-sport-mask
OK
> 
> >   --hmark-dp-mask value              Mask dst port with value
> 
> hmark-dport-mask
OK
> 
> >   --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

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

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"

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

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

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

I agree, thanks

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

-- 
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2012-01-25 12:28 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-13  9:52 [v7 PATCH 0/3] NETFILTER new target module, HMARK Hans Schillstrom
2012-01-13  9:52 ` [PATCH 1/3] NETFILTER added flags to ipv6_find_hdr() Hans Schillstrom
2012-01-13  9:52 ` [PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark Hans Schillstrom
2012-01-22 21:44   ` Pablo Neira Ayuso
2012-01-22 23:20     ` Hans Schillstrom
2012-01-23  9:12       ` Pablo Neira Ayuso
2012-01-23  9:49         ` Hans Schillstrom
2012-01-23 17:01           ` Pablo Neira Ayuso
2012-01-24 17:56             ` Hans Schillstrom
2012-01-24 18:15               ` Pablo Neira Ayuso
2012-01-25 10:14                 ` Hans Schillstrom
2012-01-25 11:49                   ` Pablo Neira Ayuso
2012-01-25 12:28                     ` Hans Schillstrom
2012-01-13  9:52 ` [v7 PATCH 3/3] NETFILTER userspace part for target HMARK Hans Schillstrom

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.