[PATCH] netdev: Netfilters on outgoing interfamily ipsec

[PATCH] netdev: Netfilters on outgoing interfamily ipsec

[Joakim Koskela]

Hi,

I understand that Herbert is in midst of cleaning up the output of
interfamily transformations, but I thought I'd post a couple of
patches related to that anyway, sort of to show what we've needed to
fix to get our systems working.

This one changes how the netfilters are applied during output to be
based on the current address family of the packet instead of what it
will be transformed to.

Signed-off-by: Joakim Koskela <jookos@gmail.com>
---

diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index c4a7156..8b0c6bd 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -13,6 +13,9 @@
 #include <linux/kernel.h>
 #include <linux/skbuff.h>
 #include <linux/netfilter_ipv4.h>
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+#include <linux/netfilter_ipv6.h>
+#endif
 #include <net/ip.h>
 #include <net/xfrm.h>
 #include <net/icmp.h>
@@ -139,7 +142,13 @@ static int xfrm4_output_finish(struct sk_buff *skb)
 
 int xfrm4_output(struct sk_buff *skb)
 {
-	return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dst->dev,
-			    xfrm4_output_finish,
-			    !(IPCB(skb)->flags & IPSKB_REROUTED));
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+	if (ip_hdr(skb)->version == 6)
+		return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dst->dev,
+			       xfrm4_output_finish);
+	else
+#endif
+		return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dst->dev,
+				    xfrm4_output_finish,
+				    !(IPCB(skb)->flags & IPSKB_REROUTED));
 }
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 6569767..7624613 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -14,8 +14,10 @@
 #include <linux/skbuff.h>
 #include <linux/icmpv6.h>
 #include <linux/netfilter_ipv6.h>
+#include <linux/netfilter_ipv4.h>
 #include <net/ipv6.h>
 #include <net/xfrm.h>
+#include <net/ip.h>
 
 int xfrm6_find_1stfragopt(struct xfrm_state *x, struct sk_buff *skb,
 			  u8 **prevhdr)
@@ -134,6 +136,11 @@ static int xfrm6_output_finish(struct sk_buff *skb)
 
 int xfrm6_output(struct sk_buff *skb)
 {
-	return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dst->dev,
-		       xfrm6_output_finish);
+	if (ip_hdr(skb)->version == 4)
+		return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dst->dev,
+				    xfrm6_output_finish,
+				    !(IPCB(skb)->flags & IPSKB_REROUTED));
+	else
+		return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dst->dev,
+			       xfrm6_output_finish);
 }

[PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Joakim Koskela]

This patch resets the ipv4-related flags in the new flow as their
content will otherwise depend on the bits of the ipv6 addresses the
struct was previously used for. For example, fl4_tos might have
RTO_ONLINK set, which usually prevents the right route from being
found.

This bit was chopped off the larger patch dealing with the problems
related to creating the bundles for inter-family tranformations.

Signed-off-by: Joakim Koskela <jookos@gmail.com>
--

diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 82e27b8..386a762 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -184,6 +184,8 @@ __xfrm6_bundle_create(struct xfrm_policy *policy, struct xfrm_state **xfrm, int
 			case AF_INET:
 				fl_tunnel.fl4_dst = xfrm[i]->id.daddr.a4;
 				fl_tunnel.fl4_src = xfrm[i]->props.saddr.a4;
+				fl_tunnel.fl4_tos = 0;
+				fl_tunnel.fl4_scope = 0;
 				break;
 			case AF_INET6:
 				ipv6_addr_copy(&fl_tunnel.fl6_dst, __xfrm6_bundle_addr_remote(xfrm[i], &fl->fl6_dst));

Re: [PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Herbert Xu]

On Fri, Oct 19, 2007 at 02:40:16PM +0300, Joakim Koskela wrote:
> This patch resets the ipv4-related flags in the new flow as their
> content will otherwise depend on the bits of the ipv6 addresses the
> struct was previously used for. For example, fl4_tos might have
> RTO_ONLINK set, which usually prevents the right route from being
> found.
> 
> This bit was chopped off the larger patch dealing with the problems
> related to creating the bundles for inter-family tranformations.

This changes behaviour.  Previously the same TOS value would be
used all the way through.  With this it won't apply to the first
tunnel and every SA after it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Joakim Koskela]

On Friday 19 October 2007 16:09:05 Herbert Xu wrote:
> On Fri, Oct 19, 2007 at 02:40:16PM +0300, Joakim Koskela wrote:
> >
> > This bit was chopped off the larger patch dealing with the problems
> > related to creating the bundles for inter-family tranformations.
>
> This changes behaviour.  Previously the same TOS value would be
> used all the way through.  With this it won't apply to the first
> tunnel and every SA after it.
>
> Cheers,

I'm not sure I follow. This affects the ipv6 bundling only where the struct 
(fl_tunnel) has previously been used for ipv6 addresses. Not that we are 
using the same block for holding the ipv4 info, the tos-value is really 
undefined before we reset it.

br, j

Re: [PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Herbert Xu]

Joakim Koskela <joakim.koskela@hiit.fi> wrote:
>
> I'm not sure I follow. This affects the ipv6 bundling only where the struct 
> (fl_tunnel) has previously been used for ipv6 addresses. Not that we are 
> using the same block for holding the ipv4 info, the tos-value is really 
> undefined before we reset it.

You're right.  But sure the same bug could affect IPv4 as well
if you had a 4-6-4 configuration.  Let me think about this one
a bit more.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Joakim Koskela]

On Friday 19 October 2007 17:25:49 Herbert Xu wrote:
> Joakim Koskela <joakim.koskela@hiit.fi> wrote:
> > I'm not sure I follow. This affects the ipv6 bundling only where the
> > struct (fl_tunnel) has previously been used for ipv6 addresses. Not that
> > we are using the same block for holding the ipv4 info, the tos-value is
> > really undefined before we reset it.
>
> You're right.  But sure the same bug could affect IPv4 as well
> if you had a 4-6-4 configuration.  Let me think about this one
> a bit more.

Hi, and thanks for the feedback. True, this one affects only one level of 
inter-family, and supporting more would require a lot more changes in the 
bundle creation (perhaps combining both versions and taking better into 
account the outer family of the last transformation..). 

Another quite annoying example of this is that 6 in 4 actually crashes the 
kernel on 64 bit, as xfrm_dst_lookup around xfrm6_policy.c:197 changes rt 
from a rt6_info to a rtable. On 64 bit, rt->rt61i_node will usually contain 
something (due to the larger pointer size), making the path_cookie assignment 
on line 208 crash.

I've been trying address this in a proper manner, but it hasn't really 
progressed quite the way I've wanted (..thus this shallow patch, just to make 
6-4 inter-work in most cases on the standard kernel). Needless to say, any 
work done for this would be greatly appreciated :)

Re: [PATCH] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec

[Herbert Xu]

On Mon, Oct 22, 2007 at 09:55:53AM +0300, Joakim Koskela wrote:
>
> Hi, and thanks for the feedback. True, this one affects only one level of 
> inter-family, and supporting more would require a lot more changes in the 
> bundle creation (perhaps combining both versions and taking better into 
> account the outer family of the last transformation..). 

I think I should have this fixed with my current tree.  I'll
either post that tonight or tomorrow.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] netdev: Netfilters on outgoing interfamily ipsec

[Herbert Xu]

On Fri, Oct 19, 2007 at 02:37:38PM +0300, Joakim Koskela wrote:
> Hi,
> 
> I understand that Herbert is in midst of cleaning up the output of
> interfamily transformations, but I thought I'd post a couple of
> patches related to that anyway, sort of to show what we've needed to
> fix to get our systems working.
> 
> This one changes how the netfilters are applied during output to be
> based on the current address family of the packet instead of what it
> will be transformed to.

While I agree that this is definitely a problem, I've already
got a solution for it which we happen to need for async crypto
anyway.

Basically xfrm_output will invoke a continuation function based
on the external mode/family which will then call the right hooks.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] netdev: Netfilters on outgoing interfamily ipsec

[Joakim Koskela]

On Friday 19 October 2007 15:55:55 Herbert Xu wrote:
> While I agree that this is definitely a problem, I've already
> got a solution for it which we happen to need for async crypto
> anyway.
>
> Basically xfrm_output will invoke a continuation function based
> on the external mode/family which will then call the right hooks.
>
> Cheers,

Ok, great. Lets go with that.