Re: [RFC] ip / ifconfig redesign

[Jeroen Massar <jeroen@unfix.org>]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
<SNIP>
>> The association between IP addresses and links is already a bit murky.
>> Reference the arp_announce sysctl for what I mean.  I recall Dave M.
>> emphasizing on at least one occassion that IP addresses belong to
>> the _box_, not to the link.
>
> Precisely the case.  It should be the case that a box response to an
> arp on *any* interface for *any* IP address known to the box.

Thus you have the following nice setup:

10.100.10.0/24 = 10Gbit streaming network
10.100.20.0/24 = 10mbit admin network

10.100.10.1 on eth0
10.100.20.1 on eth2

Then some idiot misconfigures his client box, putting 10.100.10.42/24 on
the NIC that is supposed to be in the admin network only.
Suddenly your 10mbit link is full because the arp's get answered on this
link.

I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.

There is a low level of brokeness here already. When you have:

eth0 = 10.100.10.1/24
eth1 = 192.168.1.1/24
default route towards 192.168.1.250, forwarding enabled.
SMTP on 192.168.1.1.
Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD
chain of iptables is skipped. The packet directly comes into INPUT.
Blocking based on the decision that it is actually being forwarded is
impossible because of this, unless you do -i eth0 -d 192.168.1.1.

Combine this with the above and you can suddenly access internal IP's
when the firewall is configured correctly to block FORWARD's from the
eth1 interface and you have an internal service on 10.100.10.1. You only
have to find a way to be local on the external interface so that you can
do arp's for internal IP's. It will be loved by pesky ISP's who limit
people and disallow them to do NAT of course.

Greets,
 Jeroen


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]