[PATCH v2] xfrm: fix tunnel model fragmentation behavior

[PATCH v2] xfrm: fix tunnel model fragmentation behavior

[Lina Wang]

In tunnel mode, if outer interface(ipv4) is less, it is easily to let 
inner IPV6 mtu be less than 1280. If so, a Packet Too Big ICMPV6 message 
is received. When send again, packets are fragmentized with 1280, they
are still rejected with ICMPV6(Packet Too Big) by xfrmi_xmit2().

According to RFC4213 Section3.2.2:
         if (IPv4 path MTU - 20) is less than 1280
                 if packet is larger than 1280 bytes
                         Send ICMPv6 "packet too big" with MTU = 1280.
                         Drop packet.
                 else
                         Encapsulate but do not set the Don't Fragment
                         flag in the IPv4 header.  The resulting IPv4
                         packet might be fragmented by the IPv4 layer
                         on the encapsulator or by some router along
                         the IPv4 path.
                 endif
         else
                 if packet is larger than (IPv4 path MTU - 20)
                         Send ICMPv6 "packet too big" with
                         MTU = (IPv4 path MTU - 20).
                         Drop packet.
                 else
                         Encapsulate and set the Don't Fragment flag
                         in the IPv4 header.
                 endif
         endif
Packets should be fragmentized with ipv4 outer interface, so change it.

After it is fragemtized with ipv4, there will be double fragmenation.
No.48 & No.51 are ipv6 fragment packets, No.48 is double fragmentized, 
then tunneled with IPv4(No.49& No.50), which obey spec. And received peer
cannot decrypt it rightly.

48              2002::10	2002::11 1296(length) IPv6 fragment (off=0 more=y ident=0xa20da5bc nxt=50) 
49   0x0000 (0) 2002::10	2002::11 1304	      IPv6 fragment (off=0 more=y ident=0x7448042c nxt=44)
50   0x0000 (0)	2002::10	2002::11 200	      ESP (SPI=0x00035000) 
51		2002::10	2002::11 180	      Echo (ping) request 
52   0x56dc     2002::10	2002::11 248	      IPv6 fragment (off=1232 more=n ident=0xa20da5bc nxt=50)

esp_noneed_fragment has fixed above issues. Finally, it acted like below:
1   0x6206 192.168.1.138   192.168.1.1 1316 Fragmented IP protocol (proto=Encap Security Payload 50, off=0, ID=6206) [Reassembled in #2]
2   0x6206 2002::10	   2002::11    88   IPv6 fragment (off=0 more=y ident=0x1f440778 nxt=50)
3   0x0000 2002::10	   2002::11    248  ICMPv6    Echo (ping) request 

Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
---
 net/ipv6/xfrm6_output.c   | 16 ++++++++++++++++
 net/xfrm/xfrm_interface.c |  5 ++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index d0d280077721..1ee643f8f5d5 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -45,6 +45,19 @@ static int __xfrm6_output_finish(struct net *net, struct sock *sk, struct sk_buf
 	return xfrm_output(sk, skb);
 }
 
+static int esp_noneed_fragment(struct sk_buff *skb)
+{
+	struct frag_hdr *fh;
+	u8 prevhdr = ipv6_hdr(skb)->nexthdr;
+
+	if (prevhdr != NEXTHDR_FRAGMENT)
+		return 0;
+	fh = (struct frag_hdr *)(skb->data + sizeof(struct ipv6hdr));
+	if (fh->nexthdr == NEXTHDR_ESP || fh->nexthdr == NEXTHDR_AUTH)
+		return 1;
+	return 0;
+}
+
 static int __xfrm6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
 {
 	struct dst_entry *dst = skb_dst(skb);
@@ -73,6 +86,9 @@ static int __xfrm6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
 		xfrm6_local_rxpmtu(skb, mtu);
 		kfree_skb(skb);
 		return -EMSGSIZE;
+	} else if (toobig && esp_noneed_fragment(skb)) {
+		skb->ignore_df = 1;
+		goto skip_frag;
 	} else if (!skb->ignore_df && toobig && skb->sk) {
 		xfrm_local_error(skb, mtu);
 		kfree_skb(skb);
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index 57448fc519fc..242351fffdeb 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -304,7 +304,10 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)
 			if (mtu < IPV6_MIN_MTU)
 				mtu = IPV6_MIN_MTU;
 
-			icmpv6_ndo_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
+			if (skb->len > 1280)
+				icmpv6_ndo_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
+			else
+				goto xmit;
 		} else {
 			if (!(ip_hdr(skb)->frag_off & htons(IP_DF)))
 				goto xmit;
-- 
2.18.0

Re: [PATCH v2] xfrm: fix tunnel model fragmentation behavior

[Steffen Klassert]

On Thu, Feb 24, 2022 at 02:09:31PM +0800, Lina Wang wrote:
> In tunnel mode, if outer interface(ipv4) is less, it is easily to let 
> inner IPV6 mtu be less than 1280. If so, a Packet Too Big ICMPV6 message 
> is received. When send again, packets are fragmentized with 1280, they
> are still rejected with ICMPV6(Packet Too Big) by xfrmi_xmit2().
> 
> According to RFC4213 Section3.2.2:
>          if (IPv4 path MTU - 20) is less than 1280
>                  if packet is larger than 1280 bytes
>                          Send ICMPv6 "packet too big" with MTU = 1280.
>                          Drop packet.
>                  else
>                          Encapsulate but do not set the Don't Fragment
>                          flag in the IPv4 header.  The resulting IPv4
>                          packet might be fragmented by the IPv4 layer
>                          on the encapsulator or by some router along
>                          the IPv4 path.
>                  endif
>          else
>                  if packet is larger than (IPv4 path MTU - 20)
>                          Send ICMPv6 "packet too big" with
>                          MTU = (IPv4 path MTU - 20).
>                          Drop packet.
>                  else
>                          Encapsulate and set the Don't Fragment flag
>                          in the IPv4 header.
>                  endif
>          endif
> Packets should be fragmentized with ipv4 outer interface, so change it.
> 
> After it is fragemtized with ipv4, there will be double fragmenation.
> No.48 & No.51 are ipv6 fragment packets, No.48 is double fragmentized, 
> then tunneled with IPv4(No.49& No.50), which obey spec. And received peer
> cannot decrypt it rightly.
> 
> 48              2002::10	2002::11 1296(length) IPv6 fragment (off=0 more=y ident=0xa20da5bc nxt=50) 
> 49   0x0000 (0) 2002::10	2002::11 1304	      IPv6 fragment (off=0 more=y ident=0x7448042c nxt=44)
> 50   0x0000 (0)	2002::10	2002::11 200	      ESP (SPI=0x00035000) 
> 51		2002::10	2002::11 180	      Echo (ping) request 
> 52   0x56dc     2002::10	2002::11 248	      IPv6 fragment (off=1232 more=n ident=0xa20da5bc nxt=50)
> 
> esp_noneed_fragment has fixed above issues. Finally, it acted like below:
> 1   0x6206 192.168.1.138   192.168.1.1 1316 Fragmented IP protocol (proto=Encap Security Payload 50, off=0, ID=6206) [Reassembled in #2]
> 2   0x6206 2002::10	   2002::11    88   IPv6 fragment (off=0 more=y ident=0x1f440778 nxt=50)
> 3   0x0000 2002::10	   2002::11    248  ICMPv6    Echo (ping) request 
> 
> Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
> Signed-off-by: Lina Wang <lina.wang@mediatek.com>

Your patch does not apply, it is not in plain text format.

> ---
>  net/ipv6/xfrm6_output.c   | 16 ++++++++++++++++
>  net/xfrm/xfrm_interface.c |  5 ++++-
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
> index d0d280077721..1ee643f8f5d5 100644
> --- a/net/ipv6/xfrm6_output.c
> +++ b/net/ipv6/xfrm6_output.c
> @@ -45,6 +45,19 @@ static int __xfrm6_output_finish(struct net *net, struct sock *sk, struct sk_buf
>  	return xfrm_output(sk, skb);
>  }
>  
> +static int esp_noneed_fragment(struct sk_buff *skb)
> +{
> +	struct frag_hdr *fh;
> +	u8 prevhdr = ipv6_hdr(skb)->nexthdr;
> +
> +	if (prevhdr != NEXTHDR_FRAGMENT)
> +		return 0;
> +	fh = (struct frag_hdr *)(skb->data + sizeof(struct ipv6hdr));
> +	if (fh->nexthdr == NEXTHDR_ESP || fh->nexthdr == NEXTHDR_AUTH)
> +		return 1;
> +	return 0;
> +}

While at it, this is not an ESP speciffic function. Please rename to
xfrm_noneed_fragment.

Re: [PATCH v2] xfrm: fix tunnel model fragmentation behavior

[Lina Wang]

On Thu, 2022-02-24 at 11:23 +0100, Steffen Klassert wrote:
> On Thu, Feb 24, 2022 at 02:09:31PM +0800, Lina Wang wrote:
> > In tunnel mode, if outer interface(ipv4) is less, it is easily to
> Your patch does not apply, it is not in plain text format.
> 
Do u mean I used base64 encoding? I already updated v3 as 8bit.
>
> While at it, this is not an ESP speciffic function. Please rename to
> xfrm_noneed_fragment.
>
Yes, change it to xfrm6_noneed_fragment

Thanks!