Re: [2.4 PATCH] bugfix: ARP respond on all devices

• Previous message: Muli Ben-Yehuda: "Re: [PATCH] scsi.h uses "u8" which isn't defined."
• Maybe in reply to: Pekka Savola: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Next in thread: Carlos Velasco: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Reply: Carlos Velasco: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Reply: Alan Cox: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Sun, 17 Aug 2003 15:09:57 +0200
To: "Lamont Granquist" <lamont@scriptkiddie.org>, "Bill Davidsen" <davidsen@tmr.com>

I have received reply from Cisco:

*********** BEGIN FORWARDED MESSAGE ***********

On 06/08/2003 at 11:40 Oscar Madrid <omadrid@cisco.com> wrote:

>
>My name is Oscar Madrid and I'm Luis Isselin's escalation engineer.
I've
>decided to answer to this case straight as this is a question of
whether
>or not Cisco is following a standard.
>
>I can only think of one scenario where an arp request would come in
from
>192.168.140.x to a router interface that has 192.168.128.1. That one
>scenario is a misconfiguration.
>ARP is designed to find the next hop on a LAN. If the host has an IP
>address of 192.168.140.140 and wants to get to 192.168.128.1, it will
have
>to have a default gateway configured.
>This default gateway would have to be on the same logical local
network.
>
>Now, lets say that the host has an IP address of 192.168.140.140/17
which
>will include both 192.168.128.x and 192.168.140.x. This would still
be a
>misconfig as the router is not on the same subnet. (meaning the router
>does not have the same /17 mask. The host can see the router, but the
>router cannot see the host).
>
>You could, in theory, say that we're not following "similar algorithm"
in
>the RFC as we check the source, but this is more for a sanity check as
if
>it was a perfect world and everything is configured properly and there
>were no such things as bad implementations of TCP/IP stacks, then we
>wouldn't need to check.
>
>If the router for some reason was responding to the ARP broadcast, how
>would anyone know where the packet came from since the network is not
>being advertised as connected to this router? Meaning, how would a
return
>packet make it back to the host? The router doesn't "see" the host in
his
>logical network therefore it cannot communicate with it.
>
>I believe that reason we do the sanity check is because of basic IP
>routing. If the source is not from an IP address on the interface we
>received it on, we cannot reply to that IP address. It is simple as
that.
>As I stated, ARP is designed to be used on a LAN. This means that all
>stations that send/receive ARP packets are on the same subnet. This
is
>the reason we do the check.
>
>Please also note another portion of the RFC 0826 in question:
>
>[The purpose of this RFC is to present a method of Converting
>Protocol Addresses (e.g., IP addresses) to Local Network
>Addresses (e.g., Ethernet addresses). This is a issue of general
>concern in the ARPA Internet community at this time. The
>method proposed here is presented for your consideration and
>comment. This is not the specification of a Internet Standard.]
>
>When it is talking about Local Network Addresses, that means IP
addresses
>on the same network. This is why we can perform the checks we
perform in
>our IOS.
>
>The point of the check would be to verify that the hosts are
configured
>correctly. There is no case where a properly configured host should
ever
>send a ARP request for an IP address on a different subnet.
>
>The best example I can point out is this:
>Ethernet is a Broadcast network which uses ARP to find HW addresses
of
>other IP addresses on the same broadcast network. If the IP address
is
>not on the same network, then the host/router/client needs to find the
>gateway which is on the local network.
>
>Basic and proper implementations of the TCP/IP stack should never ARP
out
>for a device that it is not located on the same logical network the
host
>is, the reason for this being they cannot communicate directly unless
a
>gateway is involved. The only ARP request a host should send in this
case
>is for its gateway that should also be a "local" device to the host
(same
>network).
>
>I hope this clears up the reson why Cisco's ARP implementation has
this
>safeguard you have found along with several others, HOWEVER, please
refer
>to RFC 1027, (http://www.ietf.org/rfc/rfc1027.txt) and under section
2.4,
>it contains the following paragraph:
>
>[If the IP networks of the source and target hosts of an ARP request
>are different, an ARP subnet gateway implementation should not
>reply. This is to prevent the ARP subnet gateway from being used to
>reach foreign IP networks and thus possibly bypass security checks
>provided by IP gateways. ]
>
>I would also ask you if you would be so kind to send me the link to
the
>netdev list of linux kernel you are making mention to so I can
escalate it
>and respond to the linux community if higher up is deemed up necesary.
>
>Best Regards,
>
>
>
>Oscar Madrid
>Customer Support Engineer
>Routing Protocols Team
>Cisco Systems
>omadrid@cisco.com
>
>
>Open a TAC case on the web for faster response!
www.cisco.com/tac/caseopen
>Visit the TAC Web Site for quick access to technical support!
>www.cisco.com/tac
>Use the new TAC Advanced Search to find information fast!
>www.cisco.com/tac/advancedsearch
>
>

*********** END FORWARDED MESSAGE ***********

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

• Previous message: Muli Ben-Yehuda: "Re: [PATCH] scsi.h uses "u8" which isn't defined."
• Maybe in reply to: Pekka Savola: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Next in thread: Carlos Velasco: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Reply: Carlos Velasco: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Reply: Alan Cox: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]