Need for a specific source address selection rule ? (not neccessarily netfilter)

Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Hi folks,

Following a discussion on comp.os.linux.networking (1), I am wondering 
if a specific rule for source address selection would be a good idea or 
not. The rule might NOT be a netfilter rule at all (ie. the rule would 
be evaluated during source address selection, that is, before packet 
building), but probably with a similar approach. Please redirect the 
discussion to a more adapted list if this is off-topic if necessary.

With the future rise or IPv6 (even if it is a damn slow rise), servers 
will have the opportunity to have [easily] multiple IP addresses 
configured by default on each interface (ip -6 addr add ..), providing 
new features that were difficult to have with the scarce IPv4 resource:
* one outgoing IP per service (for example, a SMTP server would have its 
own address for the outgoing interface - and one unique reverse IP to 
the declared SMTP server address)
* one outgoing IP per user (for multi-user machines) ; with optional 
custom reverse ("smith.users.example.com")
* one outgoing IP for specific network blocks
etc ..

The first case can sometimes be partially solved using 
application-specific configuration (bind to a specific address) - 
however this is not desirable when you need to listen to all interfaces 
(ie. including IPv4-only or IPv6-only ones)

This can not be easily achieved currently ;
* iproute's rt_tables can be used to select a specific route, but some 
ugly NATing is still necessary to rewrite the source address (we do not 
want to do that and can not do that with ipv6 anyway) ; ie. this is 
generally too late as the packet has already been built (2)
* trapping bind/connect (3) for each service using some LD_PRELOAD magic 
is not very clean or easy to deploy

RFC 3484 (4) specifies the way source address is selected ; with the 
following order (5):

1. Prefer same address. (i.e. destination is local machine)
2. Prefer appropriate scope. (i.e. smallest scope shared with the 
destination)
3. Avoid deprecated addresses.
4. Prefer home addresses.
5. Prefer outgoing interface. (i.e. prefer an address on the interface 
we're sending out of)
6. Prefer matching label.
7. Prefer public addresses.
8. Use longest matching prefix.

However, [RFC 3484] "If the eight rules fail to choose a single address, 
some unspecified tie-breaker should be used". The current default, if I 
am not mistaken, is to select the last address added to "the" selected 
interface ; as the only remaining choice is to select addresses within a 
single interface. This seem to be the current "unspecified tie-breaker".

The code logic appears to be in net/ipv6/addrconf.c ; the 
IPV6_SADDR_RULE_PREFIX is the 8th rule, and is used in 
ipv6_get_saddr_eval()

[ip6_dst_lookup()/ip6_sk_dst_lookup()] => ip6_dst_lookup_tail() => 
ipv6_dev_get_saddr() => ipv6_get_saddr_eval()
[ For an UDP packet, the udpv6_sendmsg() directly uses 
ip6_sk_dst_lookup() to get the source address ]

This "unspecified tie-breaker" could be a new rule ; maybe a new 
"netfilter" (or pre-netfilter) rule specific to each interface ; ie. 
when the source address is selected using the RFC 3484 specification, a 
9th rule would select the source address within this interface. (such as 
"IPV6_SADDR_RULE_NETFILTER")

Any remark is welcome (including obvious solutions to the problem, which 
would be great)


Xavier.


(1) <news:i58p94$2pj$1@news.httrack.net>

(2) <news:i58ui8$1n0i$1@saria.nerim.net>

(3) <news:0cc95c92-eae3-4891-8f5e-8f1a414f8ec5@l38g2000pro.googlegroups.com>

(4) <http://www.ietf.org/rfc/rfc3484.txt>

(5) <http://www.davidc.net/networking/ipv6-source-address-selection-linux>

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Sunday 2010-08-29 12:48, Xavier Roche wrote:

>1. one outgoing IP per service (for example, a SMTP server would
>have its own address for the outgoing interface - and one unique
>reverse IP to the declared SMTP server address)
>
>The first case can sometimes be partially solved using
>application-specific configuration (bind to a specific address) -
>however this is not desirable when you need to listen to all
>interfaces (ie. including IPv4-only or IPv6-only ones)

You are confusing incoming with outgoing connections. bind is
correct. For the incoming one you bind to [::]:25, for the outgoing
one you bind to [2a01::desired]:0. Problem solved.


> 3. one outgoing IP for specific network blocks
> etc ..

Hosts uses their assigned address as outgoing source address.


>RFC 3484 (4) specifies the way source address is selected ; with the
>following order (5):
>
> 1. Prefer same address. (i.e. destination is local machine)
> 2. Prefer appropriate scope. (i.e. smallest scope shared with the destination)
> 3. Avoid deprecated addresses.
> 4. Prefer home addresses.
> 5. Prefer outgoing interface. (i.e. prefer an address on the interface we're
> sending out of)
> 6. Prefer matching label.
> 7. Prefer public addresses.
> 8. Use longest matching prefix.

And somewhere in between is /etc/gai.conf.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Jan Engelhardt a écrit :
> You are confusing incoming with outgoing connections.

Yes, my mistake.

> correct. For the incoming one you bind to [::]:25, for the outgoing
> one you bind to [2a01::desired]:0. Problem solved.

What would happend for v4 destinations ? Both v4/v6 destinations may 
exist at the same time.

> And somewhere in between is /etc/gai.conf.

Yes, this allows to change the ordering of the rules (RFC 5014 if I am 
correct), but not to add a specific rule depending on various parameters 
(destination, owner, etc.) at all.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Sunday 2010-08-29 14:51, Xavier Roche wrote:
> Jan Engelhardt a écrit :
>> You are confusing incoming with outgoing connections.
>
> Yes, my mistake.
>
>> correct. For the incoming one you bind to [::]:25, for the outgoing
>> one you bind to [2a01::desired]:0. Problem solved.
>
> What would happend for v4 destinations ? Both v4/v6 destinations may exist at
> the same time.

A socket is generally only responsible for a single protocol. In other 
words, that makes two sockets, one is [::]:25, the other is 0.0.0.0:25.
Now since IPv6 was designed - as is usual for IETF, resp it working 
groups - a bit whacky, there exists the possibility to receive v4 
connections on v6... but thank god there is a IPV6_V6ONLY socket option.

> but not to add a specific rule depending on various parameters
> (destination, owner, etc.) at all.

ip route add $(address of google.com) src $(my alternate address)

should do it. IPsec already does so if I am not mistaken.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Jan Engelhardt a écrit :
> ip route add $(address of google.com) src $(my alternate address)

Yes, but not for protocol, owner, and any other rule. This is direct 
routine from a network to another one.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Sunday 2010-08-29 15:51, Xavier Roche wrote:

> Jan Engelhardt a écrit :
>> ip route add $(address of google.com) src $(my alternate address)
>
> Yes, but not for protocol, owner, and any other rule. This is direct routine
> from a network to another one.

Well no, routing only concerns itself with layer-3 factors.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Jan Engelhardt a écrit :
> ip route add $(address of google.com) src $(my alternate address)
> should do it. IPsec already does so if I am not mistaken.

Note: it does not appear to work (unless my fingers did something 
wrong), for multiple addresses within an interface. The selected source 
address is still the same. I suspect the only thing you can change is 
the outgoing interface ; source address selection logic then remains the 
same.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Pascal Hambourg]

Hello again,

Xavier Roche a écrit :
> Jan Engelhardt a écrit :
>> ip route add $(address of google.com) src $(my alternate address)
>> should do it. IPsec already does so if I am not mistaken.
> 
> Note: it does not appear to work

IME, it works for IPv4 but not for IPv6 ; only IPv4 routes seem to
support the "src" attribute, and IME src is silently ignored for IPv6
routes.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Pascal Hambourg a écrit :
> IME, it works for IPv4 but not for IPv6 ; only IPv4 routes seem to
> support the "src" attribute, and IME src is silently ignored for IPv6
> routes.

The conclusion seems to be "Yes, there is a need for a specific source 
address selection rule" to decide which IP address should be selected 
within a single interface, based on arbitrary rules. (especially for IPv6)

The question is now: is there a chance such feature could be included 
one day in the kernel ?

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Friday 2010-09-03 19:36, Xavier Roche wrote:

> Pascal Hambourg a écrit :
>> IME, it works for IPv4 but not for IPv6 ; only IPv4 routes seem to
>> support the "src" attribute, and IME src is silently ignored for IPv6
>> routes.

That's a bug then, I suppose.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Jan Engelhardt a écrit :
>> Pascal Hambourg a écrit :
>>> IME, it works for IPv4 but not for IPv6 ; only IPv4 routes seem to
>>> support the "src" attribute, and IME src is silently ignored for IPv6
>>> routes.
> That's a bug then, I suppose.

Maybe. But in all cases, the other problem would still remain: the 
source address.

The src attribute is supported in V4, but only for routing.

Source address remains the same. (reason for the ugly NAT hacks in such 
cases)

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Friday 2010-09-03 20:34, Xavier Roche wrote:


> The src attribute is supported in V4, but only for routing.

Ha. Look at that. A src attribute in the routing table. Who would have 
thought it had /anything/ to do with routing? Inconceivable!

Of course it is for routing. That is why it is in the *drumroll*
routing table!

It's not like the src attribute had any other function in V6.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Xavier Roche]

Jan Engelhardt a écrit :
> Of course it is for routing. That is why it is in the *drumroll*
> routing table!

Sure. But my point was related to the main topic of this thread: the 
damn source address is NOT at all concerned. Obvious or not, routing 
won't help.

Re: Need for a specific source address selection rule ? (not neccessarily netfilter)

[Jan Engelhardt]

On Friday 2010-09-03 22:43, Xavier Roche wrote:

> Jan Engelhardt a écrit :
>> Of course it is for routing. That is why it is in the *drumroll*
>> routing table!
>
> Sure. But my point was related to the main topic of this thread: the damn
> source address is NOT at all concerned. Obvious or not, routing won't help.

So, either you agree that ignoring the src attribute in ipV6 is the bug, 
or you have an alternate theory that I have not yet groked.