ARP Spoofing opcode 1 vs. opcode 2

[william1357chen]

There is a discovered issue with using spoofed ARP requests in IoT Inspector. Here is the detailed issue.

When using spoofed ARP requests (op=1), tests by @crazyideas21 have shown that there are clear packet losses compared to using spoofed ARP replies (op=2). We suspect that the spoofed ARP caches for the spoofed devices are modified back to the original unspoofed state, and why this happens is still to be investigated.

Here is why theoretically speaking, there should not be a difference between using ARP requests (op=1) vs. ARP replies (op=2). RFC 826 details the process of packet reception.

Two main points to pull from the figure above:

• Updating the sender hardware address field in ARP cache is before checking the opcode
• The opcode is only used to determine whether we need to reply

Therefore, according to the protocol, there is no difference between spoofed ARP requests (op=1) and ARP replies (op=2).

Here is the reason why we chose to use spoofed ARP requests:

• Using ARP replies in Windows 10 creates a bug that alters the host's own ARP cache

Speculations on why in practice there is a difference between ARP requests vs. ARP replies:

• When a device receives a spoofed ARP request, it also responds with a reply. If that reply was received by other devices that were also spoofed, it will change their ARP cache back to the original unspoofed state. However, this is unlikely since the Ethernet destination of these replies is directed to the host, meaning the network switch will not direct these replies to other devices.

[crazyideas21]

Will address in the next release of Inspector. In particular, will use opcode = 2 by default, but if user complains disrupted Internet, will switch to opcode = 1.

Relevant: https://github.com/nyu-mlab/iot-inspector-client/pull/118 @viz-prakash