netdev - ip6ip6 tunnel routing issue

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]

Message-ID: <4F44B48B.70504@wakoond.hu>
Date:	Wed, 22 Feb 2012 10:25:31 +0100
From:	"Takács András" <wakoond@...il.com>
To:	netdev@...r.kernel.org
Subject: ip6ip6 tunnel routing issue

Dear All,

We're using Mobile IPv6 for vehicle communication, and we have found a 
very annoying issue in IPv6 routing.

We're running kernel 2.6.35.14, but we think, that the problem still 
exists in the latest kernel tree also.

The description of the problem:

Mobile IPv6 implementation in Linux is using different metric values for 
each Care-of Addresses, when creates or modifies default routes. This 
cause, that all of the packets are goes out on the interface which has 
lowest metric value, independently from the tunnel interface. In 
practice it cause that the packets which are routed into ip6tnl2 are 
goes out on eth1, instead of the setup, which binds ip6tnl2 to eth2.

I have attached a test script, which reproduces the problem, without 
Mobile IPv6. The init argument initializes the environment.

I have tried to find the problem in the kernel source. I found the 
followings:

In the find_rr_leaf function (net/ipv6/route.c) the iteration goes until 
the metric is equal to the specified one. If you look the calling 
environment, you should see, that this metric value is the metric of the 
first route info entry: http://pastebin.com/XfALRrrY

We have two totally same route entries, where only the interfaces and 
the metric values are different:

default via fe80::20c:29ff:fe3b:4d16 dev eth1  proto ra  metric 1023 
mtu 1500 advmss 1440 hoplimit 0
default via fe80::20c:29ff:fe3b:4d20 dev eth2  proto ra  metric 1053 
mtu 1500 advmss 1440 hoplimit 0

In this case, the above loop, will call find_match only once, for eth1. 
If it happens, the find_match function, couldn't find eth2, which 
belongs to ip6tnl2, and returns with eth1.

Unfortunately, the (IPv6) routing mechanism in quite complex in the 
kernel. I could find only a very ugly workaround for our problem:

The attached patch, introduces a new route lookup flag: 
RT6_LOOKUP_F_IP6TUNNEL. It is passed step-by-step to find_rr_leaf, and 
it will ignore the metric condition in the loop, if this flag has been 
enabled.

The ip6ip6-metric-fix.patch contains the fix for 2.6.35.14. We had to 
edit the definition of ip6_route_output. Because of this, the 
ip6ip6-metric-stuff.patch contains the modification of calling this at 
any other occurrences.

What is your opinion about this problem? What do you think about this 
workaround? Could anybody help to us to find a more elegant solution for 
this issue?

Best Regards,
András Takács

View attachment "ip6ip6-metric-fix.patch" of type "text/plain" (5868 bytes)

View attachment "ip6ip6-metric-stuff.patch" of type "text/plain" (8462 bytes)

Download attachment "test-ip6-tnls.sh" of type "application/x-sh" (5196 bytes)