Is source address selection based on rules (netfilter) possible ?

Hi folks,

I have an IPv6 interface with multiple static addresses (on the same
interface ; ie. using 'up ip -6 addr add ...' rules), and I would like
to select the source address, based on various netfilter rules. The
default source address selected appears to be the last address added to
the interface ; I would like to change this behaviour for several cases
(such as a specific protocol)

I first tried to mark the packets using:

/sbin/ip6tables -A OUTPUT -t mangle \
-d 2000::/3 [more rules] \
-j MARK --set-mark 0xa

And then played with both /etc/iproute2/rt_tables + rules, and 'ip -6
route add', but it seem that I can not find the correct way to do that.

Policy-based routing appeared NOT to be the correct way (only one
interface, multiple source addresses), and NATing is probably also a bad
idea.

I'm a little bit stuck ; anyone managed to do something similar ?

Hello,

Xavier Roche a écrit :
>
> I have an IPv6 interface with multiple static addresses (on the same
> interface ; ie. using 'up ip -6 addr add ...' rules), and I would like
> to select the source address, based on various netfilter rules. The
> default source address selected appears to be the last address added to
> the interface ;

Actually there is a default address selection algorithm based on RFC
3484. See 'ip addrlabel'.

> I would like to change this behaviour for several cases
> (such as a specific protocol)
>
> I first tried to mark the packets using:
>
> /sbin/ip6tables -A OUTPUT -t mangle \
> -d 2000::/3 [more rules] \
> -j MARK --set-mark 0xa
>
> And then played with both /etc/iproute2/rt_tables + rules, and 'ip -6
> route add', but it seem that I can not find the correct way to do that.

It is too late. The packet has already been created and the source
address selected.

> and NATing is probably also a bad idea.

Anyway NAT is not available for IPv6 in Linux.

PS : fcolc et fcri, ils puent de la gueule ?

Pascal Hambourg a écrit :
> It is too late. The packet has already been created and the source
> address selected.

Darn. So what's the soltion ?

> Anyway NAT is not available for IPv6 in Linux.

Yes, just tested and NATing is not available at all - probably because
NAT on v6 is really stupid (and nobody wants NAT to live forever)

> PS : fcolc et fcri, ils puent de la gueule ?

[ Nan mais aucun ne correpond vraiment au sujet, donc j'ai finalement
opté pour ici (conf sous linux ou réseaux mais de manière générale) ]

Xavier Roche a écrit :
> Pascal Hambourg a écrit :
>> It is too late. The packet has already been created and the source
>> address selected.
>
> Darn. So what's the solution ?

I have no solution yet, sorry. Note that there is no real solution for
IPv4 either.

>> Anyway NAT is not available for IPv6 in Linux.
>
> Yes, just tested and NATing is not available at all - probably because
> NAT on v6 is really stupid (and nobody wants NAT to live forever)

Above all, Netfilter developpers don't want to implement IPv6 NAT. And I
support this decision because if IPv6 NAT is available, people will
start using the dirty hack instead of addressing the real issues. Oops,
they did it again.

But bad habits die hard ; the IAB even issued "thoughts on IPv6 NAT" as
RFC 5902 recently. See <http://www.bortzmeyer.org/5902.html> for a
comment (in french).

>> PS : fcolc et fcri, ils puent de la gueule ?
>
> [ Nan mais aucun ne correpond vraiment au sujet, donc j'ai finalement
> opté pour ici (conf sous linux ou réseaux mais de manière générale) ]

C'est pour ça qu'on a inventé le crosspost.

On Fri, 2010-08-27, Xavier Roche wrote:
> Pascal Hambourg a écrit :
>> It is too late. The packet has already been created and the source
>> address selected.
>
> Darn. So what's the soltion ?

Don't set up addresses which you don't want applications to use?
Configure the application to use a certain address? An application
can bind a socket to a certain address, even if it's just an UDP sender.

There may be other alternatives, but this feels a lot like something you
cannot expect to work. Why do you want to do it?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

David Schwartz a écrit :
> This makes no sense. In order for there to be netfilter rules, there
> must be a packet. In order for there to be a packet, there must be a
> source address already chosen.

Netfilter is probably not the right place ; but anyway source address
selection should be feasible based on a rule ? Maybe with a routing rule
based on iproute's rt_tables ?

The goal is to select different source addresses for different types of
protocols ; for server, this would allow to have different outgoing IP
addresses for each of them (such as smtp, nntp, ..), allowing to have
identified IPs per services.

On 2010-08-27, Xavier Roche <(E-Mail Removed)> wrote:
> Yes, just tested and NATing is not available at all - probably because
> NAT on v6 is really stupid (and nobody wants NAT to live forever)

Why not? Why would anyone not running a public server want their
network interface exposed directly to the internet?

--
Roger Blake
(Change "invalid" to "com" for email. Google Groups killfiled due to spam.)
"0bama snoozed while oil oozed."

David Schwartz a écrit :
> I would suggest intercepting the 'bind' and 'connect' calls with a
> preloaded library.

Humm, does not look like a sane method. (especially when the demons fork
themselves, and/or fork other processes)

Selecting a different route is possible apparently in IPv4 using
rt_tables selection and different interfaces aliases (iface:0, ..), but
even in this case the source address has to be hacked (rewritten) using
some NAT hack.

The RFC 3484 method (a quick overview at
<http://www.davidc.net/networking/ipv6-source-address-selection-linux>)
specify that "If the eight rules fail to choose a single address, some
unspecified tie-breaker should be used"

If this "unspecified tie-breaker" could be defined using a rule, it
would solve the problem. But apparently this is not possible

On Sun, 29 Aug 2010 14:35:09 +0200 David Brown
<(E-Mail Removed)> wrote:

> David Schwartz wrote:
> > On Aug 28, 4:20 am, Roger Blake <rogbl...@iname.invalid> wrote:
> >
> >> On 2010-08-27, Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
> >
> >>> Yes, just tested and NATing is not available at all - probably because
> >>> NAT on v6 is really stupid (and nobody wants NAT to live forever)
> >
> >> Why not? Why would anyone not running a public server want their
> >> network interface exposed directly to the internet?
> >
> > NAT and firewalls have nothing to do with each other. NAT happens to
> > provide some slight level of security by accident that you can't rely
> > on.
> >
>
> Two points here.
>
> First, NAT of various sorts can be used for other purposes than security
> or to allow multiple computers to connect to the internet via one IP
> (that being the most common use of IP4 NAT). NAT can be used for
> privacy, and it can be used as a way of "lying" about where packets come
> from or go to. It is probably not the "best" or "most correct" way to
> handle such issues, but it may be the easiest. For example, if you have
> a piece of software or hardware that has hard-coded IP addresses that it
> contacts (or allows contact from) - NAT lets you "change" those addresses.

IPv6 has some privacy features which can fit the bill.

> Secondly, NAT /does/ provide a level of security. It is by no means
> impenetrable to sophisticated attacks, and it has certain glaring holes
> such as the UDP firewall bypassing used by applications such as Skype.
> But it is such a /huge/ improvement on security compared to commonly
> found alternatives - Windows "software firewalls" and incorrectly
> configured firewalls - that NAT routers /do/ count as security.
>
> That this is by accident rather than by design is irrelevant here. I'll
> certainly not claim that NAT provides solid security, or that it is
> suitable for a serious network. But the practical facts of internet
> security in the real world are that most people use Windows, and most of
> these are connected to the Internet from fairly simple networks with no
> administrator. When the real-world choice is between connecting these
> PC's directly, or connecting them via a NAT router, I'd say that NAT
> gives excellent security here.

This minimal security is offered by stateful firewalling, not by NAT itself.

Basically, the alleged NAT "security" policy is: allow everything outbound,
allow inbound only if it's part of a flow that originated from inside.

There's nothing NAT-specific in that, except that NAT also needs stateful
connection tracking to work. But the same policy can easily be implemented
with any stateful firewall.

CPE vendors used and use to supply NAT-ready devices. I don't see why they
could not be able to ship IPv6 CPEs with such a minimal firewall already
configured. That would give users the same "security" as NAT.

David Brown a écrit :
>
> NAT can be used for privacy

IPv6 temporary addresses have been designed to address privacy concerns.

> Secondly, NAT /does/ provide a level of security.

You cannot rely on it. Due to the lack of standardization, there are
many different implementations of NAT. Some may provide some level of
security, some may provide none. "Pure" NAT such as the implementation
in netfilter/iptables provides no level of security ; it does not drop
packets, it just changes their addresses and ports according to some
rules. If a packet does not match any rule, it is just left untouched.

IPv4 NAT is mostly associated to private addressing. Now ask yourself
what provides the most security : the private addresses which are
unreachable from the public internet or the NAT whose purpose is to
allows partial communication between the private hosts and the public
internet ?