[131] in linux-net channel archive
Re: ifconfig aliases
daemon@ATHENA.MIT.EDU (Alan Cox)
Wed Mar 15 15:11:20 1995
From: iialan@iifeak.swan.ac.uk (Alan Cox)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Date: Wed, 15 Mar 1995 17:20:42 +0000 (GMT)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <m0roujP-0002gOZ.ijackson@nyx.cs.du.edu> from "Ian Jackson" at Mar 15, 95 03:11:00 pm
> 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 is conventional BSD style behaviour and approved of by RFC1122.
> 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.
Yes.
> 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.
BSD and derived system compatibility is far more important, especially
as you can achieve your aim with ip firewalling.
> 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.
Its not experimental. Its got a slight bug as of 1.2.0 (see posted patch) but
its well tested code.
> 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.
Read RFC1122. The description you provide is allowed as is the Linux/BSD/
Unix/VMS/NT/.... behaviour. You need to consider how broadcast/multicast
attacks fit into this paradigm too, especially as most RPC libraries don't
know what a multicast is and treat it like a unicast attack.
> 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.
They need only enable firewalling and it should be a serious concern
for anyone building a secure system that they firewall off all ports not
being used as routine security precautions anyway.
> 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.
IPng 16 byte addresses 8)
It's simply another case where the existing code supports the requirements
without punishing anyone. Having multiple addresses per port loses you
the fast address check that ip.c does for address=received device address,
and for 99.9% of users it has no value. It is possible a minute number of
people may have a user for obscure things like address groups. They are
so few, and so unlikely that they are not most important in the list of
work on the standard kernel. If someone wants to maintain and keep current
a patch then they have the option. Without taking such decisions Linux
will end up like gnuemacs and most will suffer for the needs of the very
few. Networks are likely to increase in speed by a factor of 15-20 over
the next 2 years so performance is also a critical issue since processors
and RAM are not likely to get 20 times faster in a hurry.
Alan
