netdev - ipv6: strange routing behaviors on a multi-interfaces setup

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>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Sep 2013 18:53:07 +0200
From:	Emmanuel Thierry <ml@...il.fr>
To:	netdev@...r.kernel.org
Subject: ipv6: strange routing behaviors on a multi-interfaces setup

Hello,

I'm working on multi-interfaces setups on IPv6. I found several disturbing route behaviors which sounds like bugs to me.

Both eth1 and eth2 interfaces receive RAs from distinct routers and autoconfigure:
* their slaac address
* their default route, both with the same priority
Under these conditions, the following happen depending on the expiration time of each route.

1/ A ping with a specified source address and interface may go through the wrong interface.

# ping6  -c 1 -I "<slaac_eth1>%eth1" <dest>
… uses the right interface (eth1) with the right source address (<slaac_eth1>).

# ping6  -c 1 -I "<slaac_eth2>%eth2" <dest>
… uses the wrong interface (eth1) with the right source address (<slaac_eth2>).

The ping6 utility performed a bind() on <slaac_ethx> with scope id set to <ifindex_ethx>.
If we flush the routing cache between each ping, the routing is done as expected.

As i could observe in the kernel. When ip6_pol_route() is called, oif is equal to <ifindex_eth2> but the flag RT6_LOOKUP_F_IFACE is not set. This makes routes through other interfaces to still be valid.
Shouldn't we set the RT6_LOOKUP_F_IFACE flag when a scope id is specified ?

2/ A ping from a specified source address may go through the wrong interface.

# ping6  -I "<slaac_eth2>" <dest>
… may use eth1 with <slaac_eth2>.

The ping6 utility performed a bind() on <slaac_eth2>
This is a derivative from the first one, with the significative difference that it also happens if the routing cache is empty. The most recent default route is chosen regardless of the source address.

Shouldn't we look in a first try for routes on the device corresponding to the source address, and in a second try for others ?

3/ A ping from a specified interface may go through the wrong interface with the wrong source address.

# ping6  -I "eth2" <dest>
… may use eth1 with <slaac_eth1>.

The ping6 performs a setsockopt(IPV6_PKTINFO) with <ifindex_ethx>, then a connect() to the destination. In this case, source address selection is concerned, but also routing since source address selection depends on routing.

I experienced these problems on a 3.11.1 kernel but they look to be quite recurrent in the past versions as well. 

Best regards
Emmanuel Thierry

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html