Use Secure Neighbor Discovery to protect against attacks

[puradox]

To protect against ARP poisoning and other attacks against NDP functions, Secure Neighbor Discovery (SEND) Protocol should be deployed where preventing access to the broadcast segment might not be possible. SEND uses RSA key pairs to produce Cryptographically Generated Addresses (CGA), as defined in RFC 3972. This ensures that the claimed soruce of an NDP message is the owner of the claimed address.

From RFC 4861 Section 11.1. Threat Analysis:

   This section discusses the main threats associated with Neighbor
   Discovery.  A more detailed analysis can be found in [PSREQ].  The
   main vulnerabilities of the protocol fall under three categories:

   - Denial-of-Service (DoS) attacks.
   - Address spoofing attacks.
   - Router spoofing attacks.

   [...]

   The protocol contains no mechanism to determine which neighbors are
   authorized to send a particular type of message (e.g., Router
   Advertisements); any neighbor, presumably even in the presence of
   authentication, can send Router Advertisement messages thereby being
   able to cause denial of service.  Furthermore, any neighbor can send
   proxy Neighbor Advertisements as well as unsolicited Neighbor
   Advertisements as a potential denial-of-service attack.

This issue homes the discussion of whether or not we need this feature.

[ghananigans]

https://tools.ietf.org/html/rfc8504#section-5.5 (published Jan 2019)

   There have been relatively few implementations of SEND in common
   operating systems and platforms since its publication in 2005; thus,
   deployment experience remains very limited to date.

   At this time, support for SEND is considered optional.  Due to the
   complexity in deploying SEND and its heavyweight provisioning, its
   deployment is only likely to be considered where nodes are operating
   in a particularly strict security environment.