This paper provides a brief introduction to common security threats on IPv6 Layer 2 access networks and will explain the value of using IPv6 Secure Neighbor Discovery (SEND) technology in mitigating these threats. The paper includes an overview of the operational principles of SEND together with some architectural technology details.
The target audience for this paper is network architects and network operation engineers.
Neighbor Discovery Protocol
This section will explain some of the Internet Control Message Protocol Version 6 (ICMPv6) security vulnerabilities for IPv6 that engineers should be concerned about. In comparison with IPv4, IPv6 has an increased set of capabilities to simplify end-system autoconfiguration, while at the same time running service detection by means of ICMP. Because of these new ICMP capabilities, the importance of ICMP is much higher for IPv6 as it ever has been for IPv4.
One of the new functionalities within ICMPv6 is the Neighbor Discovery Protocol (NDP), part of RFC 4681, which in its base specification is a nonauthenticated protocol. NDP is an application and operates above ICMPv6. NDP makes heavy usage of multicast packets for on-the-wire efficiency.
The functional applications of NDP include:
• Router discovery
• Autoconfiguration of addresses (stateless address autoconfiguration [SLAAC])
Table 1 compares the IPv6 NDP functionality with the comparable IPv4 technology.
Table 1. Comparison of IPv6 Features with IPv4 Features
IPv6 NDP Feature
Short Description
IPv4 Equivalent
Router discovery
Enable hosts to locate routers on attached links
ICMP router discovery
Routing protocols snooping
Prefix discovery
Enable hosts to learn prefixes used on attached links
-
Parameter discovery
Enable nodes to learn parameters such as link MTU or hop limit
Path MTU discovery
RFC 1191[69]
Address autoconfiguration
Enable host to configure automatically an address
-
Address resolution
Enable nodes to determine link-layer address for on-link destinations
Address Resolution Protocol (ARP)
Next-hop determination
Enable nodes to determine the next hop for a given destination
ARP cache on-link prefixes
Default router otherwise
Neighbor unreachability detection
Enable nodes to detect nodes that a neighbor is no longer reachable
Dead Gateway Detection
RFC 816[70], RFC 1122[71]
Duplicate address detection
Enable nodes to determine addresses already in use
ARP with source=0
Redirect
Enable routers to inform host of a better next hop for a particular destination
ICMP Redirect
Proxying nodes
Accepts packets on behalf of other nodes
Proxy-ARP
Neighbor Discovery Protocol Trust Models and Threats
The security implications of NDP are well known and clearly described in RFC 3756, which describes three trust models. Each of these environments has its intrinsic security considerations and requirements:
• Corporate Internet: A model in which all authenticated nodes trust each other to behave correctly at the IP layer and not to send any network discovery or router discovery message that contains false information.
• Public wireless: A model in which a router is trusted by the other nodes in the network to be a legitimate router that faithfully routes packets between the local network and any connected external networks. Furthermore, the router is trusted to behave correctly at the IP layer and not to send any network discovery or router discovery messages that contain false information.
• Ad hoc network: A model in which the nodes do not directly trust each other at the IP layer.
Each of these trust models imposes a set of different requirements regarding NDP security because NDP is a nonauthenticated protocol. Some of the well-known NDP vulnerabilities are:
• Attack on address resolution (Figure 1)
Figure 1. Attack on Address Resolution
• Redirect attack (Figure 2)
Figure 2. Redirect Attack
• DAD attack (Figure 3)
Figure 3. DAD Attack
• First-hop router spoofing (Figure 4)
Figure 4. First-Hop Router Spoofing Attack
• Attack on address configuration (Figure 5)
Figure 5. Address Configuration Attack
Although NDP (RFC 4861) does not include authentication, it does have some basic protection mechanisms built-in as an initial protection shield:
• NDP is a link-local protocol, and the source address must be either the unspecified address (::/128) or a link-local address.
• The hop limit must be set to 255. This mechanism avoids NDP packets that can be injected into the network infrastructure from beyond the directly connected Layer 2 access network.
Nevertheless these protection mechanisms are not enough really to protect the IPv6 network for all different trust models. Hence, IETF has developed Secure Neighbor Discovery, which is a more secure version of NDP.
Introduction to SEND
Secure Neighbor Discovery is a protocol that enhances NDP with three additional capabilities:
• Address ownership proof
– Makes stealing IPv6 addresses "impossible"
– Used in router discovery, DAD, and address resolution
– Based upon Cryptographically Generated Addresses (CGAs)
– Alternatively also provides non-CGAs with certificates
• Message protection
– Message integrity protection
– Replay protection
– Request/response correlation
– Used in all NDP messages
• Router authorization
– Authorizes routers to act as default gateways
– Specifies prefixes that routers are authorized to announce "on-link"
While SEND provides a significant uplift to the IPv6 neighbor discovery technology by introducing the above enhancements, it does not, for example, provide any end-to-end security and provides no confidentiality.
It is important to understand that SEND is not a new protocol and still remains a protocol operating on the link. Secure Neighbor Discovery is just an "extension" to NDP and defines a set of new attributes:
• New network discovery options: CGA, Nonce1, Timestamp, and RSA
Purpose: These options provide a security shield against address theft and replay attacks.
Purpose: Identifying valid and authorized IPv6 routers and IPv6 prefixes of the network segment. These two messages complement the already existing NDP messages (NS, NA, RA, RS, and Redirect).
• New rules
Purpose: These rules describe the preferred behavior when a SEND node receives a message supported by SEND or not supported by SEND.
SEND technology works by having a pair of private and public keys for each IPv6 node in combination with the new options (CGA, Nonce, Timestamp, and RSA). Nodes that are using SEND cannot choose their own interface identifier because the interface identifier is cryptographically generated based upon the current IPv6 network prefix and the "public" key. However, the CGA interface identifier alone is not sufficient to guarantee that the CGA address is used by the appropriate node.
For this purpose SEND messages are signed by usage of the RSA public and private key pair. For example if node 1 wants to know the MAC address of node 2, it will traditionally send a neighbor solicitation request to the node 2 solicited node multicast address. Node 2 will respond with a corresponding neighbor advertisement containing the MAC address to IPv6 address mapping. Node 2 will in addition add the CGA parameters (which include among others the public key) and a private key signature of all neighbor advertisement fields. When node 1 receives this neighbor advertisement it uses the public key to verify with the CGA address the private key signature of node 2. Once this last step has been successfully completed the binding on node 1 of the MAC address and CGA address of node 2 can be successfully finalized.
Note that the above mechanism is simply an explanation to verify the correct relationship between a node MAC address and its CGA IPv6 address (more details are found in a following chapter covering CGA addresses). SEND does not check any of the node's privileges to be allowed, or not allowed, on the network. If this is required, other means of infrastructure protection will be required (such as 802.1x).
Replay Protection with SEND
Note that the above simplified procedure does not protect against replay of NDP messages. For this purpose two new options have been created: Nonce and Timestamp. Both these options belong to the list of CGA parameters.
The Nonce option provides replay protection when there is two-way communication (that is, neighbor solicitation to neighbor advertisement). In essence the Nonce is a random number. When for example a node 1 wants to know the MAC address of node 2, then node 1 will add this Nonce option into a neighbor advertisement request. When node 2 responds to this neighbor advertisement request from node 1 with a neighbor solicitation, it will add this Nonce into the neighbor solicitation packet. Doing so will allow node 1 to verify whether the neighbor solicitation received is actually a real response to the originally sent neighbor advertisement or a fake replay attack (Figure 6).
Figure 6. Using the Nonce Option
The above mechanism works pretty well when there is a two-way triggered communication, as with neighbor advertisement/neighbor solicitation. However, NDP also has components that are simply unidirectional such as the periodic router advertisement. To protect this type of communications the Timestamp is used (Figure 7).
Figure 7. Using the Timestamp Option
Assuming all devices have synchronized clocks, then replay of router advertisement packets does not exist because each router advertisement in a SEND environment has a private key signature that includes the Nonce and the Timestamp.
Router Authorization with SEND
Another important role of SEND is the authorization of valid routers on a Layer 2 access network. SEND will use X.509 certificates to authorize valid authorized routers and the information embedded with the router advertisements. Receiving hosts can, when receiving these certificates, verify the certificate with the aid of the certificate authority and identify whether the router advertisement is from a valid authorized router and can be used as an IPv6 default gateway.
In essence the usage of these certificates will allow hosts to trust attached routers. In addition the certificate subject field includes the prefixes that the router is allowed to announce. Upon receiving a router advertisement, a host can, through analyzing the certificates, either trust or not trust the information embedded within the router advertisement.
The exchange of the certificates is done by means of two new messages:
• Certification Path Solicitation (CPS): A host can use this message to obtain the router certificate if it is not already in the host cache.
• Certification Path Advertisement (CPA): A router can use this message to reply with the certificate after a CPS.
Figure 8 provides insight into the steps taken with SEND for router authorization.
Figure 8. Using SEND for Router Authorization
1. In the first instance, the host needs to receive a certificate authority certificate C0 from the trusted certificate authority CA0. This certificate C0 will be used as the anchor certificate to validate any received router certificate. The host will be able to verify with this certificate C0 anything that Router R sends that is signed with the router certificate CR (see later in step 3).
2. If the router wants the host to trust its router advertisement, then the router will have to ask the certificate authority CA0 for a valid router certificate.
3. The certificate authority CA0 will provide the router with router certificate CR. This router certificate is used by the router to let the hosts know that it is a valid authorized router.
4. The next step is for the host to make sure that the attached router is a valid authorized router, and this is done by sending a CPS packet toward the router asking for its certificate CR.
5. Once the router receives the certificate request from the host, it will reply with the router certificate CR included into the CPA router response packet.
6. Next the host will verify the received router certificate CR by means of its certificate authority certificate C0.
7. If the router certificate CR is found valid, then the host can start using the router as the default gateway.
Because the X.509 certificates can be rather large, the SEND technology will only place a single certificate into a CPA packet. The host will check the certificates only once it has learned through the router advertisement about the potential IPv6 default-gateway candidate. Figure 9 provides some more detailed insight into the steps taken by a host to request the certificates.
Figure 9. Steps the Host Takes to Request the Certificates
The Cryptographically Generated Address
The CGA is, as indicated earlier, a key component within the SEND technology and has been defined in RFC 3972 by the IETF. The CGA concept provides a mechanism to have trust between a node and the IPv6 address the node is using. The goal is to avoid that an IPv6 address could be used (by accident or on purpose) by another node without the correct credentials.
The basic idea is to generate the interface identifier (the rightmost 64 bits) of the IPv6 address of a node by computing a cryptographic hash of the node's public RSA key. The corresponding private RSA key can then be used to sign messages sent from this node.
Some considerations that have been made when developing the CGA address standard RFC 3972:
• It must be very hard for a brute-force attack to generate a corresponding RSA private/public key pair.
• The "complexity" for generating the hash must be able to evolve and be tunable.
• The address must be "well" formed.
• The address must be verifiable: Receiver must be able to check that the address was generated from the key that can decode the signature.
Figure 10. Creating the CGA Address
The creation of the CGA address happens in a few steps (Figure 10):
1. To generate the CGA address, the node must initially obtain an RSA public/private key. The private key must be hidden very well within the node, while the public key can be distributed to any node that has interest in it.
2. Based upon the IPv6 prefix of the node (64 bits) and the public key, a message ("message" in this instance relates to a cryptographic terminology for a memory structure) can be built.
3. The next step is to perform a SHA-1 hash of the complete original message from step 2 combined with additional CGA parameters3.
4. In this last step a new hash' is made based upon the hash in step 3. To build the actual 128-bit CGA address, the IPv6 prefix and the u and g bits are added correspondingly, and additionally the CGA additional parameters are taken into account again for creating the hash' value.
5. An important aspect to increase the security for SEND is the security level used. At the time of writing, only two values have been defined. The SHA-1 hash function between steps 3 and 4 results in a 20-byte value. The first security level will just look at the first 16 bits of the resulting hash' value. If they all result in 0 (zeros) then the hash' is successful; if not then the resulted value is hashed again and again until the first 16 leading bits are all 0. Statistically this would need around 212 loops. Statistically with current microprocessor calculation power this takes about 1 second to calculate for the host generating the hash'. The number of times the host had to recalculate the SHA-1 hash' to come to an acceptable "security level 1" hash' value is added as a CGA parameter. Using this technique will make it much harder for a brute-force attack to guess a matching private/public RSA key pair. The other current defined security level is level 2. Level 2 means that now the first 32 bits have to be 0, which is a process that takes significantly longer (order of months) than security level 1. Other security levels have not been defined yet to make sure that SEND can be extended with better and more advanced security mechanisms towards the future. Cisco IOS® Software only supports security level 1 at the moment and does not support security level 2 due to the time it takes to process with current technology.
Figure 11 illustrates how the CGA address is used to understand the basic operational principle of address ownership.
Figure 11. The Basic Operational Principle of Address Ownership
Figure 11 illustrates how the content of the NDP messages is used by the receiver of a SEND NDP packet to verify the authenticity of the packet. Through this method, the receiving node can decide whether a packet is valid or nonvalid (for example through address hijack, replay, and so on).
Conclusion
The usage of CGA is a lightweight mechanism that provides good protection against Layer 3 address spoofing when used in combination with SEND-capable nodes. The SEND implementation for router advertisement spoofing is a very powerful tool to avoid nonauthorized routers on the network and hence solves completely the issue of router spoofing.
Using SEND and CGA does only provide protection against Neighbor Discovery Protocol security, as neither provides any sort of Layer 2 protection or protection against address scanning.
Cisco IOS Software 12.4(24)T provides support for Secure Neighbor Discovery to support the full IPv6 specification of RFC 3972 and RFC 3971.
For More Information
• Neighbor discovery
– RFC 2461: "Neighbor Discovery for IP Version 6 (IPv6)"
1In order to prevent replay attacks, two new neighbor discovery options, Timestamp and Nonce (a random number), are introduced. Given that neighbor and router discovery messages are in some cases sent to multicast addresses, the Timestamp option offers replay protection without any previously established state or sequence numbers. When the messages are used in solicitation-advertisement pairs, they are protected with the Nonce option.
2Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default router. Certification path solicitation and advertisement messages are used to discover a certification path to the trust anchor without requiring the actual router discovery messages to carry lengthy certification paths. The receipt of a protected router advertisement message for which no certification path is available triggers the authorization delegation discovery process.
3The additional parameters exist out of a modifier (a random 128-bit integer used to enhance privacy and randomness to the address), 64-bit prefix of the node, collision count (8-bit unsigned integer, incremented each time a duplicate address detection was detected upon the generated CGA address), and the public key (a variable length field containing the public key of the address owner).
