Detection of Neighbor Solicitation and Advertisement
Spoofing in IPv6 Neighbor Discovery Protocol
Ferdous A Barbhuiya Santosh Biswas
IIT Guwahati IIT Guwahati
Assam, INDIA Assam, INDIA
ferdous@iitg.ernet.in santosh_biswas@iitg.ernet.insukumar@iitg.ernet.in
ABSTRACT
With the increase in number of hosts in the Internet, there is also a rise
in the demand for IP address space. To cater to this issue, IP version 6
(IPv6) succeeded IPv4. Compared to 32 bit IP address space in IPv4, IP
address in IPv6 is composed of 128 bits. In IPv4, when a host wants to
communicate with another host in an LAN, it needs to know the MAC
address of the target host, which was possible through Address Resolu-
tion Protocol (ARP). As ARP is stateless and due to lack of authoriza-
tion in ARP messages, many attacks like request spoofing, response
spoofing, Man-in-the-Middle (MiTM), Denial-of- Service (DoS) etc.
are possible. IPv6 uses Network Discovery Protocol (NDP) to find the
MAC address. NDP is also stateless and lacks authentication of its
messages by default. So NDP also suffers from many attacks similar
to ARP namely, neighbor solicitation spoofing, neighbor advertisement
spoofing, router solicitation spoofing, router advertisement spoofing,
neighbor unreachability detection attack etc. Although there are var-
ious attack detection and prevention mechanisms available for ARP
attacks, they are not yet implemented for NDP (IPv6). In this paper
we propose an attack detection mechanism for neighbor solicitation
spoofing and neighbor advertisement spoofing.
Keywords
IPv6 Security, Network Discovery Protocol, Neighbor spoofing, Attack
detection
1. INTRODUCTION
With rapid growth of the Internet, demand for more space in the In-
ternet Protocol(IP) address range arised. In the traditional IP Version
4 (IPv4), IP address comprise 32 bits thereby supporting an address
space of the O(232 ). IP version 6 (IPv6), where the IP address is
composed of 128 bits, succeeded IPv4, primarily to solve the address
scarcity problem. This expansion, apart from allowing many more de-
vices and users on the Internet, also provides many extra features like
flexibility in allocating addresses, efficiency in routing traffic [16] etc.
IPv6 uses two addressing schemes, one for local communication on the
link (called link local address) and the other for communication outside
the link (called global address). IPv6 subnet size has been standard-
ized by fixing the size of the host identifier to 64 bits to facilitate an
automatic mechanism for generating the host identifier from MAC ad-
dress. The link local address is 128 bits and is generated as follows.
The lower order 64 bits of link local address is obtained by inserting a
Sukumar Nandi
IIT Guwahati
Assam, INDIA
fixed value of 0xFFFE (comprising 16 bits) in the middle (i.e., 25th to
41th position) of the 48 bit MAC address of the host and changing the
7th bit of MAC from 0 to 1; these 64 bits are called interface identi-
fier. The higher order 64 bits of the link local address is a fixed value
of 0xFF80:0000:0000:0000. The link local address identifies a host
in the link and can be used to communicate with other hosts within a
link. The lower order 64 bits of the global address for a host is same as
the lower order 64 bits of the link local address. The higher order 64
bits are obtained from an incoming Router Advertisement (which is a
message in IPv6, to be elaborate latter).
When a host wants to communicate with another host, it needs to know
the MAC address of the target host. In IPv4 ARP (Address Resolu-
tion Protocol) is used for finding the MAC address given the IP ad-
dress. As ARP is stateless and due to lack of authorization in ARP
messages, many attacks like Man-in-the-Middle (MiTM), Denial-of-
Service (DoS) etc. initiate with the exploitation of this essential pro-
tocol of IPv4 [9]. There are number of passive solutions proposed in
the literature to detect, mitigate and prevent such attacks namely, static
IP-MAC assignment [10], use of hardware [12] and software to mon-
itor changes in IP-MAC pairs [5, 4, 7], signature intrusion detection
system [1] etc. The main drawbacks of these passive schemes were
lack of dynamism, scalability and false alarms. Attempts to eliminate
such drawbacks have been made in some active techniques for detect-
ing ARP attacks [15, 9, 17], where the IDS actively sends probe pack-
ets to hosts in the LAN in addition to observations (like changes of
IP-MAC pairs). Details of ARP attack detection techniques and issues
therein can be found in [9].
IPv6 uses Network Discovery Protocol (NDP) to find the MAC ad-
dress. The traditional attacks for exploiting ARP are also relevant in
NDP as it is also stateless and lacks authentication of its messages by
default. Neighbor solicitation spoofing, neighbor advertisement spoof-
ing, router solicitation spoofing, router advertisement spoofing, neigh-
bor unreachability detection attack etc. are some examples of NDP
related attacks. Although there are various attack detection and preven-
tion mechanisms available for ARP attacks (in IPv4 discussed above),
they are not yet implemented in NDP (IPv6) as the protocol is relatively
new and slowly coming in use. A few mechanism has been proposed
for detection / prevention of these attacks, but they are either com-
putationally expensive or requires management of cryptographic keys
or involve change in NDP itself. In this paper we propose an attack
detection mechanism for two IPv6 NDP related attacks namely, neigh-
bor solicitation spoofing and neighbor advertisement spoofing. These
spoofing attacks may lead to other attacks namely, Man in the mid-
dle (MiTM), Denial of Service (DoS), which are also detected by the
proposed scheme.
Rest of the paper is organized as follows. In Section 2, we discuss
briefly about the working of NDP protocol followed by neighbor so-
licitation spoofing and neighbor advertisement spoofing in Section 3.
Section 3 also presents existing techniques to detect these attacks and
issues therein. The proposed approach for detection of such NDP re-
lated attacks is given in Section 4. Experimental results are presented
in Section 5 and finally we conclude in Section 6
2. NETWORK DISCOVERY PROTOCOL
NDP is defined in RFC 2461 [6]. It uses ICMPv6 [8] to exchange mes-
sages necessary for its functions; specifically, five ICMPv6 messages
are specified in RFC 2461, which are
• Router Solicitation (RS) messages are originated by hosts to
request a router to send an Router Advertisement.
• Router Advertisement (RA) messages are originated by routers
to advertise their presence and link-specific parameters such as
link prefixes, link MTU and hop limits. These messages are sent
periodically, and also in response to Router Solicitation mes-
sages.
• Neighbor Solicitation (NS) messages are originated by hosts
to request another host’s MAC address and also for functions
such as duplicate address detection and neighbor unreachability
detection.
• Neighbor Advertisement (NA) messages are sent in response
to NS messages. If a host changes its MAC address, it can send
an unsolicited NA to advertise the new address.
• Redirect messages are used in the same way as redirects are
used in ICMP for IPv4 to redirect traffic from one router to an-
other.
As discussed in the last section, link local address in NDP can be gen-
erated from the MAC address. For the global address, we need MAC
address as well as information from a RA packet. A router makes
its presence known, along with any parameters it has been configured
to advertise, by periodically sending RAs on its attached links. RFC
2461 specifies that the period between transmissions of RAs should
be between 4 and 1800 seconds, with a default of 600 seconds. It
also specifies a minimum period between advertisements of RAs with
a default of 200 seconds. The advertisements are jittered between the
maximum and minimum values to prevent synchronization on a link.
These unsolicited RAs are sent with their source address set to the link-
local IPv6 address of the router’s interface. The destination address is
the all-nodes (hosts and routers) multicast address. 200 seconds is a
long time for a host that has just attached to an interface to wait for an
RA, so when a host first becomes active on a link, it can send an RS
to solicit the immediate transmission of an RA. The source of the RS
can either be the unspecified address (::) or the host’s link-local IPv6
address. The destination is always the all-routers multicast address.
When a router receives an RS, it sends (after a delay of .5 seconds)
an RA in response. If the source address of the RS that triggered the
RA is a host’s link-local address, the RA is unicast to the host using
its link-local address. If the source address of the RS was unspeci-
fied, the solicited RA is multicast to the all-nodes address. When a
host receives an RA, it generates the global address and adds the router
to its default router list (unless the RA indicates by a Router Lifetime
value of 0 that it cannot be used as a default). If there is more than one
router on the default router list, how the host selects a default router is
implementation-specific.
When an IPv6 node wants to communicate with another IPv6 node on
a local link, it must first discover the destination’s MAC address. This
address is then used as the destination address in the frame that encap-
sulates the IP packets to that node. For example, a node might want
to send a packet to “examplelocalhost.com". A DNS query returns
the IPv6 address 3FFE:521:2400:15:211:24FF:FE23:334E. When the
node examines the 64 bit prefix of the IPv6 address returned by DNS,
it either concludes that the destination is a neighbor on the local link
(when this 64 bit prefix matches with that of default router’s IPv6 ad-
dress) or that it is off-link and therefore reachable through the default
router. In the former case, as the destination is on the local link, the
source node first looks in its neighbor cache (similar to ARP cache in
IPv4) to see if the MAC address is available. If the address is not in the
neighbor cache, an entry is made with the corresponding IP and MAC
address, marked as Incomplete (indicating that address resolution is in
progress). The node then sends an NS to the multicast address of the
target host asking its MAC address. The NS should include the source
MAC address, which is used as the destination address by the respond-
ing NA. The target node sends a NA by unicast mentioning its MAC
address. On receipt of the NA, the source node updates in neighbor
cache (without verifying). If latter is the case, when the target node is
off the link, the packet is to be routed though the default router, whose
MAC address is known.
3. NEIGHBOR SOLICITATION/ ADVERTISE-
MENT SPOOFING: ATTACKS AND DETEC-
TION TECHNIQUES
As discussed before, when a source node wants to communicate with
a destination node in the same link, the source node needs to know the
MAC address of the destination node. Nodes on the link use Neighbor
Solicitation and Advertisement messages to create bindings between IP
addresses and MAC addresses. Each host has a neighbor cache which
keeps entries for IP-MAC pairings. So a source node first looks in its
neighbor cache to check if the MAC address corresponding to the IP
address under question (of the destination node) is available. If the
MAC address is not in the neighbor cache it sends an NS to the mul-
ticast address asking the MAC address of the host having the IP under
question. All hosts receive the NS (as it is multicast) and the host hav-
ing the IP under question sends an unicast NA mentioning its MAC
address. On receipt of the NA, the source node updates its neighbor
cache with the MAC address without any verification namely, whether
it had sent an NS for which the NA has arrived etc. Further, (all) nodes
which receive the NS update their cache with IP-MAC pairing infor-
mation (of the source node) available in the NS. This is basically a
performance optimization because all nodes know the MAC address of
the source node without NS and NA.
As IP-MAC pairing information from NS and NA are accepted with-
out any verification, attackers can easily spoof NS and NA with fal-
sified IP-MAC pairings. NS/NA spoofing involves a malicious node
sending NS/NA messages to a target node having falsified IP-MAC
pairings. Since NDP is a stateless protocol and the cache always up-
dates its entries, the target host blindly writes its neighbor cache with
the spoofed IP-MAC pairing. This results in redirecting all the data
link layer frames to the spoofed MAC address. For example, let there
be three hosts in a link A,B and D having IP address as IP(B),IP(B)
and IP(D), respectively; let the MAC addresses be MAC(B), MAC(B)
and MAC(D). Let A,B be genuine hosts and D be the attacker. Also,
let A sent a NS to query about MAC address corresponding to IP(B).
In response, B will send a NA which contains MAC(B). Following this
genuine NA, attacker D can send a spoofed NA to A having IP(B)-
MAC(D) (i.e., IP of B associated with its MAC). Neighbor cache of
A will update IP(B)-MAC(B) with (falsified) IP(B)-MAC(D). Now all
traffic A wants to send B will go to D (as commutation is by MAC
address). Similar situations can also be achieved by attacker sending
unsolicited NA or NS packets having falsified IP-MAC pairs. This
spoofing mechanism can be used for a DoS attack by specifying an
unused MAC address. Also this can be used to create Man in the mid-
dle (MiTM) attack by spoofing a pair of host’s MAC address with the
attacker’s MAC address.
3.1 Existing Mechanisms to Detect
NS/NA Spoofing
As IPv6 is new, only a few techniques to detect NS/NA spoofing has
been reported in the literature. In this sub-section we will discuss these
techniques and point out issues therein. Following that we will present
the motivation of the proposed approach.
Use of IPSec [13]: IPsec AH can be used with NDP (NS/NA) mes-
sages to enhance security and verify through AH that messages do con-
tain proper and accurate information. Security Associations (SA)s can
be created only through using the Internet Key Exchange (IKE). But
IKE requires a functional IP stack in order to function and this result in
a bootstrapping problem. So SA can only be configured by manually,
which is a tedious or impractical task considering the volume. Even
if SAs were established, it is not possible to verify the ownership of
dynamically generated IP addresses.
Secure Neighbor Discovery (SEND) [3]: RFC3971 defines this mech-
anism, which uses (PKI) to sign NA/NA messages. It may be noted that
key management in a LAN is cumbersome and difficult for a medium
scale organization to implement it.
Cryptographically generated addresses (CGA)) [2]: are used to avoid
spoofing on the local network. However, this protocol is not yet widely
implemented and the overhead associated with it can cause DoS con-
ditions itself. Further, the scheme requires modification of NDP.
Neighbor Discovery Protocol Monitor (NDPmon) [14]: It is a tool
that observes NS/NA packets in the local network to see if there are
changes in IP-MAC pairings; on detection of changes it notifies the
administrator by writing in the syslog. The problem with this approach
is, if the first sent packet itself is having a spoofed MAC address then
the whole system fails. Further, any genuine change in IP-MAC pair
will be discarded.
So, from the review, it may be stated that an NDP attack preventa-
tion/detection scheme needs to have the following features
• Should not modify the standard NDP or violate layering archi-
tecture of network
• Should not require patching, installation of extra softwares in all
systems
In this paper we propose a mechanism (i.e., Intrusion Detection Sys-
tem (IDS)) for detecting two NDP related attacks namely NS spoofing
and NA spoofing. The technique involves installation of the IDS in
just one system in the network, do not require changes in the standard
NDP protocol. Further, the IDS also detects MiTM and DoS attacks
generated by NA/NS spoofing.
4. PROPOSED SCHEME
This section focuses on the proposed Intrusion Detection System (IDS)
for detection NS/NA spoofing attacks.
4.1 Assumptions
The proposed model relies on the following assumptions regarding
IPv6 LAN.
1. All nodes are IPv6 configured using Stateless address autocon-
figuration (SLAAC) mechanism or have been assigned static IP.
The router has a static IPv6 address which sends out various net-
work parameters required by hosts on the network for autocon-
figuration.
2. Genuine non-compromised nodes on the link which are expected
to reply a Neighbor Solicitation message (either unicast or mul-
ticast) must do so within a specific time interval Treq .
3. IDS is a trusted machine with a static IP-MAC binding. It has
two network interfaces dedicated to their respective purposes;
one being responsible to collect network data in the LAN through
port mirroring and the other being exclusively used for handling
NS/RS or NA/RA probes requests/replies.
The proposed system maintains information about the network traffic
in data tables described below.
4.2 Data tables for the proposed system
Our proposed scheme ensures the genuineness of the IP-MAC pairing
by an active verification mechanism. The scheme sends verification
messages termed as NS probe requests upon receiving NSs and NAs.
To assist in the probing and separating the genuine IP-MAC pairs with
that of spoofed ones, we maintain some information obtained along
with the probe requests, NSs and NAs in some data tables. The in-
formation and the data tables used are enumerated below. Hence-
forth in the discussion, we use the following short notations: IP S -
Source IP Address, IP D - Destination IP Address, M ACS - Source
MAC Address, M ACD - Destination MAC Address. Fields of any
table would be represented by hT ableN ameihf ieldi ; e.g., N STIP S
represents the source IP filed of “Neighbor Solicitation Table. Also,
hT ableN ameiM AX represents the maximum elements in the table at
a given time.
1. Neighbor Solicitation Table: (N ST ):
Purpose: Whenever a neighbor solicitation message is sent, it is
recorded in the solicitation table N ST .
Components (Rows):
N STIP S Source IP of the Solicitation message, N STM ACS
Source MAC of the Solicitation message, N STIP D Destination
IP of the Solicitation message and timestamp N STtau
2. Neighbor Advertisement table (N AT ):
Purpose: This table records neighbor advertisement messages
sent by nodes in the network.
Components:
N ATIP S Source IP of the Advertisement message, N ATM ACS
Source MAC of the Advertisement message, N ATIP D Destina-
tion IP of the Advertisement message, N ATM ACD Destination
MAC of the Advertisement message and timestamp N ATtau
3. Probe table (P RB):
Purpose: For the verification of an IP-MAC pair, our IDS sends
out a Neighbor solicitation probe packet and its response (neigh-
bor advertisement) is verified. This process is initiated to in-
spect suspicious Neighbor solicitation and advertisement mes-
sages. The probe table stores the information about the probe
packets sent out by IDS.
Components:
P RBIP IP address for which verification message is being sent,
P RBM AC MAC address for which verification message is be-
ing sent.
4. Authenticated bindings table (AU T H):
Purpose: This table records IP-MAC bindings which have been
found to be authentic by the verification mechanism of IDS.
Components:
AU T HIP and AU T HM AC IP-MAC pair verified to be gen-
uine.
5. Log table (LOG):
Purpose: Whenever a spoofing is detected, the parameters are
recorded here along with the timestamp. Components:
LOGIP S Source IP of the Advertisement message, LOGM ACS
Source MAC of the Advertisement message, LOGIP D Destina-
tion IP of the Advertisement message, LOGM ACD Destination
MAC of the Advertisement message and timestamp LOGtau
6. Unsolicited advertisement table (U SAT ):
Purpose: This data table stores information about number of
neighbor advertisements for which no neighbor solicitation ex-
ists sent by a node within a specified time interval δ. Also mali-
cious neighbor solicitation messages (those which are not in Log
table and Authenticated table) are stored in this table.
Components:
 U SATIP D Destination IP of the Advertisement message and
timestamp U SATtau .
Although N As are sent in response to N Ss normally, there are
exceptions to it. For example, N As are unsolicited when sent
in order to propagate new information like change in its MAC
or IP address or at the time a node joins a network. Such N As
are handled separately and are not included in the Unsolicited
Advertisement table.
4.3 Algorithm and detection modules
The proposed scheme is based on two main modules NS-Handler() and
NA-Handler(). These are elaborated in Algorithm 1 and Algorithm 2,
respectively.
Algorithm 1 handles Neighbor Solicitation (N S) messages and Algo-
rithm 2 deals with Neighbor Advertisement (N A) messages.
Flow chart in Figure 1 illustrates the basic working of Algorithm 1.
Algorithm 1:
For any NS packet (N SP ) it first checks whether the packet is mal-
formed i.e. any changes in the immutable fields of the packet header or
inconsistent MAC addresses in the ICMPv6 header and IPv6 header. A
status flag is set accordingly to reflect this inconsistency and the algo-
rithm terminates here itself. The algorithm also skips the packet orig-
inated from IDS as we assume IP-MAC pairing of the IDS is already
verified. In all other cases, the NS request is added to the Solicitation
table and further processing of the packet is done as per the algorithm.
Next the NS packet (N SP ) is searched in the Authenticated bindings
table (AU T H). If a match is found, the packet has genuine IP-MAC
pair which is already recorded in the Authenticated bindings table. In
case of a mismatch in the MAC address, the packet is spoofed with
incorrect MAC address and hence status flag is set to spoofed. This
spoofed packet details is recorded in Log table. If neither of the above
cases occur the packet is sent to verification module which sends out
probe packets to verify the genuineness of the packet.
Algorithm 1 N S handler algorithm.
Input : N SP - Neighbor Solicitation packet, τ : time when this packet
was received.
Output: status of the packet.
if N SP is malf ormed then
status ← malf ormed
else if N SPIP S = IP (IDS) and N SPM ACS = M AC(IDS)
then
Exit
else if N SPIP S == :: (unspecified address) then
status ← unspecif ied
Exit
else
Add N SPIP S , N SPM ACS , N SPIP D and τ to the Solicitation
table (N ST )
if N SPIP S is found in an AU T H table (i.e. atleast one of the
AU T H table present in the window has this entry) then
if N SPM ACS also matches then
status ← genuine
else
status ← spoof ed Add N SPIP S , N SPM ACS , N SPIP D ,
N U LL, τ to Log table
end if
else
VERIFY_IP-MAC(N SP , τ )
end if
end if
Algorithm 2:
Algorithm 2 is N A handler. Flow chart in Figure 2 illustrates the ba-
sic working of Algorithm 2. As before, for any N A message the al-
gorithm first checks whether this packet is malformed; if it is so, the
packet is discarded and a status flag is set accordingly. Else the packet
details are recorded in the Neighbor Advertisement table (N AT ). Next
our algorithm checks if this packet is in response to some N S probe
sent by VERIFY_IP-MAC() module of the IDS. This can be identified
by the fact that for such packets, N APIP D ==IDSIP C and there ex-
ists a probe message entry corresponding to that packet in probe table
(P RB) . For such packets, this algorithm terminates.
If none of the above cases holds, then the advertisement packet is
checked for a corresponding neighbor solicitation (N S) in the solicita-
tion table (N ST ). If a corresponding match is found then this packet is
searched for its entry in Authenticated bindings table (AU T H). If en-
try corresponding to this packet is found, then the advertisement packet
has genuine IP-MAC binding.In case of a mismatch in MAC address
i.e. N AM ACS 6= AU T HTM ACS [i] (for some i ∈ N), the packet is
marked spoof ed and recorded in the log table LOG. If the advertise-
ment packet entry is not available in any Authenticated table, then a
NS probe is sent by the VERIFY_IP-MAC() module. If there is no
NS packet entry in Solicitation table (N ST ) for the received adver-
tisement packet, then this advertisement packet is an unsolicited adver-
tisement packet. It is to be noted that this statement means there is no
corresponding NS packet in N ST table though it is possible that the
solicitation flag in the ICMPv6 header of the packet is set to 1 by the
attacker. In this case UNSOLICITED_ADVT_HANDLER() module
is called by the algorithm with parameters as destination IP N AIP D
and timestamp τ . Also an entry is created in the Log table LOG for
this packet.
Algorithm 2 N A handler algorithm.
Input: N AP - Neighbor advertisement packet, τ : time when this
packet was received.
Output: Status of the packet.
if N AP is malf ormed then
status ← malf ormed
else
Add N APIP S , N APM ACS , N APIP D and τ to the advertise-
ment table (N AT )
if N APIP D == IP (IDS) & N APIP S is present in some probe
table (i.e. this packet is in response to some probe packet sent by
IDS) then
Exit
else
if N APIP S == N SPIP D for some NSP present in N ST table
(i.e. this NAP is in response to a neighbor solicitation sent by
some host ) then
if N APIP S is found in some authenticated table then
if N APM ACS also matches then
status ← genuine
else
status ← spoof ed
Add N APIP S , N APM ACS , N APIP D , N APM ACD ,
τ to Log table
end if
else
VERIFY_IP-MAC(N SP , τ )
end if
else
Add N APIP S , N APM ACS , N APIP D , N APM ACD , τ to
Log table
UNSOLICITED_ADVT_HANDLER(N APIP D , τ )
end if
end if
end if
The main modules discussed in Algorithms1 and Algorithm 2 are as-
sisted by sub-modules namely VERIFY_IP-MAC(),
RESPONSE_ANALYSER() and UNSOLICITED_ADVT_HANDLER().
Now we discuss these modules is detail.
 Start

YES
N SP is STATU S =
Exit
m alform ed m alform ed

NO

NO Is corresponding YES
Is source Is source IP YES
M AC also m atches
IP-M AC sam e present in STATU S= genuine
w ith that in
as that of ID S ? AU TH T ?
AU TH T ?

YES NO
NO
Exit

Exit Is source IP YES Is corresponding STATU S= spoofed

YES
present in Log M AC sam e as that Add packet details
table ? in Log table ? to Log table

NO
NO

Verify_IP-M AC()

Exit

Figure 1: Neighbor Solicitation Handler

6WDUW

<(6
1$3LV 67$786
([LW
PDOIRUPHG PDOIRUPHG

12

12 ,VFRUUHVSRQGLQJ <(6
,VGHVWLQDWLRQ ,VVRXUFH,3 <(6
0$&DOVRPDWFKHV
,30$&VDPH SUHVHQWLQ 67$786 JHQXLQH
ZLWKWKDWLQ
DVWKDWRI,'6" $87+7 "
$87+7 "

<(6 12
12
([LW

([LW <(6
,VVRXUFH,3 ,VFRUUHVSRQGLQJ <(6 67$786 VSRRIHG
SUHVHQWLQ/RJ 0$&VDPHDVWKDW $GGSDFNHWGHWDLOV
WDEOH" LQ/RJWDEOH" WR/RJWDEOH

12
12

9HULI\B,30$&

([LW

Figure 2: Neighbor Advertisement Handler

VERIFY_IP-MAC() algorithm:
This module verifies the IP-MAC binding of NS or NA packet. It sends
out a probe packet with destination IP-MAC address set to respective
values of IP-MAC pair to be verified. The algorithm first checks if an
entry corresponding to this IP-MAC pair already exists in some probe
table. If it is found then the algorithm terminates. It means that the
given IP-MAC has already been tested. If no match found then a new
probe packet with suspicious IP-MAC is sent and response is awaited.
Also a new entry is created in probe table (P RB). To analyse the
response obtained for this probe packet RESPONSE_ANALYSER()
function is called. Based on the replies obtained in the Neighbor Ad-
vertisement table (N AT ), this function determines the genuineness of
the suspicious packet.
Algorithm 3 VERIFY_IP-MAC algorithm.
Input: SP - suspicious packet (N A/N S packet), τ : time when this
packet was received, probe table (P RB).
Output: updated probe table (P RB), LOG and status of the packet.
if SPIP S is present in a probe table P RB then
if corresponding SPM ACS also matches then
Exit
else
status ← spoof ed
Add SPIP S , SPM ACS , SPIP D , SPM ACD and τ to Log table
end if
else
send NS probe for SPIP S
Add SPIP S and SPM ACS to probe table
RESPONSE_ANALYSER(SPIP S , SPM ACS , τ )
end if
RESPONSE_ANALYSER() algorithm:
This function is a kind of helper function for VERIFY_IP-MAC al-
gorithm. This module analyses the neighbor advertisements received
in response to probe solicitaions sent by IDS. As per our assumption,
all such advertisements must be received within the time interval Treq .
Now if no response is received within Treq , the case when attacker is
trying to cause Denial of service (DoS) to the victim, then it is clear
that suspicious IP-MAC pairing is a spoofed one. If exactly one re-
sponse is received and its source MAC matches with SPM ACS then
the suspicious packet (SP ) is a genuine packet and the algorithm ter-
minates. In case of more than one replies, the SP may be a spoofed
packet. Multiple NA replies are possible when attacker also tries to re-
ply with forged packet in order to present his attack packet as genuine.
If spoofing attempt is detected against a IP-MAC pair, it is updated in
the Log table otherwise it is added to a authenticated bindings table
(AU T H).
Algorithm 4 RESPONSE_ANALYSER() algorithm
Input: SP - suspicious packet (N A/N S packet), Treq : NS-NA
round trip time, advertisement tables (N AT ).
Output: updated Probe table (P RB), Log table (LOG), Authenti-
cated bindings table (AU T H) and status.
wait for Treq time interval
if SPIP S is found in some advertisement table N AT & SPM ACS
does not match with that in N AT table then
status ← spoof ed
Add SPIP S , SPM ACS , SPIP D , SPM ACD and τ to Log table
Add N ATIP S , N ATM ACS , N ATIP D , N ATM ACD and τ to
Log table (i.e. add corresponding entry already present in N AT
table)
EXIT
end if
update authenticated bindings table
UNSOLICITED_ADVT_HANDLER() algorithm:
This module handles advertisements for which no prior neighbor solic-
itation exists i.e. no corresponding solicitation message was found in
the solicitation table (N ST ). Such advertisement can be used in case
of Denial of Service (DoS) attack by continuously flooding spoofed
advertisement to a victim host in order to poison its neighbor cache
thereby redirecting traffic sent by it. This module uses unsolicited ad-
vertisement table (U SAT ) which maintains the number of such ad-
vertisements against individual IP address along with timestamp cor-
responding to most recent reply. If an entry already exists, then it is
updated by the algorithm otherwise if number of advertisements re-
ceived within a specified time interval δ exceeds DoS threshold value
(φT h ), a new entry is created in this table.
Algorithm 5 UNSOLICITED_ADVT_HANDLER() algorithm
Input: N AIP D - destination IP address of N A, τ - timestamp, δ -
time window, φT h - DoS threshold value, unsolicited advertisement
table (U SAT ).
Output: status.
if N AIP D is found in some U SAT table then
if τ - U SATτ < δ (i.e. this packet is received again within time
window δ since it was last received) then
Add this packet to U SAT table with current time as timestamp
τ and counter as 1 + counter value when the packet was last
received.
if U SATcounter > φT h then
status ← DoSattack
Exit
end if
else
Add entry corresponding to this packet in U SAT table with
U SATcounter =1 and timestamp τ as current time
end if
else
Add N AIP D , timestamp τ as current time, and counter value 1
to U SAT table
end if
In order to detect man in the middle attack we have another module
called MiTM-DETECTOR(). This module scans all Log table present
in the current window to identify man in the middle attack. Since this
attack involves spoofed packets to be sent in the network, these packets
will be detected by our spoof detecting mechanism described in above
algorithms and hence corresponding log entries will be available in Log
table (LOG). If two different IP address are found to be associated
with same MAC address within a specific time interval TM iT M , this
indicates the possibility of a M iT M attack. The algorithm scans all
Log table for the entries having same MAC address as that of the most
recent entry added within the time interval TM iT M . This subset of
Log table entries (LOG0 ) are analysed. If there is an entry in LOG0
for which source IP matches with the destination IP of the packet last
added and destination IP of LOG0 matches with the source IP of the
packet last added, it implies the case of MiTM attack.
4.4 Example
In this sub-section, we present an example to illustrate neighbor ad-
vertisement verification mechanism for normal and spoofing packets
in the network. Here, the network has 6 hosts namely A, B, C, D, E,
F. Node F acts as router and node E is our monitoring machine hav-
ing IDS running. It’s one interface is connected to switch through port
mirroring so that all the traffic in the network can be intercepted by it,
while the other interface is responsible for sending and receiving probe
packets in the network.
Figure 3 displays sequence of packets sent in the network (indicated by
packet serial numbers). Following is the detailed description of these
packets.
 6 . PAD V 4 . N AP
IP(C), M AC(D ) IP(C), M AC(D )
( Spoofe d pa ck e t )

3 .PAD V
IP(A), M AC(A)
2 . PSOL
IP(A), M AC(?) 5 . PSOL
IP(C), M AC(?)

LEGEN D

7 . PAD V N SP : N eighbor Solicitation packet

1 . N AP N AP : N eighbor Advertisem ent packet
IP(C), M AC(C)
IP(A), M AC(A) PSO L : N eighbor Solicitation Probe packet
( Ge n u in e pa ck e t )
( Ge n u in e pa ck e t ) PAD V : N eighbor Advertisem ent Probe packet

Figure 3: Verification of normal and spoofed packet

Algorithm 6 MiTM-DETECTOR() algorithm Table 4: Authenticated bindings table

bthp Sl. no. IP MAC
Input: IP S - source IP address of recent Log table entry, M ACS - 1 IP A MAC A
corresponding source MAC address, IP D - destination IP address of
recent Log table entry, τ - time when this entry was created, TM iT M -
time window for arrival of packets causing MiTM, log table LOG. Genuine Neighbor Advertisement sent by host A to host B:
Output: status.

LOG0 := LOG table which have entries corresponding to MACS • Packet 1: Node A sends neighbor advertisement to host B. Ad-
& (τ -LOGτ ) < TM iT M vertisement table (N AT ) is updated with a new entry corre-
if LOG0IP S == IP D && LOG0IP D == IP S for some log table in sponding to this packet.
LOG0 ) then
status ← M iT M and attacker is M ACS • Packet 2: Since there is no entry for packet 1 in any Authenti-
end if cated bindings table, E sends a NS probe packet (packet 2) to
verify the source MAC address claimed by packet 1 and a corre-
sponding entry is added to probe table P RB.
• Packet 3: After probe packet is sent, RESPONSE_ANALYSER()
Table 1: Neighbor Solicitation Table module is called. This module waits for Tr eq and collects the re-
Pac. no. IPsrc M ACsrc IPdst τ sponse obtained within this time interval. Only A will respond
− − − − − and hence packet 1 is inferred to be genuine. AU T H table is
updated with an entry for IP-MAC pair of node A.

centering
Spoofed advertisement packet sent by attacker D to victim A:
Table 2: Neighbor Advertisement Table
Pac. no. IPsrc M ACsrc IPdst M ACdst τ
1 IP A MAC A IP B MAC B τ1 • Packet 4: Attacker D sends out a spoofed packet having IP(C)-
3 IP A MAC A IP E MAC E τ2 MAC(D) binding to node A. This is recorded in Advertisement
4 IP C MAC D IP A MAC A τ3 table N AT .
6 IP C MAC D IP E MAC E τ4 • Packet 5: Packet 4 is detected by IDS (E) and since there is no
7 IP C MAC C IP E MAC E τ5 entry in any Authenticated bindings table, a corresponding probe
packet is sent to verify its identity. Probe table is accordingly
updated with IP(C)-MAC(D) entry. After sending probe packet,
RESPONSE_ANALYSER() module is executed.
Table 3: Probe table
Pac. no. IP MAC • Packet 6,7: In response to probe solicitation sent by IDS, at-
2. IP A MAC A tacker will respond with a neighbor advertisement having IP(B)-
5 IP C MAC D MAC(D) so as to present its original spoofed advertisement packet
as genuine, while host C replies with its genuine IP(C)-MAC(C)
 packet. Now these advertisements will be received within Treq 6. CONCLUSION
and recorded by IDS in the advertisement table N AT . In this paper we presented a technique for detecting neighbor solicita-
RESPONSE_ANALYSER() module analyses N AT table and tion spoofing and advertisement spoofing attacks in IPv6 NDP. Further,
concludes that there is an attempt of spoofing against IP of C the scheme also detects MiTM and DoS attacks generated by NA/NS
since there are two different MAC address corresponding to same spoofing. The scheme uses an active probing mechanism. As the ac-
IP (that of C). tive probes are nothing but NS messages, the scheme does not require
any change in NDP. Further, this being a software based approach does
not require any additional hardware to operate. Also, as the software
The entries in Neighbor Solicitation Table, Neighbor Advertisement is installed in a centralized location, other hosts do not required any
Table, Probe table and Authenticated bindings table for the packet se- patching or installing.
quence used in the above example is shown in Table 1 through Table
4.
At present the scheme can only detect NS spoofing, NA spoofing,
MiTM and DoS attacks. There are several other attacks possible on
5. EXPERIMENTAL RESULTS NDP namely, malicious router attack, neighbor unreachability detec-
The test bed created for our experiments consists of 6 machines run- tion attack, duplicate address detection attack etc. The authors are
ning different operating systems. We name the machines with alpha- currently extending the scheme proposed in this paper to handle these
bets ranging from A-F. Machines A-E are running the following OSs: attacks.
Windows Xp, Ubuntu (as router), Windows 7, Backtrack 5, Fedora 14
and Windows 3003, respectively. The machine D with Backtrack 5 7. REFERENCES
is acting as the attacker machine and machine E is set up as the IDS. [1] Cristina L. Abad and Rafael I. Bonilla. An analysis on the
These machines are connected in a LAN with a CISCO catalyst 3560 schemes for detecting and preventing ARP cache poisoning
G series switch [11] with port mirroring enabled for system E. The attacks. In International Conference on Distributed Computing
algorithms mentioned in Section 4 are implemented in C++ and the ta- Systems Workshops, pages 60–67. IEEE, 2007.
bles in MySQL. The IDS has two preemptive modules namely, packet
[2] Ed. J. Arkko, J. Kempf, B. Zill, and P. Nikander.
grabber and packet injector. Packet grabber sniffs the packets from
Cryptographically generated addresses (CGA). RFC 3972,
the network, filters NDP packets and invoke either the Algorithm 1 or
Internet Engineering Task Force, March 2005.
Algorithm 2 depending upon the NS or NA.
[3] Ed. J. Arkko, J. Kempf, B. Zill, and P. Nikander. SEcure
neighbor discovery (SEND). RFC 3971, Internet Engineering
Figure 4 and Figure 5 shows the amount of NDP traffic generated in
Task Force, March 2005.
the experimentation in two cases. The first case is of normal operation
in the absence of the IDS. Second case is when the IDS is running [4] arpdefender. http://www.arpdefender.com.
and there are no attacks generated in the network. We notice that the [5] arpwatch. http://www.arpalert.org.
extra traffic generated is slightly high at the initialization phase and [6] T. Aura. Neighbor discovery for IP version 6 (IPv6). RFC 2461,
then goes down to become negligible. Once genuine IP-MAC pairs Internet Engineering Task Force, December 1998.
are identified (by probing) they are stored in Authenticated bindings [7] colasoft capsa. http://www.colasoft.com.
table. Following that no probes are required to be sent for any NDP [8] A. Conta, S. Deering, and M. Gupta. Internet Control Message
solicitation/advertisement from these IP-MAC pairs. In case of attack, Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
a little extra traffic is generated by our IDS for the probes. With each Specification. Technical Report 4443, Internet Engineering Task
spoofed NS/NA packet, our IDS sends a probe request and expects at Force, March 2006.
least two replies (one from normal and the other from the attacker), [9] N. Hubbali, S. Biswas, S. Roopa, R. Ratti, and S. Nandi. LAN
thereby adding only three NDP packets for each spoofed packet. attack detection using discrete event systems. ISA Transactions,
50(1):119–130, 2010.
NDP Traffic at Normal Condition [10] Charles M. Kozierok. TCP/IP Guide. No Starch Press, 1 edition,
35
October 2005.
30
[11] Cisco Systems PVT LTD. Cisco 3560 catalyst switches
reference manual.
NDP Packet Count

25

20 Normal without IDS [12] Cisco Systems PVT LTD. Cisco 6500 catalyst switches
15 Normal with IDS
reference manual.
10 [13] T. Narten, E. Nordmark, and W. Simpson. Security features in
5
ipv6. Whitepaper, SANS Institute, 2002.
0
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97
[14] NDPmon. http://ndpmon.sourceforge.net.
Seconds
[15] V. Ramachandran and S. Nandi. Detecting ARP spoofing: An
active technique. International Conference on Information
Figure 4: NDP traffic at Normal Condition Systems Security, LNCS, 3803:239–250, 2005.
[16] Microsoft Technet. Ipv6 features.
[17] Zouheir Trabelsi and Khaled Shuaib. Man in the middle
NDP Traffic at Attack condition
intrusion detection. In Globecom, pages 1–6. IEEE, 2006.
35

30
NDP Packet Count

25

20 Attack without IDS

15 Attack with IDS

10

0
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97
Seconds

Figure 5: NDP traffic at Spoofed Condition