Message-ID: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk>
From: Richard Underwood <richard@aspectgroup.co.uk>
To: "'David S. Miller'" <davem@redhat.com>,
       Stephan von Krawczynski <skraw@ithnet.com>
Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com,
       lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl,
       marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org,
       layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices
Date: Tue, 19 Aug 2003 13:02:20 +0100
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2871
Lines: 71

David S. Miller wrote:
>
> > _And_ you did not explain so far why these implementations should
> > not be RFC-conform or else illegal.
> 
> Both responding and not responding on all interfaces for ARPs
> is RFC conformant.  This means both Linux and other systems
> are within the rules.
> 
	Firstly, can I point out that you have consistently talked about
REPLIES when everyone else has been talking about REQUESTS. I suspect that
this may be confusing more people than you realise.

	The RFC I quoted (985) says the ARP packets generated by Linux
should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
implementations that obey it for perfectly valid security reasons.

> Under Linux, by default, IP addresses are owned by the system
> not by interfaces.  This increases the likelyhood of successful
> communication on a subnet.
> 
	This is crap.

	ARP is local to a broadcast net. The ARP standard explicitly
prohibits responding to an ARP request on a different interface.

	If you broadcast a request asking for a reply on an entirely
different subnet, you're asking for trouble. You REDUCE the likelyhood of a
successful ARP reply, not increase it.

	All you can possibly achieve by sending REQUESTS from the wrong IP
number is assist screwed up networks where you've got multiple subnets on
the same copper and cause a shed-load of security issues.

> For scenerios where this doesn't work, we have ways to make the
> kernel behave the way you want it to.
> 
	There are many ways of "fixing" it. I've chosen a static ARP entry
for my next-hop. I really don't care. The issue is that the Linux ARP code
is, apparently by design, flawed.

> There is no discussion about changing the default, because that
> might break things for some people.  So this discussion is pretty
> useless.

	Can you give one good example where this is the case?

	What makes all this worse is that once an ARP request has been
queued using the wrong IP number, further connections that would otherwise
have generated a valid ARP request will be blocked as Linux won't queue a
second request - despite it coming from a different IP number.

	This means that connectivity is non-deterministic, and while
everything may work for 99.9% of the time, when an ARP entry gets deleted
and the next ARP request comes from the wrong IP number you lose
connectivity.

	I wonder how many unsolved random network problems there have been
due to this. "Just reboot it, it'll work again." Great!

	If you insist on leaving the code as it is, at the very least allow
multiple incomplete ARP requests, one per source IP.

	Thanks,

		Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/