This document presents a technique to identify the correct IP to MAC address mapping when an attacker is performing ARP spoofing. It discusses limitations of existing probe packet-based detection techniques when facing a strong attacker. The proposed technique generates broadcast ARP requests to identify the correct mapping, even if the attacker can modify the protocol stack. Experimental results show the technique can correctly identify the attacker in both weak and strong attacking environments with only a small increase in network traffic overhead.

1. Identification of an Intelligent
Attacker in ARP Spoofing
Presented By :
Subhash Kumar Singh
(201011044)
Guided By :
Prof Anish Mathuria
20th Nov, DAIICT

2. Outline
●
ARP Protocol
●
Probe Packet based technique (eg. SDE)
●
Importance of identification of attacker
●
Proposed Idea
●
Results
●
Conclusion

3. Basic ARP Protocol

4. ARP Header
Hardware Type(2)
HW Len(1)
Protocol Type(2)
Pro Len(1)
Opcode(2)
Source Hardware Address(6)
Source Protocol Address(4)
Destination Hardware Address(6)
Destination Protocol Address(4)

5. Rules for Updating ARP Cache
●
●
●
For creation of new entry - when an ARP
req/rep message arrive at host a new entry is
created if the cache doesn't contain any entry
for the source IP in the received ARP packet.
Updating an entry - when an ARP req/rep
message arrive at host and the entry for the
source IP in ARP header is present then the
information in the ARP packet updated into
cache and timeout time is renewed.
Problem : ARP can't verify the sender of ARP
request/ reply packet.

6. Various techniques to secure ARP
Port Security
Binding MAC Address to switch port
Enhanced ARP[10]
Conflict resolution of MAC address based on voting
S-ARP[6]
Signing ARP replies
TARP[7]
Centrally issued ticket authentication <IP,MAC>
associations
El-Hajj et al.[3]
Uses stateful ARP cache and fuzzy logic
Trabelsi et al.[9]
Detection technique using trap ICMP ping packet and
analyze packets to varify the correct <IP,MAC> mapping
Kanamori et al.[1]
Uses ARP request packet as confirmation probe packet
Ramachandran et al.[2]
Defines types of attacker explicit and used TCP SYN
packet as confirmation probe packet

7. Probe Packet based techniques
●
●
Such technique injects a probe packet in
order to confirm the mapping of IP
address and mac address.
Probe packet can be anything :
– ARP packets
– ICMP packets
– TCP SYN packets
●
E.g. - Spoof Detection Engine (SDE)

8. Working of SDE
Host A
10.100.98.91
00:00:00:00:00:0A
ARP Req/Rep
[arp.src] <10.100.98.92, 00:00:00:00:00:0B>
Host B
10.100.98.92
00:00:00:00:00:0B
If 10.100.98.92 is new entry for ARP cache
then send TCP SYN packet
Otherwise in case of mismatch with ARP
cache, raise the spoof alarm
TCP SYN packet
eth.dst=00:00:00:00:00:0B, IP_dst=10.100.98.92, SYN
TCP SYN/ACK packet
eth.src=00:00:00:00:00:0B, IP.src=10.100.98.92, SYN/ACK
SDE uses TCP SYN packet as probe packet.

9. Attacking Model[2]
●
Weak Attacker 

●
Generate fake packets.
Can't modify protocol stack.
Strong Attacker
Generate fake packets.

Can also modify the protocol stack.

10. SDE in Weak Attacking Environment
Host A
10.100.98.91
00:00:00:00:00:0A
ARP Req/Rep
[arp.src] <10.100.98.92, 00:00:00:00:00:0C>
Attacker
10.100.98.93
00:00:00:00:00:0C
If 10.100.98.92 is new entry for ARP cache
TCP SYN packet
eth.dst=00:00:00:00:00:0C, IP_dst=10.100.98.92, SYN
eth.src=00:00:00:00:00:0C, IP.src=10.100.98.92, SYN/ACK
TCP SYN/ACK packet
10.100.98.92 !=
10.100.98.93 so SYN
packet is silently
dropped at IP layer
Host B
10.100.98.92
00:00:00:00:00:0B

11. SDE in Strong Attacker
Host B
10.100.98.92
00:00:00:00:00:0B
Host A
10.100.98.91
00:00:00:00:00:0A
ARP Req/Rep
Attacker
10.100.98.93
00:00:00:00:00:0C
[arp.src] <10.100.98.92,
00:00:00:00:00:0C>
If 10.100.98.92 is new entry for ARP cache
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<10.100.98.92, 00:00:00:00:00:00>
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<10.100.98.92, 00:00:00:00:00:00>
Broadcast ARP Requset for 10.100.98.92
ARP Reply
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>

12. Why the Identification is Important
●
Detection of attacker leaves the host
with a set of possible MAC addresses. A
victim can't determine which MAC
should be selected to associate with IP
address.

13. Problem : Limitation of Probe
packet based Detection
Techniques
●
A detecting host can not resolve the
correct IP to mac address mapping in
the case of strong attacker, because a
strong attacker can modify the protocol
stack such a way that, he can generate
appropriate response for probe packets.

14. Proposed Idea

15. Enhanced Technique
●
●
●
Probe Packet based detection
technique.
ARP request packet as probe packet.
Correctly identifies the mapping of IP
address and MAC address in both the
environments of attacker (weak and
strong attacker).

16. Assumption
●
●
●
Attacker can modify his protocol stack. It
is not necessary for attacker to follow
flow sequence of packet in any protocol.
Attcker is working in promiscuous mode.
Attacker can't control the network
devices or communication channel.

17. Working of Enhanced Technique
If there is ARP req/reply
from any host
No
Mismatch in information
of received ARP packet with
ARP chache
or ARP req/reply form
IP that doesn't exist in ARP cache
No
Packet generated form
true host
Go for Broadcast_test()
Yes
If source IP has
entry in ARP cache
Yes
Verify the mapping present
in cache for that IP

18. Verifying the mapping
present in the ARP cache
Generate Broadcast ARP request for
source IP of received ARP packet
No
Go for Broadcast_test()
any ARP response
is received
Yes
Keep the previous mapping in
the ARP cache and refresh its timeout
period

19. Broadcast_test()
Generate broadcast ARP Request
for all possible IP address in LAN
Yes
MAC address of
attacker
Got two or more
ARP reply from same
MAC address
No
Legitimate <IP , MAC>
mapping

20. In case of Strong Attacker
Host B
10.100.98.92
00:00:00:00:00:0B
Host A
10.100.98.91
00:00:00:00:00:0A
ARP Req/Rep
Attacker
10.100.98.93
00:00:00:00:00:0C
[arp.src] <10.100.98.92,
00:00:00:00:00:0C>
If 10.100.98.92 is new entry for ARP cache
Broadcast ARP Req
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
Broadcast ARP Req
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
Arp.src<10.100.98.93, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
X.X.X.X – all possible IP in the LAN

21. Hiding Probe Packets
●
Generate the ARP Request traffic
according to calculated LAN parameters
2
mean (µ) and variance (σ ) from a
random MAC address.

22. Scheduling
X = µ + σ * random_fun(0,1)

23. Advantage
●
●
●
Identify correct mapping in the case of
strong attacker.
In case, legitimate host is powered off,
attacker can't do poisoning.
Dynamic changes in mapping of a host
correctly handled.

24. Setup, Experiment and
Results

25. Test Bed
●
LAN consist of 20 PC's.
– Gateway.
– Victim (windows XP).
– Attacker (ubuntu 10.10).
●
100 Mbps Switched LAN.
●
Wireshark.

26. ARP Request traffic generated (In
Internet traffic)
(a) Normal ARP Protocol
Normal ARP Protocol
(b) Probe based techniques
X – axis time in seconds
Y – axis Number of ARP
request packet

27. ARP Request traffic generated (In
Internet traffic)
(c) Proposed Idea
X – axis time in seconds
Y – axis Number of ARP
request packet

28. System Load
(a)System Load in Non-Promiscuous mode (core-2 processor)

29. System Load
(b)System Load in Promiscuous mode (core-2 processor)

30. Conclusion
●
●
●
The proposed technique can identify the
weak and strong attacker.
We are paying some traffic overhead but
it is not significant high.
Proposed technique is backward
compatible.

31. References
●
●
●
●
●
[1]K. Masataka, K. Takashi, and Y. Suguru, “A self-confirming
engine for preventing man-in-the-middle attack(security)(internet
technology iv),” IEICE transactions on communications, vol. 87,
no. 3, pp. 530–538, 2004-03.
[2]V. Ramachandran and S. Nandi, “Detecting arp spoofing: an
active technique,” in Proceedings of the First international
conference on Information Systems Security, ICISS’05, (Berlin,
Heidelberg), pp. 239–250, Springer-Verlag, 2005.
[3] W. El-Hajj and Z. Trabelsi, “Using a fuzzy logic controller to
thwart data link layer attacks in ethernet networks,” in WCNC, pp.
2547–2552, 2007.
[4] W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols.
Addison Wesley, 1994.
[5] C. L. Abad and R. I. Bonilla, “An analysis on the schemes for
detecting and preventing arp cache poisoning attacks,” in
Proceedings of the 27th International Conference on Distributed
Computing Systems Workshops, ICDCSW ’07, (Washington, DC,
USA), pp. 60–, IEEE Computer Society, 2007.

32. Cont..
●
●
●
●
●
[6] D. Bruschi, A. Ornaghi, and E. Rosti, “S-arp: a secure
address resolution protocol,” in Proceedings of the 19th
Annual Computer Security Applications Conference,
ACSAC ’03, (Washington, DC, USA), pp. 66–, IEEE
Computer Society, 2003.
[7] W. Lootah, W. Enck, and P. McDaniel, “Tarp: Ticketbased address resolution protocol,” Comput. Netw., vol. 51,
pp. 4322–4337, Oct. 2007.
[8] Z. Trabelsi and H. Rahmani, “Detection of sniffers in an
ethernet network,” in ISC, pp. 170–182, 2004.
[9] Z. Trabelsi and K. Shuaib, “Spoofed arp packets
detection in switched lan networks,” in SECRYPT, pp. 40–
47, 2006.
[10] S. Y. Nam, D. Kim, and J. Kim, “Enhanced arp:
preventing arp poisoning-based man-in-the-middle
attacks,” Comm. Letters., vol. 14, pp. 187–189, Feb. 2010.

33. Cont..
●
●
●
●
[11] B. Issac, “Secure arp and secure dhcp protocols to
mitigate security attacks,” I. J. Network Security, vol. 8, no.
2, pp. 107–118, 2009.
[12] Z. Wang and Y. Zhou, “Monitoring arp attack using
responding time and state arp cache,” in ISNN (4), pp.
701–709, 2009.
[13] M. V. Tripunitara and P. Dutta, “A middleware approach
to asynchronous and backward compatible detection and
prevention of arp cache poisoning,” in Proceedings of the
15th Annual Computer Security Applications Conference,
ACSAC ’99, (Washington, DC, USA), pp. 303–, IEEE
Computer Society, 1999.
[14] V. Goyal and R. Tripathy, “An efficient solution to the
arp cache poisoning problem,” in Proceedings of the 10th
Australasian conference on Information Security and
Privacy, ACISP’05, (Berlin, Heidelberg), pp. 40–51,
Springer-Verlag, 2005.

34. Thanking You...

35. In case of Weak Attacker
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
Attacker
10.100.98.93
00:00:00:00:00:0C
[arp.src] <10.100.98.92, 00:00:00:00:00:0C>
If 10.100.98.92 is new entry for ARP cache
Broadcast requst for all possible IP
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
ARP Reply
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
Host IP doesn't
matches with
destination IP in the
received ARP header,
so drop ARP Request
Host B
10.100.98.92
00:00:00:00:00:0B
ARP Reply
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
X.X.X.X – all possible IP in the LAN