linux-kernel - Unwanted "Frag needed and DF set" IPSEC ping response due to code change in xfrm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 6 Aug 2013 11:32:27 -0700
From:	Xiachen Dong <xiachendong@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Unwanted "Frag needed and DF set" IPSEC ping response due to code
 change in xfrm_policy.c from 2.6.38.8 to 2.6.39

Hi,

Recently we moved from the 2.6 kernel to the 3.0 kernel. While testing
the branch office vpn with the new kernel, we notice that the new
3.0.xx kernel generates the following response when ping through the
branch office vpn:

ping 3.3.3.100

PING 3.3.3.100 (3.3.3.100) 56(84) bytes of data.

>From 4.4.4.1 icmp_seq=1 Frag needed and DF set (mtu = 552)
64 bytes from 3.3.3.100: icmp_seq=2 ttl=62 time=6.48 ms
64 bytes from 3.3.3.100: icmp_seq=3 ttl=62 time=6.48 ms
...

Please note the message "icmp_seq=1 Frag needed and DF set (mtu =
552)". It occurs for the 1st ping packet. However, such message never
occurs under the 2.6.3[0-8] kernel.

We spent some time trying to figure out how such message comes into
being under the 3.0.xx kernel. Here is the call trace:

ip_forward() in ip_forward.c --> xfrm4_route_forward() in xfrm.h -->
xfrm_route_forward() in xfrm.h --> __xfrm_route_forward() in
xfrm_policy.c --> xfrm_lookup() in xfrm_policy.c

Within xfrm_lookup(), we reach "return make_blackhole(net, family,
dst_orgi);". The make_blackhole() returns a "fake" blackhole route and
the whole call trace returns back to ip_forward() in ip_forward.c:

ipv4/ip_forward.c:

int ip_forward(struct sk_buff *skb)
{
    ...

    if (!xfrm4_route_forward(skb))
        goto drop;

     rt = skb_rtable(skb);

    if (opt->is_strictroute && ip_hdr(skb)->daddr != rt->rt_gateway)
        goto sr_failed;

    if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
             (ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df) {
        IP_INC_STATS(dev_net(rt->dst.dev), IPSTATS_MIB_FRAGFAILS);
        icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
              htonl(dst_mtu(&rt->dst)));
        goto drop;
    }
    ...

}

Since xfrm_lookup() returns a "fake" balckhole rout (!IS_ERR),
__xfrm_route_forward() returns 1. As a result, xfrm4_route_forward()
returns 1. So the packet is not dropped.

Then the code falls through and hits "unlikely(skb->len >
dst_mtu(&rt->dst) ...). Since it is a blackhole route
(dst_mtu(&rt->dst) == 0), "skb->len > dst_mtu(&rt->dst)" is true, so
the kernel calls

 icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, ...)

That's how mesaage "icmp_seq=1 Frag needed and DF set (mtu = 552)" is generated.

In contrast, in 2.6.3[0-8] kernel, __xfrm_lookup() does not return
make_blackhole(), it returns -EREMOTE instead. Since -EREMOTE is
returned, xfrm_lookup() returns -EAGAIN. As a result, the packet is
dropped in ip_forward() in ipv4/ip_forward.c. That's why we don't see
the same message in 2.6.3[0-8].

Such code change about xfrm_policy.c first occurs in 2.6.39 kernel
(from 2.6.38.8). It appears that the corresponding GIT change are the
following:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/xfrm/xfrm_policy.c?id=2774c131b1d19920b4587db1cfbd6f0750ad1f15

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/xfrm/xfrm_policy.c?id=452edd598f60522c11f7f88fdbab27eb36509d1a

Our question is, is the message "Frag needed" an expected behavior? If
not, are there any suggestions about the walk around?

Thanks,

Xiachen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/