Bugzilla – Bug 107
ARP Cache is not updated by the reception of ARP Requests packets
Last modified: 2008-07-01 13:32:20 EDT
You need to log in before you can comment on or make changes to this bug.
Two InternetNodes (node1,node2) are connected to a CSMA channel. node1 wishes to send an UDP-echo-request packet to node2. Since they are configured in the same IP network, node1 first sends an ARP Request to discover node2's MAC. Based on RFC826, when Node2 receives this ARP Request it should add an node1 MAC/IP entry to its ARP cache. Apparently, it does not because later in the simulation when node2 needs to send an and UDP-echo-reply packet to node1, it also sends an ARP Request.
Created an attachment (id=91) [details] possible patch Does this (untested) patch address the problem adequately?
(In reply to comment #1) > Created an attachment (id=91) [edit] [details] > possible patch > > Does this (untested) patch address the problem adequately? > I think that I did not implement this before because it is a classic ARP poisoning attack (sending fake arp requests).
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=91) [edit] [details] > > possible patch > > > > Does this (untested) patch address the problem adequately? > > > > I think that I did not implement this before because it is a classic ARP > poisoning attack (sending fake arp requests). > RFC 826 algorithm does not say to omit that step due to ARP poisoning. IMHO we should stick to RFCs by default, or change the behaviour to match real world implementations when most used implementation do something different. Do you know for a fact how e.g. Windows (most deployed OS) handles this scenario?
> > I think that I did not implement this before because it is a classic ARP > > poisoning attack (sending fake arp requests). > > > > RFC 826 algorithm does not say to omit that step due to ARP poisoning. IMHO we > should stick to RFCs by default, or change the behaviour to match real world yes, but RFC 826 was written in a time when arp poisoning attacks were not a concern so, that argument is not relevant. > implementations when most used implementation do something different. Do you > know for a fact how e.g. Windows (most deployed OS) handles this scenario? I thought that windows did not update its cache in this case but I don't have a machine handy to verify that it is really the case. Anyhow, I did not want to say that I was against this patch. I just meant to explain why I think it was not done that way yet.
Hi all, We had a discussion about this at the NS3 meeting today. For those not there, I went through the Linux 2.6.23 source and it does *not* update the local ARP table upon receiving a request from an unknown node. Logic in this regard is roughly: If received msg is a reply to a request I have not made, toss it If received msg is a request to me or a node for which I am a proxy Reply If requester is already in local ARP table, update timestamp So, the second node would indeed generate an ARP request despite having just gotten one from that node. After that first request it would keep updating the cache such that it did not request again as long as the dialog kept up. Thx
Small note that I think part of the reasoning for this is the ARP poisoning that Mathieu mentioned. A perhaps more pressing issue from the receiving node's viewpoint is that otherwise it'd be easy to fill its ARP table and severely cripple its ability to talk to anyone, not just spoofed nodes.
shall I close this bug as WONTFIX then ?
(In reply to comment #7) > shall I close this bug as WONTFIX then ? > +1
+1 on the WONTFIX.
Pedro is very quiet about this but I think he won't be upset if this is closed. :-) What matters here is that NS-3 simulates reality closely. If real life systems do this way, let NS-3 do it the same way... (although if NS-2 did differently we might have a consistency problem...)
added a comment to the code to point to this bug report. changeset d2d179640630