# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 2 Background and Motivation
### Eager Neighbor Spoofing Attacks  
A less well-known and much more powerful cache poisoning attack opportunity exists in an optimization related to Neighbor Solicitations. The source link-layer address option (SLLAO) stub can be included with NS messages to indicate the intended link-layer address binding of the IP source address of the NS packet. This is performed so that receiving nodes will not be required to reverse-probe the sender's IP address for a link-layer address binding during NDAR transactions.  
The NDP specification in RFC 4861 [3] reads: \"If the [NS] is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option. Otherwise, the sender SHOULD include its link-layer address (if it has one) as a Source Link-Layer Address option. Including the source link-layer address in a multicast [NS] is required to give the target an address to which it can send the [NA]\". This optimization to NDP allows NDAR transactions to occur much faster, but it weakens the protocol due to its blind trust of senders and subsequent automatic caching. Since NS packets are generally the first contact in an NDP transaction, there is no straightforward way to recognize and mitigate this \"eager\" attack unless the NS occurs for an IP address that already has a binding within a target's Neighbor Cache.  
Figure 2 demonstrates the simplicity and potency of a more eager neighbor spoofing attack: only two steps are necessary for the poisoning to begin from the very start of an apparently legitimate and innocuous NDP transaction. In step 1, the malicious Node C creates a solicited-node multicast Neighbor Solicitation with a spoofed IP source address of fe80::b (Node B's address). The target address of address resolution is not important, but the attacker will need to aim the NS at the multicast group for which it knows the target node (Node A) is a member while trying to avoid sending the NS to the victim (Node B). By random chance, this will almost always be the case anyway for a 24-bit address suffix used to derive a solicited-node multicast address. When Node A receives the NS packet, it will preemptively cache the link-layer address found in the SLLAO and bind it to the IP source address of the packet; so Node A creates the entry [fe80::b \(\rightarrow\) 11-22-33-44-55-cc].  
Figure 1: A classic Neighbor Discovery neighbor spoofing (traffic redirection; on-path) attack. Each arrow is colored to indicate its associated step in the process; an upward arrow indicates transmission of a message, and a downward arrow indicates receipt of a message. After the normative address resolution process is completed in steps 1 and 2, the listening malicious Node C sends a spoofed Neighbor Advertisement in step 3 to override the link-layer address value in Node A’s Neighbor Cache. Node A now unknowingly harbors a “poisoned” cache entry.  
In step 2, Node A happily advertises itself through a unicast NA message as fe80::a with its legitimate MAC address 11-22-33-44-55-aa as a part of an expected and normal NDAR response. Node C is now free to receive data frames originally intended for Node B, transparently forwarding them, blocking them, or modifying them in-transit. It is also important to note that this attack can be effective in NDP augmentations requiring a Nonce field to be attached to NS/NA packets, because this eager poisoning can dishonestly forge any Nonce value as a virtue of being the NDAR initiator (i.e., solicitor).