[patch] source-address selection

[David Young]

For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.
Below, I document the impact of the patches a bit. I will turn this
text into a manual page.

The patches let an operator set the policy by which the kernel chooses a
source address for any socket bound to the "wildcard" address, INADDR_ANY.
Note that the policy is applied *after* the kernel makes its forwarding
decision, thereby choosing the output interface; in other words, this
mechanism does not affect whether or not NetBSD is a "strong ES".

An operator affects the source-address selection using sysctl(8) and
ifconfig(8). Operators set policies with sysctl(8). Some policies
consider the "preference number" of an address. An operator may set
preference numbers for each address with ifconfig(8).

A source-address policy is a priority-ordered list of source-address
ranking functions. A ranking function maps its arguments, (_source
address_, _source index_, _source preference_, _destination address_),
to integers. The _source index_ is the position of _source address_
in the interface address list; the index of the first address is 0.
The _source preference_ is the preference number the operator assigned
to _source address_. The _destination address_ is the socket peer /
packet destination.

Presently, there are four ranking functions to choose from:

index ranks by _source index_; lower indices are ranked
more highly

preference ranks by _source preference_; lower preference
numbers are ranked more highly

common-prefix-len
ranks each _source address_ by the length of the
longest prefix it has in common with _destination
address_; longer common prefixes rank more highly

same-category determines the "categories" of _source_ and
_destination address_. A category is one of
"private", "link-local", or "other". If the
categories exactly match, same-category assigns a
rank of 2. Some sources are ranked 1 by category:
a link-local source with a private destination,
a private source with a link-local destination,
and a private source with an "other" destination
rank 1. All other sources rank 0.

Categories are defined as follows.

private: RFC1918 networks, 192.168/16, 172.16/12,
and 10/8,

link-local: 169.254/16, 224/24

other: all other networks---i.e., not private,
not link-local

To apply a policy, the kernel applies all ranking functions in the policy
to every source address, producing a vector of ranks for each source.
The kernel sorts the sources in descending, lexicographical order by their
rank-vector, and chooses the highest-ranking (first) source. The kernel
breaks ties by choosing the source with the least _source index_.

The operator may set a policy on individual interfaces. The operator
may also set a global policy that applies to all interfaces whose policy
he does not set individually.

Here is the sysctl tree for the policy at system startup:

net.inet.ip.selectsrc.default = index
net.inet.ip.interfaces.ath0.selectsrc =
net.inet.ip.interfaces.sip0.selectsrc =
net.inet.ip.interfaces.sip1.selectsrc =
net.inet.ip.interfaces.lo0.selectsrc =
net.inet.ip.interfaces.pflog0.selectsrc =

The policy on every interface is the "empty" policy, so the default
policy applies. The default policy, "index," is the "historical" policy
in NetBSD.

The operator may override the default policy on ath0,

# sysctl -w net.inet.ip.interfaces.ath0.selectsrc=\

same-category,common-prefix-len,preference

yielding this policy:

net.inet.ip.selectsrc.default = index
net.inet.ip.interfaces.ath0.selectsrc = same-category,common-prefix-len,preference

The operator may set a new default,

# sysctl -w net.inet.ip.selectsrc.debug=\

same-category,common-prefix-len,preference

# sysctl -w net.inet.ip.interfaces.ath0.selectsrc=

yielding this policy:

net.inet.ip.selectsrc.default = same-category,common-prefix-len,preference
net.inet.ip.interfaces.ath0.selectsrc =

In a number of application areas, the policy above will usually pick
suitable source addresses if ath0 is configured in this way:

# ifconfig ath0 inet 64.198.255.1/24
# ifconfig ath0 inet 10.0.0.1/24
# ifconfig ath0 inet 169.254.1.1/24
# ifconfig ath0 inet 192.168.49.1/24 preference 5
# ifconfig ath0 inet 192.168.37.1/24 preference 9

A sysctl, net.inet.ip.selectsrc.debug, turns on and off debug messages
concerned with source selection. You may set it to 0 (no messages) or 1.

You add the source-address selection policy mechanism to your kernel with
'options IPSELSRC'.

Dave

[Mihai CHELARU]

Post by David Young
For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.

[..]

Great work ! Thank you !

[..]

Post by David Young
preference ranks by _source preference_; lower preference
numbers are ranked more highly

Preference should do exactly the opposite. Higher preference for higher
rank. This is the logical way. If user sets an address without preference
it should default to 0.

Post by David Young
common-prefix-len
ranks each _source address_ by the length of the
longest prefix it has in common with _destination
address_; longer common prefixes rank more highly

Aye ! This is great !

Post by David Young
same-category determines the "categories" of _source_ and
_destination address_. A category is one of
"private", "link-local", or "other". If the
categories exactly match, same-category assigns a
a link-local source with a private destination,
a private source with a link-local destination,
and a private source with an "other" destination
rank 1. All other sources rank 0.
Categories are defined as follows.
private: RFC1918 networks, 192.168/16, 172.16/12,
and 10/8,
link-local: 169.254/16, 224/24
other: all other networks---i.e., not private,
not link-local

Uhm, I don't understand this. Isn't common prefix enough ? Why is 224/24
(shouldn't be 224/4 ?) link-local ? Maybe you wanted 240/4 ? Also for
link-local I suggest adding 0/8. But the first question remains: why do we
need this ?

[Pavel Cahyna]

Post by David Young
For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.
Below, I document the impact of the patches a bit. I will turn this
text into a manual page.
The patches let an operator set the policy by which the kernel chooses a
source address for any socket bound to the "wildcard" address, INADDR_ANY.
Note that the policy is applied *after* the kernel makes its forwarding
decision, thereby choosing the output interface; in other words, this
mechanism does not affect whether or not NetBSD is a "strong ES".

My impression is that it introduces a quite complicated interface to
achieve only limited results. Namely, you can't apparently request a
source address from a different interface. Using an alias on the loopback
interface as source address quite common, I think.

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai CHELARU]

Post by Pavel Cahyna
Namely, you can't apparently request a
source address from a different interface.

Don't bind to INADDR_ANY in this case.

[David Young]

Post by Pavel Cahyna

Post by David Young
For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.
Below, I document the impact of the patches a bit. I will turn this
text into a manual page.
The patches let an operator set the policy by which the kernel chooses a
source address for any socket bound to the "wildcard" address, INADDR_ANY.
Note that the policy is applied *after* the kernel makes its forwarding
decision, thereby choosing the output interface; in other words, this
mechanism does not affect whether or not NetBSD is a "strong ES".

My impression is that it introduces a quite complicated interface to
achieve only limited results.

Can you suggest any less complicated interface to achieve the same or
better result?

Post by Pavel Cahyna
Namely, you can't apparently request a
source address from a different interface.

As Mihai said, you can still bind any address you like. It would be easy
to extend the source-selection patch so that it considered addresses on
interfaces other than the output interface, however, I leave that up to
somebody else.

Dave

[Pavel Cahyna]

Post by David Young

Post by Pavel Cahyna

Post by David Young
For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.
Below, I document the impact of the patches a bit. I will turn this
text into a manual page.
The patches let an operator set the policy by which the kernel chooses a
source address for any socket bound to the "wildcard" address, INADDR_ANY.
Note that the policy is applied *after* the kernel makes its forwarding
decision, thereby choosing the output interface; in other words, this
mechanism does not affect whether or not NetBSD is a "strong ES".

My impression is that it introduces a quite complicated interface to
achieve only limited results.

Can you suggest any less complicated interface to achieve the same or
better result?

I would be quite happy with your complicated solution, if it is a bit more
powerful. It should be possible to mark an address as being a candidate
for source address selection on other interfaces, for example.
(ok, I can add this later.)

Also, do you have any similar plans for IPv6 ? There is a standard
algorithm for source address selection, it would be good to keep v4 and v6
in sync.

Post by David Young

Post by Pavel Cahyna
Namely, you can't apparently request a
source address from a different interface.

As Mihai said, you can still bind any address you like. It would be easy
to extend the source-selection patch so that it considered addresses on
interfaces other than the output interface, however, I leave that up to
somebody else.

Well if we can bind any address, we don't need any source address
selection mechanism in the kernel, no? :-)

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Pavel Cahyna
Also, do you have any similar plans for IPv6 ? There is a standard
algorithm for source address selection, it would be good to keep v4 and v6
in sync.

I do not have plans, per se, but I have thought about IPv6 before, and
IMO we should use a mechanism for IPv6 source-selection policy that is
analogous to the mechanism I use for IPv4. My mechanism can express the
class of IPv6 source-selection policies described by RFC 3484, and more.

Dave

[Thor Lancelot Simon]

Post by David Young
As Mihai said, you can still bind any address you like. It would be easy
to extend the source-selection patch so that it considered addresses on
interfaces other than the output interface, however, I leave that up to
somebody else.

If you do this, please _do not_ make such behavior the default; you might
consider making it emit a warning. This takes us even further away from
the strong host model preferred by most network security folks, and
required by policy in some environments (I have personally had to patch
NetBSD kernels to enforce strong host semantics before a client's security
staff would allow them to be run on their network).

[David Young]

Post by Thor Lancelot Simon

Post by David Young
As Mihai said, you can still bind any address you like. It would be easy
to extend the source-selection patch so that it considered addresses on
interfaces other than the output interface, however, I leave that up to
somebody else.

If you do this, please _do not_ make such behavior the default; you might
consider making it emit a warning. This takes us even further away from
the strong host model preferred by most network security folks, and
required by policy in some environments (I have personally had to patch
NetBSD kernels to enforce strong host semantics before a client's security
staff would allow them to be run on their network).

If anybody is interested in doing this work, I may be able to help.
Somewhere I have some notes on where to enforce strong-host semantics
in the kernel.

Dave

[Daniel Carosone]

Post by David Young
link-local: 169.254/16, 224/24

Why is 224/24 (shouldn't be 224/4 ?) link-local ? Maybe you wanted 240/4 ?)

I had a similar initial reaction, but this network is for link-local
multicast.

--
Dan.

[YAMAMOTO Takashi]

Post by David Young
net.inet.ip.interfaces.ath0.selectsrc =
net.inet.ip.interfaces.sip0.selectsrc =
net.inet.ip.interfaces.sip1.selectsrc =
net.inet.ip.interfaces.lo0.selectsrc =
net.inet.ip.interfaces.pflog0.selectsrc =

i don't think it's appropriate to use sysctl for these.

(sorry for not replying in a timely manner.)

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Mihai CHELARU

Post by David Young
For review, here are my latest patches adding a mechanism
for enforcing an IPv4 source-address selection policy,
<ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.

[..]
Great work ! Thank you !
[..]

Post by David Young
preference ranks by _source preference_; lower preference
numbers are ranked more highly

Preference should do exactly the opposite. Higher preference for higher
rank. This is the logical way. If user sets an address without preference
it should default to 0.

Mihai,

(Six months later....)

I agree with you. I'm going to change the sense of 'preference', update
docs, and send a pull-up request for 4.0.

Post by Mihai CHELARU

Post by David Young
_destination address_. A category is one of
"private", "link-local", or "other". If the
categories exactly match, same-category assigns a
a link-local source with a private destination,
a private source with a link-local destination,
and a private source with an "other" destination
rank 1. All other sources rank 0.
Categories are defined as follows.
private: RFC1918 networks, 192.168/16, 172.16/12,
and 10/8,
link-local: 169.254/16, 224/24
other: all other networks---i.e., not private,
not link-local

Uhm, I don't understand this. Isn't common prefix enough ? Why is 224/24
(shouldn't be 224/4 ?) link-local ? Maybe you wanted 240/4 ? Also for
link-local I suggest adding 0/8. But the first question remains: why do we
need this ?

I don't remember if I answered this. Common prefix is not enough
because 224/24 and 169.254/16 do not have a common prefix, but they
nevertheless have "link-local" semantics, so an operator may want to
treat them alike---I do!

Can you explain a bit more about 0/8 ? ISTR that is a BSDism that
appeases dhclient somehow?

Curious whether you've used IPSELSRC any?

Dave

[Mihai Chelaru]

Post by David Young
Can you explain a bit more about 0/8 ? ISTR that is a BSDism that
appeases dhclient somehow?

I guess I've just checked RFC3330 at that time.

Post by David Young
Curious whether you've used IPSELSRC any?

Yes, since today :) I had no idea it made into -current. Could you please
document it in options(4) ?