[PATCH RFC] xfrm6: handling fragment

[PATCH RFC] xfrm6: handling fragment

[Nicolas Dichtel]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

RFC4301 Section 7.1 says:

"7.1.  Tunnel Mode SAs that Carry Initial and Non-Initial Fragments

     All implementations MUST support tunnel mode SAs that are configured
     to pass traffic without regard to port field (or ICMP type/code or
     Mobility Header type) values.  If the SA will carry traffic for
     specified protocols, the selector set for the SA MUST specify the
     port fields (or ICMP type/code or Mobility Header type) as ANY.  An
     SA defined in this fashion will carry all traffic including initial
     and non-initial fragments for the indicated Local/Remote addresses
     and specified Next Layer protocol(s)."

But for IPv6, fragment is treated as a protocol. Would the following patch be 
acceptable to catch protocol transported in fragmented packet?
In IPv4, there is no problem.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

[-- Attachment #2: x.diff --]
[-- Type: text/x-patch, Size: 1813 bytes --]

diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 08e4cbb..604bc0a 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -144,6 +144,7 @@ static int xfrm6_fill_dst(struct xfrm_dst *xdst, struct net_device *dev)
 static inline void
 _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
 {
+	int onlyproto = 0;
 	u16 offset = skb_network_header_len(skb);
 	struct ipv6hdr *hdr = ipv6_hdr(skb);
 	struct ipv6_opt_hdr *exthdr;
@@ -159,6 +160,8 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
 		exthdr = (struct ipv6_opt_hdr *)(nh + offset);
 
 		switch (nexthdr) {
+		case NEXTHDR_FRAGMENT:
+			onlyproto = 1;
 		case NEXTHDR_ROUTING:
 		case NEXTHDR_HOP:
 		case NEXTHDR_DEST:
@@ -172,7 +175,7 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
 		case IPPROTO_TCP:
 		case IPPROTO_SCTP:
 		case IPPROTO_DCCP:
-			if (pskb_may_pull(skb, nh + offset + 4 - skb->data)) {
+			if (!onlyproto && pskb_may_pull(skb, nh + offset + 4 - skb->data)) {
 				__be16 *ports = (__be16 *)exthdr;
 
 				fl->fl_ip_sport = ports[!!reverse];
@@ -182,7 +185,7 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
 			return;
 
 		case IPPROTO_ICMPV6:
-			if (pskb_may_pull(skb, nh + offset + 2 - skb->data)) {
+			if (!onlyproto && pskb_may_pull(skb, nh + offset + 2 - skb->data)) {
 				u8 *icmp = (u8 *)exthdr;
 
 				fl->fl_icmp_type = icmp[0];
@@ -193,7 +196,7 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
 
 #if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
 		case IPPROTO_MH:
-			if (pskb_may_pull(skb, nh + offset + 3 - skb->data)) {
+			if (!onlyproto && pskb_may_pull(skb, nh + offset + 3 - skb->data)) {
 				struct ip6_mh *mh;
 				mh = (struct ip6_mh *)exthdr;
 

Re: [PATCH RFC] xfrm6: handling fragment

[David Miller]

From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 31 Oct 2008 18:18:01 +0100

> RFC4301 Section 7.1 says:
> 
> "7.1.  Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
> 
>      All implementations MUST support tunnel mode SAs that are configured
>      to pass traffic without regard to port field (or ICMP type/code or
>      Mobility Header type) values.  If the SA will carry traffic for
>      specified protocols, the selector set for the SA MUST specify the
>      port fields (or ICMP type/code or Mobility Header type) as ANY.  An
>      SA defined in this fashion will carry all traffic including initial
>      and non-initial fragments for the indicated Local/Remote addresses
>      and specified Next Layer protocol(s)."
> 
> But for IPv6, fragment is treated as a protocol. Would the following patch be acceptable to catch protocol transported in fragmented packet?
> In IPv4, there is no problem.
> 
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

This seems good, I've applied this to net-next-2.6

Thanks.