# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 5 Discussion  
### Precomputing Address Collisions  
Malicious Voucher Bearers controlling address generation parameters are not able to further any goals aimed at neighbor spoofing attacks without infeasible time-memory tradeoffs. Control over network-wide KDF parameters and the voucher seed affords the opportunity to minimize the baseline difficulty of computing a hash collision, but only to an extent where the correct collision-producing link-layer identifiers must yet be discovered for neighbors with dynamic addresses.  
If the role of the Voucher Bearer is successfully hijacked by a malicious neighbor, then a static seed value with a minimal-cost KDF can be set according to the attacker's whims. The attacker can pre-compute a set of rainbow tables for all possible link-layer address bindings. However, the selection of an iteration count is determined at each network node and is not controllable by the threat actor. Therefore, indexing a set of predetermined results would require an index containing derivations from all possible link-layer identifiers (48 bits for MAC addresses), multiplied by all possible iteration count values (a 16-bit value) for each generated network address.  
\[2^{48}\times 2^{16}=2^{64}=18,446,744,073,709,552,000\text{ hashes}\]  
In the case specific to MAC addresses as link-layer identifiers: if each result stored only the necessary 48 bits extracted from the derived KDF hash value, then storage requirements per hash lookup in the rainbow table would total:  
MAC Address (48 bits) + Iterations Count (16 bits) + Hash Result Slice (48 bits) = 112 bits or 14 bytes  
For \(2^{64}\) rainbow table entries at 14 bytes each, 258,254,417,031,933,722,624 bytes, or about 224 EiB (exbibytes), of storage space would be required. This of course assumes that all possible 48-bit MAC addresses are useable by network nodes, which is not the case but  
Figure 13: A high-difficulty setting with the Scrypt KDF (a SCALING_FACTOR at its maximum of 5) shows a mostly linear relationship between the baseline time required to generate a VBA and the input iteration count. The data gathered is not an averaged composite of multiple runs. As the iteration count increases, variations in the baseline computation time increase, and the linearity of the graph gently curves downwards.  
provides a somewhat accurate demonstration. In total, 224 Eib is roughly equivalent to 2 million 128-TiB enterprise-grade storage arrays in sequence: an incomprehensible amount of data. If each hash were to require only 1 microsecond to compute, 8183.589 millennia of computation time would be required to calculate all the possible values, longer than any conceivable amount of time on a human scale.  
For more perspective, in an evenly distributed workload, 100,000 nodes would need to operate at full throttle for almost 82 years to generate all the desired information. Finally, this generated index would need to be readily cross-referenceable because finding a collision necessitates using a different input link-layer address than the one used by the legitimate node, according to the established principle of link-layer address uniqueness on-link. All of these preemptive calculations assume that the subnet prefix is also statically precomputed with the typical link-local prefix value of fe80::/64. Any change in the subnet prefix value requires an entirely new set of data at 224 Eib in size.  
These attacks are clearly computationally infeasible. In the best interest of future-proofing VBA, and to avoid any absurdities related to these considerations, all deployments using VBA should strongly consider using Router Advertisement Guarding per [32] to assist in preventing these attacks. Guarding against rogue vouchers prevents all hijacking and abates these concerns because the voucher seed will never be a fixed value controlled by an attacker.