2

I am trying to understand ARP and ARP cache poisoning. Will a host updates its cache if it gets an ARP response even if it didnt send a request? If yes, is there any particular reason it is designed like that?

Also I have one more question. In case of ARP cache poisoning, does the malicious host flood the network with ARP responses or respond only when some one sends out a request

user1004985
  • 125
  • 4
  • It depends on the device / OS. Some switches will do, some OSes will filter packet on the firewall before it's even examined by the system. – Andrew Smith Jul 06 '12 at 09:45

2 Answers2

2

Most of the time, a device will accept unsolicited ARP replies, to allow machines to notify others when the MAC address for an IP address changes. The methods of ARP cache poisoning are varied, but typically you don't have to flood the network, just send them periodically to ensure that the ARP cache doesn't expire and the other machine does an ARP request of it's own.

womble
  • 95,029
  • 29
  • 173
  • 228
0

Will a host updates its cache if it gets an ARP response even if it didnt send a request? If yes, is there any particular reason it is designed like that?

Yes. THe idea is that for example a workstation picks up all addresses of servers even if not needing them at the moment. Especially the AP address of the gatedway of the network and local switches. This reduces network traffic in a pre-switch era because a workstation gets all that when someone ele asks. The idea is that your local broadcast domain is trusted anyway, so poisoning is not an issue, and it reduces traffic as the answer is going to be valid anyway. The trust assumption is true in any corporate network - mostly- but obviously breaks apart in hosting centers, for example.

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • But isnt ARP Response a unicast and sent to only the one who requests. In that case, how a work station is expected to pickup addresses of other devices which it may be needing future? – user1004985 Jul 06 '12 at 10:05
  • Ah, but when ARP Was designed, noone had a switch (not sure they even ecisted). A Hub sends all packets to everyone ;) Today, yes, it makes little sense - in a Hub world 20 years and more ago, it was a significant saving. – TomTom Jul 06 '12 at 10:07
  • Always when you see a VERY stupid design decision, look at the timeline. A lot of stuff goes back way more than most people today know, and it is amazing what limitations one had to work around 10 or 20 years ago. The first LOCAL NETWORK I worked on had 128kbit ;) (AppleTalk, I think). – TomTom Jul 06 '12 at 10:14
  • So the implementation of ARP on modern OS can be changed and make it more like DNS for example in the sense that it will accept responses only if it has requested. This way we can prevent arp cache poisoning? – user1004985 Jul 06 '12 at 10:19
  • Not TOTALLY sure. Theoretically it COULD - just someone has to do it. WHle there still MAY BE some odd hubs (never seen one recently) the change MAY be fine - just I am not a specialist for low level Ethernet. BUt yes, logically it could be designed differently these days. – TomTom Jul 06 '12 at 10:35
  • 1
    @Tomtom, a hub has nothing to do with it. There are two conditions for a station to update its arp cache: 1) ARP dmac is unicast to the station in question. 2) ARP dmac is a broadcast address. If you have a 10 stations on a hub and a unicast ARP reply is sent, only the station addressed in the reply will update their cache. – Mike Pennington Jul 06 '12 at 10:43
  • @MikePennington It has. In a world without switches with thousands of machiens in a broadvcast domain (seen that) you want to use broadcasts for ARP and have all machines update the cache. Today you COULD design it like DNS (unicast only) without problems - 20 years ago with only hubs and some ridiculous large broadcast domains, everyone saw all ARP packets anyway - and that reduced the amount of ARP requests on the network. SImple like that. Saying hubs has nothing to do with that is - surreal at best. – TomTom Jul 06 '12 at 10:51
  • @tomtom, I suggest you read up on how ethernet works before you spread more misinformation to unsuspecting people. ARP replies are unicast. An ethernet NIC doesn't know whether it is attached to a hub or a switch. When the NIC sees a unicast frame and the DMAC does not belong to the NIC, it will *not* accept it. Therefore, unicast ARP replies to a single station on a hub containing 10 stations will not influence the ARP tables of the other 9 stations on the hub. – Mike Pennington Jul 06 '12 at 10:57
  • @MikePennington Well, maybe you come to our planet then before explaining how things work on yours. My computer arp cache picks up all kinds of machines in the network it is NEVER TALKING TO. Which indicates (a) it picks up ARP information it never asked for and (b) quite a lot of ARP running around is multicast. May be your ethernet works differently, but most people here live on Earth, SOlar System, and here we have the behavior of machines getting ARP resonses for addresses they never asked for AND USING THEM. – TomTom Jul 06 '12 at 11:05
  • 1
    @tomtom I have to agree with MikePennington on this one. Your PC is picking up other MAC addresses from servers and workstations that are sending broadcast/multicast packets. ARP replies are unicast. ARP poisoning works by sending ARP replies to either the unicast or the broadcast address for specific MAC/IP combinations. In today's world and in days of yore a PC will have the same entries in it's ARP cache regardless of it being connected to a hub or switch. Quite the harsh response I might add. – Paul Ackerman Jul 06 '12 at 11:47
  • 1
    @tomtom, please calm down. Remember, I said **ARP replies** are *unicast*. I did not discuss ARPs bound to multicast mac-addresses (not commonly seen, but used by some clustering technologies), and I did not mention **ARP requests** (which are broadcast and may populate an ARP cache, unsolicited) – Mike Pennington Jul 06 '12 at 11:56