[132] in linux-net channel archive
Re: ifconfig aliases
daemon@ATHENA.MIT.EDU (Ian Jackson)
Wed Mar 15 15:19:03 1995
Date: Wed, 15 Mar 95 15:11 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: iialan@iifeak.swan.ac.uk (Alan Cox), elias@power.net (Elias Levy),
linux-net@vger.rutgers.edu
Alan Cox writes ("Re: ifconfig aliases"):
> [Elias Levy writes:]
> > Is there any reason why we can implement interface aliases
> > like in SunOs (or is it Solaris?)? Just wondering, since I was setting
> > up a machine with multiple httpd server that bind to different addresses
> > using the dummy modules. The sun aproach seems much clearner tough.
>
> Go ahead - make my day. Its all semantics and what ifconfig chooses to show
> you really. For internal speed the BSD approach is not so good - it has to
> search a linked list of addresses for each port each time.
Umm, I take it from the above that you mean that one should use the
`dummy' driver.
I don't think this will work right, when another problem is fixed.
I'll describe the other problem first.
Currently, if you have a multi-homed host which has packet forwarding
disabled Linux still `virtually' forwards packets which arrive on one
of its interfaces to the other.
This means that the local interface address on which a connection
arrives can not be used as a security check, because sites on one
`side' of the machine can pretend to be on the other if they can get
misaddressed packets to the Linux machine's interface.
Eg, if you have a private link to a machine you trust, and are also on
an untrusted Ethernet, people on the Ethernet can persuade your Linux
system that their connections are really coming from a machine on the
private network, simply by adding an entry to their ARP table linking
your machine's private address and its public Ethernet MAC address.
Hypothetically the Linux system is not supposed to be routing between
the two networks - perhaps the trusted machine is also on the
untrusted Ethernet, and the private network is used to provide
physical and logical separation for high-sensitivity, high-security
traffic.
Now, you might argue that if I want this functionality I should enable
IP firewalling, however that is still experimental, costs more kernel
code, and is probably overcomplicated for my application.
The conclusion I come to is that packets which arrive on the `wrong'
interface for their destination address should be discarded (perhaps
generating an ICMP message) unless you have CONFIG_IP_FORWARD enabled.
If this is done then simply adding a new dummy interface won't provide
the `ifconfig alias' functionality, because the packets will be
arriving on the real interface which is supposed to have the alias,
and will be discarded because they don't match its address.
(Currently all arriving packets are checked against all local
interface addresses even if CONFIG_IP_FORWARD is not set.)
Asking the user to enable CONFIG_IP_FORWARD in this situation is
broken IMO; if nothing else I can see situations where one might want
both an interface on a private network which is completely trusted and
also several virtual interfaces on a single physical interface to an
untrusted internet.
Clearly a Linux system which is acting as an IP-level router as well
as a firewall needs the IP firewall code; however this is not the case
in the examples I've described. Asking the user to enable both IP
forwarding and IP firewalling, when in fact they wanted neither and
were just after `sensible' behaviour, seems to me to be a bad thing.
Regarding your performance concern: I don't think we need a linked
list of addresses per interface. Surely a small table will do ? If
the table turns out to be too small we can have a linked list of
tables. The code for the linked list of tables can be left as an
exercise to someone who needs more than (say) 5 address/mask pairs per
interface, so you don't have to write it, and it could be compiled out
for most people.
I say address/mask pairs because I it might be useful in some
situations to have a single machine have a large range of `local' IP
addresses and it seems silly to rule it out. Alternatively you could
take the view that that would encourage IP number space exhaustion
(even with IPng 8-byte addresses) and so decide not to support it.
Ian.
