netdev - Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200907012201.13760.denys@visp.net.lb>
Date:	Wed, 1 Jul 2009 22:01:13 +0300
From:	Denys Fedoryschenko <denys@...p.net.lb>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote:
> The only case where I can imagine proxying the default route would even
> approach being correct is on a point to point link.  But that seems
> pointless as you could simply have a default route to the other side.
>
> Eric

It seems Linux proxy_arp behavior is also RFC 1027 non-conformant.

Quote from RFC:

    In 4.3BSD (and probably in other operating systems), a default route
    is possible.  This default route specifies an address to forward a
!   packet to when no other route is found.  The default route must not
!   be used when checking for a route to the target host of an ARP
!   request.  If the default route were used, the check would always
    succeed.  But the host specified by the default route is unlikely to
    know about subnet routing (since it is usually an Internet gateway),
    and thus packets sent to it will probably be lost.  This special
    case in the routing lookup method is the only implementation change
    needed to the routing mechanism.



If i have linux host with 
eth0 10.0.0.1/24
eth1 10.0.1.1/24

sysctl -w net.ipv4.conf.eth1.proxy_arp=1

from other host in same ethernet segment eth1

Xpernet_137 ~ # arping -I eth1 2.4.6.8
ARPING to 2.4.6.8 from 1.0.0.1 via eth1
Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms
Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms

And RFC define to not do that (use default route for proxy_arp).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html