* [PATCH] xfrm: fix tunnel model fragmentation behavior
@ 2022-02-21 5:16 Lina Wang
2022-02-21 11:04 ` Steffen Klassert
2022-02-23 8:31 ` Steffen Klassert
0 siblings, 2 replies; 6+ messages in thread
From: Lina Wang @ 2022-02-21 5:16 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S . Miller,
Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski, Matthias Brugger
Cc: netdev, linux-kernel, linux-arm-kernel, 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
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..ab4384e22b4f 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)
+ 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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] xfrm: fix tunnel model fragmentation behavior
2022-02-21 5:16 [PATCH] xfrm: fix tunnel model fragmentation behavior Lina Wang
@ 2022-02-21 11:04 ` Steffen Klassert
2022-02-22 2:18 ` Lina Wang
2022-02-23 8:31 ` Steffen Klassert
1 sibling, 1 reply; 6+ messages in thread
From: Steffen Klassert @ 2022-02-21 11:04 UTC (permalink / raw)
To: Lina Wang
Cc: Herbert Xu, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, netdev, linux-kernel,
linux-arm-kernel
On Mon, Feb 21, 2022 at 01:16:48PM +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
>
> Signed-off-by: Lina Wang <lina.wang@mediatek.com>
We have two commits in the ipsec tree that address a very similar
issue. That is:
commit 6596a0229541270fb8d38d989f91b78838e5e9da
xfrm: fix MTU regression
and
commit a6d95c5a628a09be129f25d5663a7e9db8261f51
Revert "xfrm: xfrm_state_mtu should return at least 1280 for ipv6"
Can you please doublecheck that the issue you are fixing still
exist in the ipsec tree?
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfrm: fix tunnel model fragmentation behavior
2022-02-21 11:04 ` Steffen Klassert
@ 2022-02-22 2:18 ` Lina Wang
2022-02-23 8:25 ` Steffen Klassert
0 siblings, 1 reply; 6+ messages in thread
From: Lina Wang @ 2022-02-22 2:18 UTC (permalink / raw)
To: Steffen Klassert
Cc: Herbert Xu, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, netdev, linux-kernel,
linux-arm-kernel, Lina Wang
On Mon, 2022-02-21 at 12:04 +0100, Steffen Klassert wrote:
> On Mon, Feb 21, 2022 at 01:16:48PM +0800, Lina Wang wrote:
> > in tunnel mode, if outer interface(ipv4) is less, it is easily to
We have two commits in the ipsec tree that address a very similar
> issue. That is:
>
> commit 6596a0229541270fb8d38d989f91b78838e5e9da
> xfrm: fix MTU regression
>
> and
>
> commit a6d95c5a628a09be129f25d5663a7e9db8261f51
> Revert "xfrm: xfrm_state_mtu should return at least 1280 for ipv6"
>
> Can you please doublecheck that the issue you are fixing still
> exist in the ipsec tree?
Yes, I know the two patches, which didnot help for my scenary. Whatever
commit a6d95c5a62 exist or not, there still is double fragment issue. From
commit 6596a022's mail thread, owner has met double fragment issue, I am
not sure if it is the same with mine.
My scenary is very simple, set up ipsec0, create default route, set
transport mode for ipsec0 and tunnel mode for wlan0.
ip link add ipsec0 type xfrm dev xfrm dev wlan0 if_id xx
ip link set mtu 1400 dev ipsec0
ip link set mtu 1300 dev wlan0
ping6 -s 1300 xx will always reproduce such issue.
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfrm: fix tunnel model fragmentation behavior
2022-02-22 2:18 ` Lina Wang
@ 2022-02-23 8:25 ` Steffen Klassert
0 siblings, 0 replies; 6+ messages in thread
From: Steffen Klassert @ 2022-02-23 8:25 UTC (permalink / raw)
To: Lina Wang
Cc: Herbert Xu, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, netdev, linux-kernel,
linux-arm-kernel
On Tue, Feb 22, 2022 at 10:18:04AM +0800, Lina Wang wrote:
> On Mon, 2022-02-21 at 12:04 +0100, Steffen Klassert wrote:
> > On Mon, Feb 21, 2022 at 01:16:48PM +0800, Lina Wang wrote:
> > > in tunnel mode, if outer interface(ipv4) is less, it is easily to
> We have two commits in the ipsec tree that address a very similar
> > issue. That is:
> >
> > commit 6596a0229541270fb8d38d989f91b78838e5e9da
> > xfrm: fix MTU regression
> >
> > and
> >
> > commit a6d95c5a628a09be129f25d5663a7e9db8261f51
> > Revert "xfrm: xfrm_state_mtu should return at least 1280 for ipv6"
> >
> > Can you please doublecheck that the issue you are fixing still
> > exist in the ipsec tree?
>
> Yes, I know the two patches, which didnot help for my scenary. Whatever
> commit a6d95c5a62 exist or not, there still is double fragment issue. From
> commit 6596a022's mail thread, owner has met double fragment issue, I am
> not sure if it is the same with mine.
Thanks for the doublecking this!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfrm: fix tunnel model fragmentation behavior
2022-02-21 5:16 [PATCH] xfrm: fix tunnel model fragmentation behavior Lina Wang
2022-02-21 11:04 ` Steffen Klassert
@ 2022-02-23 8:31 ` Steffen Klassert
2022-02-24 6:15 ` Lina Wang
1 sibling, 1 reply; 6+ messages in thread
From: Steffen Klassert @ 2022-02-23 8:31 UTC (permalink / raw)
To: Lina Wang
Cc: Herbert Xu, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, netdev, linux-kernel,
linux-arm-kernel
On Mon, Feb 21, 2022 at 01:16:48PM +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
>
> Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Can you please add a 'Fixes' tag?
> ---
> 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..ab4384e22b4f 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)
> + return 1;
Shouldn't this problem exist for NEXTHDR_AUTH too?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] xfrm: fix tunnel model fragmentation behavior
2022-02-23 8:31 ` Steffen Klassert
@ 2022-02-24 6:15 ` Lina Wang
0 siblings, 0 replies; 6+ messages in thread
From: Lina Wang @ 2022-02-24 6:15 UTC (permalink / raw)
To: Steffen Klassert
Cc: Herbert Xu, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, netdev, linux-kernel,
linux-arm-kernel, Lina Wang
On Wed, 2022-02-23 at 09:31 +0100, Steffen Klassert wrote:
> On Mon, Feb 21, 2022 at 01:16:48PM +0800, Lina Wang wrote:
>Can you please add a 'Fixes' tag?
>
Sure
+ fh = (struct frag_hdr *)(skb->data + sizeof(struct ipv6hdr));
> > + if (fh->nexthdr == NEXTHDR_ESP)
> > + return 1;
>
> Shouldn't this problem exist for NEXTHDR_AUTH too?
Thanks for reminding! V2 has modified and submitted!
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-02-24 6:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-21 5:16 [PATCH] xfrm: fix tunnel model fragmentation behavior Lina Wang
2022-02-21 11:04 ` Steffen Klassert
2022-02-22 2:18 ` Lina Wang
2022-02-23 8:25 ` Steffen Klassert
2022-02-23 8:31 ` Steffen Klassert
2022-02-24 6:15 ` Lina Wang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).