|
Bugzilla – Full Text Bug Listing |
| Summary: | ARP Cache is not updated by the reception of ARP Requests packets | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Pedro Fortuna <pedro.fortuna> |
| Component: | internet | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | gjcarneiro, tjkopena |
| Priority: | P3 | Keywords: | bug |
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://www.nsnam.org/bugzilla/show_bug.cgi?id=2483 | ||
| Attachments: | possible patch | ||
|
Description
Pedro Fortuna
2007-11-16 13:22:01 UTC
Created attachment 91 [details]
possible patch
Does this (untested) patch address the problem adequately?
(In reply to comment #1) > Created an attachment (id=91) [edit] > 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] > > 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 |