linux-kernel - Re: [PATCH] ipv6: Fixed source specific default route handling.

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

Message-ID: <55884B12.7010307@universe-factory.net>
Date:	Mon, 22 Jun 2015 19:51:14 +0200
From:	Matthias Schiffer <mschiffer@...verse-factory.net>
To:	Steven Barth <steven@...link.org>
Cc:	Markus Stenberg <markus.stenberg@....fi>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ipv6: Fixed source specific default route handling.

On 06/22/2015 07:58 AM, Steven Barth wrote:
> On 22.06.2015 00:35, Matthias Schiffer wrote:
>> Could you explain in detail what you mean with "If you want specific SA,
>> add same route with higher metric and/or (more) specific src match."?
>> Routes aren't bound to specific addresses except via the "src" attribute
>> (which is called prefsrc in the kernel), which is exactly what it not
>> working. I can't control the chosen source address at all when
>> source-specific routes are involved.
> Except that prefsrc and src are two different beasts and usually ip route from transates to
> RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length.
> 
> Try adding two routes to the same destination with the same metric but different source values with PREFSRC (e.g. IPv4) and then
> try doing the same with SRC (e.g. IPv6). The former will fail but the latter will succeed.

Ah sorry, I didn't know that "src" and "prefsrc" were distinct concepts.
I meant to refer to "src" whenever I wrote "prefsrc". What are the
precise semantics of the "src" attribute? Any RFC I can read, or is this
a Linux-specific concept?

> 
> 
> https://tools.ietf.org/html/draft-troan-homenet-sadr-01
> was the original draft for source-address dependent routing IIRC so might be a good read.

Thanks for the link, that helps a bit.

> 
> 
>>
>> Even though the source-specific route has a higher metric than the
>> generic one, the source-specific one shadows the generic route.
> 
> (was a bit ago since I read into this so please correct me if I am wrong)
> IIRC this is intentional since longest-prefix-match beats metric here
> and the source-address match counts to being more-specific here. See also above difference between PREFSRC and SRC.

Ah, that would explain the metric issue. I looks like the source of my
confusion is that for source-specific routes *all* addresses are in the
candidate set, not only the addresses of the outgoing interface (which
makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in
the source-specific case).

I'm not sure if this can be fixed in a sane way (as there seems to be a
dependency cycle: source address should depend on outgoing interface,
which depends on the chosen route, which depends on the source address),
but it leads to highly unintuitive source address selection :(

Markus suggested in the commit message not to call ip6_route_output at
all before the source address has been selected. Wouldn't this make it
impossible to choose the source address depending on the outgoing
interface in the non-source-specific case as well?

> Cheers,
> 
> Steven

Thanks for the explanation,
Matthias


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)