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]

Date:	Thu, 02 Jul 2009 20:14:44 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Denys Fedoryschenko <denys@...p.net.lb>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

Denys Fedoryschenko <denys@...p.net.lb> writes:

>> Having two networks:
>> 10.0.0.0/24 physical segment
>> 10.0.1.0/24 physical segment
>>
>> It is correct for proxy arp to answer to for 10.0.0.66
>> when it is plugged into the 10.0.1.0/24 network.
> It is not defined in standart, correct or not. 
>
>>
>> Because in that case 10.0.0.66 is on the wrong subnet, and your
>> network is misconfigured.
> What Linux does care about this?
> It is not police inspector to block me from taking this ip in wrong subnet.
>
> And without emotions - it is not his job to give answers for wrong request 
> (ARP Announce), from wrong ip (not linux with proxy arp enabled interface 
> subnet). Especially because there is no use for current behavior, other than 
> making problems.

There is use. Talking to the machine that is known as 10.0.0.66 when
it is plugged into the network it is configured to be on.

> And most important what you are telling violates RFC again, i finally found 
> this in RFC 1027:
>
> ..."The gateway
>     is acting as an agent for host B, which is why this technique is
>     called "Proxy ARP"; we will refer to this as a transparent subnet
>     gateway or ARP subnet gateway.
> "...
>
> "    An ARP subnet gateway implementation must not reply if the physical
>     networks of the source and target of an ARP request are the same.
>     In this case, either the target host is presumably either on the
>     same physical network as the source host and can answer for itself,
>     or the target host lies in the same direction from the gateway as
>     does the source host, and an ARP reply from the would cause a loop.
> "

This is comedy.  They are supposed to be on different physical
networks as far as linux is configured.  The fact the laptop is in the
wrong place is something else again.

As for the rest.  I am not a great expert on how Cisco configuration
works.  In your example I believe you did not place the ports on
different vlans.  If both networks are run in the same vlan and
the packets will be bridged and everything will work smoothly.

Except when you explicitly configure it.  Linux does not do anything
layer 2.  So by default when we have two interfaces coming into a linux
box we do not bridge them.

Is this perhaps where you are confused?

Eric
--
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