Bug 2483 - ARP Request reception : RFC 826 compliant
ARP Request reception : RFC 826 compliant
Status: PATCH PENDING
Product: ns-3
Classification: Unclassified
Component: internet
ns-3-dev
All Linux
: P5 normal
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-23 09:40 UTC by Seb
Modified: 2016-11-05 19:53 UTC (History)
2 users (show)

See Also:


Attachments
Tar archive containing modifications on arp-cache.h, arp-cache.cc and arp-l3-protocol.cc (10.00 KB, application/x-tar)
2016-08-23 09:40 UTC, Seb
Details
New patch - slightly simplified (5.17 KB, patch)
2016-11-05 12:24 UTC, Tommaso Pecorella
Details | Diff
New patch - slightly simplified (and working) (5.23 KB, text/plain)
2016-11-05 13:44 UTC, Tommaso Pecorella
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Seb 2016-08-23 09:40:53 UTC
Created attachment 2554 [details]
Tar archive containing modifications on arp-cache.h, arp-cache.cc and arp-l3-protocol.cc

Hello everybody,

According to the RFC 826 and the Linux kernel, we propose a patch to solve the bug 107 during the ARP request reception.
Comment 1 Tommaso Pecorella 2016-11-05 12:21:50 UTC
Hi Sebastien,

I'm currently checking this enhancement, and I have a question.

Back when bug #107 was opened, the conclusion was the opposite: i.e., that the Linux kernel is ignoring the ARPs requests from unknown nodes.

I'm up for re-checking this, but I'd need a clarification, since it seems that you have already gone through the kernel.

We have 3 cases:
1) ARP request - actually we don't change our ARP table, and you propose to fill it instead, as RFC 826 suggests.
2) ARP reply - 2 sub-cases.
2a) ARP reply and we did a request - fill the table
2b) ARP reply and we did NOT do a request - ignore gratuitous ARP replies because they could be an ARP poisoning.

About 2b I'm seriously tempted to add an attribute to change this behaviour. If the ARP poisoning is monitored by a proper IDS, the hosts shouldn't throw away gratuitous ARP replies because they could be simply from a host recovering from a NIC failure.

About case 1, are you sure that the Linux kernel accepts them? It goes kinda in the opposite direction of bug 107 kernel check...

Thanks, T.
Comment 2 Tommaso Pecorella 2016-11-05 12:24:53 UTC
Created attachment 2652 [details]
New patch - slightly simplified

The new patch has the same effect, but with no changes in the ArpCache class
Comment 3 Tommaso Pecorella 2016-11-05 13:44:14 UTC
Created attachment 2654 [details]
New patch - slightly simplified (and working)
Comment 4 Tom Henderson 2016-11-05 16:46:45 UTC
(In reply to Tommaso Pecorella from comment #1)

> 
> About case 1, are you sure that the Linux kernel accepts them? It goes kinda
> in the opposite direction of bug 107 kernel check...

I just did a test on a Linux kernel 4.4.  Reception of an ARP request puts a temporary entry in the ip neighbor table in state 'DELAY' and starts a 5 second timer.  The ARP reply uses the MAC that was in the request, so it is sent immediately.  However, after 5 seconds, the recipient will ARP to check the entry in state DELAY, and move it to REACHABLE if the ARP succeeds, or remove if not. 

So this patch makes it more RFC 826 compliant but suppresses the ARP exchange that occurs later to validate the entry.
Comment 5 Tommaso Pecorella 2016-11-05 19:53:26 UTC
(In reply to Tom Henderson from comment #4)
> (In reply to Tommaso Pecorella from comment #1)
> 
> > 
> > About case 1, are you sure that the Linux kernel accepts them? It goes kinda
> > in the opposite direction of bug 107 kernel check...
> 
> I just did a test on a Linux kernel 4.4.  Reception of an ARP request puts a
> temporary entry in the ip neighbor table in state 'DELAY' and starts a 5
> second timer.  The ARP reply uses the MAC that was in the request, so it is
> sent immediately.  However, after 5 seconds, the recipient will ARP to check
> the entry in state DELAY, and move it to REACHABLE if the ARP succeeds, or
> remove if not. 
> 
> So this patch makes it more RFC 826 compliant but suppresses the ARP
> exchange that occurs later to validate the entry.

Mmm... this makes sense. It is also explained here:
http://linux-ip.net/html/ether-arp.html

I'm just wondering if an L4 event (e.g., a successful TCP connection) could change the entry from DELAY to REACHABLE.
Actually we do update the entries reachability when we receive valid L3 packets - it is a clearly described thing in IPv6 RFCs and it has been validated by experiments in IPv4.

I'd ask Sebastien if he can improve the patch in this sense.