Although the Internet protocol (IP) has become widely successful, it has led to many security issues. Many of these security issues are related to illegal host access. An address resolution protocol (ARP) spoofing attack is another security issue related to an illegal host access. This paper deals with the prevention of these ARP spoofing attacks.

ARP provides dynamic mapping between two different forms of addresses: the 32-bit IP address of the network layer and the 48-bit medium access control (MAC) address of the data link layer [1]. A host computer finds the MAC address of a default gateway or of the other hosts on the same subnet by using ARP, after which it can send data packets [2]. However, recently, there have been a considerable number of network attacks using ARP. The types of these attacks can vary from attacks interfering with the network operations of the host to spoofing attacks that allow the attacker to intercept data frames. Man in the middle (MITM) attacks are a form of potential spoofing attacks. An MITM attack means that the attacker intercepts the data frames of the target host, modifies them maliciously, and then forwards these modified frames [3]. A number of solutions have been proposed to prevent ARP spoofing attacks [4]. However, the existing solutions require additional systems or are not perfectly compatible with the current ARP.

In this paper, a modified ARP algorithm to prevent spoofing attacks is proposed. The proposed algorithm is backward compatible with the current ARP and can effectively prevent ARP spoofing attacks.

The rest of this paper is organized as follows: Section II describes the ARP operation and ARP spoofing attacks. In Section III, the proposed ARP protocol is described. In Sections IV and V, implementation of the proposed algorithm and test results for its verification are discussed. The conclusion is presented in Section VI.

An Ethernet ARP frame format is illustrated in Fig. 1(a). The Ethernet header includes the Ethernet destination address, Ethernet source address, and frame type. The Ethernet address, also known as the MAC address, is a 48- bit address. In the case of an ARP frame, the value of the frame type field is ‘0x0806.’ The ARP header includes the type of hardware address (its value for Ethernet is 1), the type of protocol address (its value for an IP address is 0x0800), the size of the hardware address (6 bytes for Ethernet), the size of the protocol address (4 bytes for an IP address), and the operation field (1 for an ARP request and 2 for an ARP reply). The payload fields of an ARP frame include the sender’s Ethernet address, sender’s IP address, target’s Ethernet address, and target’s IP address. With the ARP request frames, all the fields are filled in except the target Ethernet address. The target host receiving the ARP request fills in the target Ethernet address field with its Ethernet address, swaps the two sender addresses with the two target addresses, sets the operation code (OP) field to 2, and sends the ARP reply [2, 5].

Fig. 1(b) shows a normal ARP operation. First, host A broadcasts an ARP request to find out host B’s MAC address for the destination IP [192.168.0.1]. Hosts B and C receive host A’s ARP request, but host C drops the request because the target IP address is not the same as its IP address. Secondly, host B confirms that the target IP address of the ARP request is the same as its own IP address and sends out a unicast ARP reply to host A. Thirdly, host A, having received the ARP reply from host B, saves both the MAC address and the IP address of host B in its ARP table. Finally, host A sends IP packets to host B referencing the ARP entry that includes host B’s MAC address and IP address.

During ARP spoofing attacks, an attacker periodically sends out a forged unicast (or broadcast) ARP request and reply. The victim receiving the forged ARP request or reply then adds the poisoned ARP entry to its ARP table. The victim sends IP packets to the attacker referring to the poisoned ARP entry rather than the normal target host. ARP request attacks and ARP reply attacks are described in the following paragraphs separately [6]. ARP attacks are illustrated in Fig. 2.

1) Forged ARP Request Attacks

During a normal ARP operation, shown in Fig. 1(b), host B saves host A’s MAC address and IP address at the time of receipt of the ARP request from host A. Thus, the attacker sends out a forged ARP request by unicast or broadcast to the normal host, and thus, the normal host makes a poisoned ARP entry of only the forged ARP request. An ARP request attack is illustrated in Fig. 2(a). Hosts A and B are legitimate hosts, and host M is the malicious host. First, host M sends out a unicast ARP request forging host B’s IP address to host A. The forged ARP request includes host B’s IP address in the sender’s IP address field and host M’s MAC address in the sender’s MAC address field. Secondly, host A stores the sender’s IP address and the MAC address of the forged APP request in its ARP table. The stored ARP entry is [192.168.0.1] (host B’s IP address) on “01:23:45:67:89:EF” (host M’s MAC Address). Thirdly, host A sends out an ARP reply to host M. Finally, the MAC address for the IP address [192.168.0.1] is the poisoned ARP entry in host A’s ARP table. If host A sends out IP packets with a destination IP address [192.168.0.1], these packets are sent out to host M, not host B.

2) Forged ARP Reply Attacks

The attacker sends out a forged unicast ARP reply to a specific host, and then, the host saves the sender’s MAC address and the IP address of the forged ARP reply in its ARP table irrespective of whether a reply was solicited. Therefore, the normal host may refer to the poisoned entry. Fig. 2(b) shows an ARP reply attack. Firstly, host M sends out a unicast ARP reply forging host B’s IP address to host A. Secondly, host A creates or updates a forged ARP entry from the malicious ARP reply of host M. Thirdly, host A refers to the poisoned ARP entry and sends out the frame; then, all frames that must be sent to host B are delivered to host M. Hosts mostly communicate with servers or hosts on other subnets. Thus, an attacker generally forges a gateway’s IP address for an ARP spoofing attack [7].

In this section, a modified ARP algorithm for the prevention of ARP spoofing attacks, described in Section II, is proposed. There are two main differences between the proposed ARP algorithm and the original ARP algorithm. The first difference is that the proposed ARP algorithm sends out broadcast ARP replies. This is a procedure wherein other hosts verify whether the mapping of the MAC address and IP address in the ARP reply is forged or not. The second difference is the new ARP message type, defined as an ARP notification.

The function of the ARP notification is to notify other hosts of the forged address. In other words, normal hosts can receive all ARP replies and thereby detect an ARP spoofing attack, and the host detecting the attack broadcasts the ARP notification. Hosts receiving an ARP notification do not save the relevant address in the ARP table.

Fig. 3 shows an overview of the ARP algorithm proposed in the study. Firstly, host M, the attacker, transmits the forged ARP request (or ARP reply), usually by unicast. Secondly, host A, the victim, checks whether its IP address is the same as the target IP address of the ARP request frame from host M. If it is the same, host A adds the sender’s MAC address field and IP address field to its processing table entry (PTE) table. Then, host A broadcasts an ARP reply in order to verify the sender’s addresses and starts its PTE timer. Thereafter, hosts B and C receive the broadcast ARP reply from host A. Hosts B and C can detect the presence of an ARP spoofing attack if host B(or host C)’s IP address is the same as the target IP address but its MAC address is different from the target MAC address. Thus, hosts B and C broadcast an ARP notification in the event of attack detection. Finally, host A receives the broadcast ARP notification from host B or host C prior to timeout and then, deletes the relevant entry from its PTE table. If no ARP notification arrives prior to the timeout, host A saves the PTE in its ARP table.

The frame format of an ARP notification is the same as that illustrated in Fig. 1(a), and the operation value is defined as 0x0B. The MAC address of the suspected attacking hosts is entered into the target MAC address field of the ARP notification. The IP address of the victim is entered into the target IP address field of the ARP notification. The host receiving the ARP notification does not create or update the forged address in its ARP Table. Consequently, the function of the ARP notification is to prevent ARP spoofing attacks. Table 1 shows the state transition table of the proposed ARP algorithm.

*1:      i. Send ARP Request(M[This Host], IP[This Host], 0, IP[Requested Host]) to Ether(Bca, M[This Host]);      ii. Requested.IP[Requested Host] = TRUE;

*2:      i. If(IP[S] == IP[This Host])          · Send ARP Notification(M[This Host], IP[This Host], M[S], IP[S]) to Ether(Bca, M[This Host]);      ii. Else if(IP[T] == IP[This Host])          · Send Reply(M[This Host], IP[This Host], M[S], IP[S]) to Ether(Bca, M[This Host]);          · Save M[S], IP[S] into PTE;          · Start Timer;          · PTE for “M[S], IP[S]”.next state = Wait;

*3:      i. If(Requested.IP[IP[T]] == TRUE)          /* Normal Reply by solicitation */          · Save M[S], IP[S] into PTE;          · Start Timer;          · PTE for “M[S], IP[S]”.next state = Wait;          · Requested.IP[IP[T]] == FALSE;      ii. Else if(IP[T] == IP[This Host])          /* Unsolicited ARP reply */          · Send Received Reply frame to Ether(bca, M[This Host]);          · Save M[S], IP[S] into PTE;          · Start Timer;          · PTE for “M[S], IP[S]”.next state = wait;      iii. Else if(IP[S] == IP[This Host])          · Send ARP Notification(M[This Host], IP[This Host], M[T], IP[T]) to Ether(Bca, M[This Host])

*4:          If(PTE for “M [S], IP[S]”.next state == Wait)          · Purge the entry in PTE;

*5:          If(PTE for “MS[S], IP[S]”.next state == Wait)          · Save M[S], IP[S] into ARP Table;          · Purge the entry in PTE;

The ARP source code is generally included in the kernel of an operating system. The ARP source code included in the kernel must be modified in order to implement the proposed algorithm. Thus, an ARP source in Linux Kernel was used for the implementation of the proposed ARP algorithm; this was done because Linux is an open-source operating system [8-10]. Modification of the ARP code can lead to frequent replacement of the kernel image. Thus, embedded systems are used for development convenience [11]. Embedded systems based on the ARM 6410 CPU were used. The kernel that was ported to the ARM 6410 board was Linux Kernel version 2.6.21. In this section, the original ARP source code is described, and then, the modified code to implement the proposed algorithm is described in detail.

“arp_tbl” as the ARP table is declared by “struct neigh_ table” in the ARP instance of Linux kernel 2.6.21, and the functions called for ARP processing are as shown in Fig. 4 [8, 9].

As shown in Fig. 4, the ARP frames are processed by the function arp_process(). The proposed algorithm to be implemented is mostly related to this function.

In this study, the ARP notification frame’s OP code was defined as ARPOP_NOTIFY (11), and the modified arp_process() function was mainly used for implementing the proposed algorithm. Management functions, timer, and structure for the PTE table were also implemented.

· sip: sender’s IP address· sha: sender’s MAC address· tip: target’s IP address· tha: target’s MAC address· myip: this host’s IP address· myha: this host’s MAC address

The modified arp_process() function will receive ARP_ REQUEST frame, ARP_REPLY frame or ARP_NOTIFY frame and the processing flow of each frame is illustrated in Fig. 5.

1) ARP Request Frame Processing Shown in Fig. 5(a)

· 2) to 3): If sip is the same as myip (the host’s IP address), the host broadcasts an ARP notification frame due to an attack.· 4) to 6): If tip is the same as myip, the host broadcasts an ARP reply. Then, the host adds sha and sip to the PTE entry and starts the PTE timer.

2) ARP Reply Frame Processing Shown in Fig. 5(b)

· In cases 2), 3), and 4), suppose that (tip == myip) and Solicited.IP: The ARP reply is normally the solicited frame. Thus, an ARP reply including sha and sip is added to the PTE table, and the PTE timer is started and counts down until timeout.· In cases 2), 5), and 6), suppose that (tip == myip) and (tha == myha): This is an unsolicited ARP reply. Thus, the ARP reply is retransmitted by broadcast for its verification from other hosts. Then, sha and sip are added to the PTE table, and the PTE timer is started.· In cases 2), 5), and 7), suppose that (tip == myip) and (tha != myha): This is an ARP reply attack using myip (this host’s IP address), and the host broadcasts an ARP notification.· In cases 8) and 9), suppose that (sip == myip) and (sha != myha): This is an ARP reply attack and the host broadcasts an ARP notification.

3) ARP Notification Processing Shown in Fig. 5(c)

· When it receives an ARP notification, stop the PTE timer and delete the PTE including tip.· Further, delete the ARP entry related to the tip and tha of the ARP notification.

Hosts A and B as victims are embedded boards loaded with the Linux OS. Host M as an attacker is a personal computer, and the Cain & Abel program, an ARP spoofing attack tool, operates at host M. Further, all ARP frames on the subnet were captured using the Wireshark tool operating at Host M.

As shown in Fig. 6, a Ping test to make the ARP entry was attempted first. After the creation of the ARP entry, ARP spoofing attacks were attempted. The results confirmed that the normal ARP entry remained unchanged after the attacks.

ARP notification transmissions were verified as shown in Table 2.

ARP attacks can be prevented by using packet filtering, port security settings, or separate device addition methods [4]. These solutions have several issues, including economic inefficiency, use of system resources, and compatibility aspects. In this study, an algorithm that can dynamically prevent spoofing attacks by the modification of ARP was proposed.

We focused on broadcasting an ARP reply and an ARP notification. The broadcast ARP reply was used for checking whether the ARP information was forged. The broadcast ARP notification was used for preventing a normal host’s ARP table from being poisoned. Further, the proposed algorithm was implemented in Linux Kernel and tested in a real LAN environment. The results showed that the designed algorithm can prevent ARP spoofing attacks. In the same ARP spoofing attacks, the original ARP protocol’s ARP table was poisoned, but the proposed ARP’s table was not poisoned. In this mechanism, an ARP notification frame might be maliciously used for isolating a specific host from a network. However, an ARP notification on the network means that any existing types of ARP attacks can be detected. Furthermore, this algorithm can prevent MITM attacks in which an attacker intercepts and forges a victim’s frames.

Further studies focusing on solutions for a malicious use of ARP notification are needed, and a study on the Internet Engineering Task Force (IETF)’s Source Address Validation Improvements (SAVI) protocols is planned.