IPv6 for IoT — SEcure Neighbor Discovery (SEND) and Duplicate Address Detection (DAD)
Internet-connected products are becoming increasingly popular, and while IPv4 addresses couldn’t meet the demand for IoT products, IPv6 gives IoT products a platform to operate on for a very long time.
The primary function of IPv6 is to allow for more unique TCP/IP address identifiers to be created, now that we’ve run out of the 4.3 billion created with IPv4. This is one of the main reasons why IPv6 is such an important innovation for the Internet of Things (IoT).
IPv6 Address Format
IPv6 basically has an address format as seen in the figure below.
Global Routing Prefix: Includes the prefix information given to institutions by Internet Service Providers (ISP) or the Regional Internet Registry (RIR). The global routing prefix in the IPv6 address structure refers to the first 48 bits. The first 23 bits are distributed by RIRs and the next (up to) 32 bits are distributed by ISPs.
Subnet ID: the Subnet ID defines an administrative subnet of the network and is up to 16 bits in length. You assign a subnet ID as part of the IPv6 network configuration. 16 bits of Subnet ID are also provided by ISPs to institutions.
Interface ID: It indicates the interface in a website on a particular subnet. The length of this field is 64. In stateless address configuration, the interface identifier that lasts 64 (interface identifier) of IPv6 address are unique for 64 prefixes of IPv6 address.
IPv4 vs IPv6
The main differences between IPv4 and IPv6 are as follows;
- IPv4 is a 32-Bit IP address whereas IPv6 is a 128-Bit IP address.
- IPv4 is a numeric addressing method whereas IPv6 is an alphanumeric addressing method.
- IPv4 binary bits are separated by a dot(.) whereas IPv6 binary bits are separated by a colon(:).
- IPv4 offers 12 header fields whereas IPv6 offers 8 header fields.
- IPv4 has checksum fields while IPv6 doesn’t have checksum fields
- IPv4 supports VLSM (Virtual Length Subnet Mask) whereas IPv6 doesn’t support VLSM.
- IPv4 uses ARP (Address Resolution Protocol) to map to MAC address whereas IPv6 uses NDP (Neighbour Discovery Protocol) to map to MAC address.
The encryption and integrity-checking used in current virtual private networks (VPNs) are a standard component in IPv6, available for all connections and supported by all compatible devices and systems. Widespread adoption of IPv6 will therefore make “man-in-the-middle” attacks i.e., thinking that you’re signing in to a secure bank log in when you’re actually walking into a cyber trap, significantly more difficult.
IPv6 also supports more secure name resolution. The Secure Neighbor Discovery (SEND) protocol is capable of enabling cryptographic confirmation that a host is who it claims to be at the time of the connection. This renders Address Resolution Protocol (ARP) poisoning and other naming-based attacks more difficult.
According to a report put out by Gartner, 25 billion “things” will be connected to the internet by the year 2020. IPv6 is important for IoT devices. Creators of IoT products that are connected over TCP/IP can rest assured that there will be a unique identifier available for their devices for a long, long time.
Network Address Translation (NAT) posed one of these major issues. NAT was created as a workaround for organizations that needed multiple people and devices to be able to work off of the same IPv4 address. Not only does this pose a security issue (which we’ll talk about in a moment), but it also poses a difficult issue for IoT products. IPv6 allows IoT products to be uniquely addressable without having to work around all of the traditional NAT and firewall issues.
SEcure Neighbor Discovery (SEND)
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
In order to take precautions against the vulnerability attacks in the IPv6 NDP, various measures such as authentication, proving the address of the client, ensuring the integrity of the messages, and authorizing the routers must be taken. At this point, a mechanism that performs these operations is defined in Secure Neighbor Discovery (SEND) by RFC 3971.
The Secure Neighbor Discovery (SEND) protocol is a security extension of the Neighbor Discovery Protocol (NDP) in IPv6 defined in RFC 3971 and updated by RFC 6494.
4 new header structures are defined for SEND in RFC 3971;
- CGA (Cryptographically Generated Addresses) Option
- RSA Signature Option
- Nonce Option
- Timestamp Option
In addition to these options, 2 different message types are defined for SEND;
- CPS (Certification Path Solicitation)
- CPA (Certification Path Advertisement)
SEND uses Cryptographically Generated Addresses (CGA) and other new NDP options for the ICMPv6 packet types used in NDP.
Duplicate Address Detection (DAD)
Duplicate Address Detection (DAD) is performed when an IPv6 node verifies the uniqueness of a tentative IPv6 address. This node sends a Neighbor Solicitation (NS) message with the IP destination set to the solicited-node multicast address of the tentative address. This NS message is multicasted to other nodes on the same link. When the tentative address is already used on the link by another node, this last one replies with a Neighbor Advertisement (NA) message to inform the first node. So when performing DAD, a node expects the NS messages are received by other nodes.
However, in a point-to-multipoint network with a split-horizon forwarding scheme implemented in the AN, the CPEs are prevented from talking to each other directly. All packets sent out from a CPE would be forwarded by AN only to the BNG but not to any other CPE. That said, NS messages sent by a certain CPE will be received only by the BNG and will not reach other CPEs. So, other CPEs have no idea that a certain IPv6 address is used by another CPE. That means, in a network with split-horizon, DAD can’t work properly without an additional helper.
How SEND Counters Threats to NDP?
The SEND protocol is designed to counter the threats to NDP, as outlined in. The following subsections contain a regression of the SEND protocol against the threats, to illustrate which aspects of the protocol counter each threat.
1. Neighbor Solicitation/Advertisement Spoofing
The threat is that a spoofed message may cause a false entry in a node’s Neighbor Cache. There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router receiving a Router Solicitation with a Target Link-Layer Address extension and the IPv6 source address unequal to the unspecified address inserts an entry for the IPv6 address into its Neighbor Cache. Also, a node performing Duplicate Address Detection (DAD) that receives a Neighbor Solicitation for the same address regards the situation as a collision and ceases to solicit for the address.
In either case, SEND counters these threats by requiring that the RSA Signature and CGA options be present in these solicitations.
SEND nodes can send Router Solicitation messages with a CGA source address and a CGA option, which the router can verify so that the Neighbor Cache binding is correct. If a SEND node must send a Router Solicitation with the unspecified address, the router will not update its Neighbor Cache, as per base NDP.
2. Entries made as a result of a Neighbor Advertisement message. SEND counters this threat by requiring that the RSA Signature and CGA options be present in these advertisements.
2. Neighbor Unreachability Detection Failure
SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes include an RSA Signature option and proof of authorization to use the interface identifier in the address being probed. If these prerequisites are not met, the node performing NUD discards the responses.
3. Duplicate Address Detection DoS Attack
SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD include an RSA Signature option and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses.
When a SEND node performs DAD, it may listen for address collisions from non-SEND nodes for the first address it generates, but not for new attempts. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node.
4. Router Solicitation and Advertisement Attacks
SEND counters them by requiring that Router Advertisements contain an RSA Signature option and that the signature is calculated by using the public key of a node that can prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves its authorization by showing a certificate containing the specific prefix or an indication that the router is allowed to route any prefix. A Router Advertisement without these protections is discarded.
5. Replay Attacks
SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by including a Nonce option in the solicitation and requiring that the advertisement include a matching option. Together with the signatures, this forms a challenge-response protocol.
SEND protects against attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects by including a Timestamp option. The following security issues are relevant only for unsolicited messages:
- A window of vulnerability for replay attacks exists until the time stamp expires.
However, such vulnerabilities are only useful for attackers if the advertised parameters change during the window. Although some parameters (such as the remaining lifetime of a prefix) change often, radical changes typically happen only in the context of some special case, such as switching to a new link-layer address due to a broken interface adapter.
SEND nodes are also protected against replay attacks as long as they cache the state created by the message containing the timestamp. The cached state allows the node to protect itself against replayed messages. However, once the node flushes the state for whatever reason, an attacker can re-create the state by replaying an old message while the timestamp is still valid. Because most SEND nodes are likely to use fairly coarse-grained timestamps.
- Attacks against time synchronization protocols such as NTP may cause SEND nodes to have an incorrect timestamp value. This can be used to launch replay attacks, even outside the normal window of vulnerability. To protect against these attacks, it is recommended that SEND nodes keep independently maintained clocks or apply suitable security measures for the time synchronization protocols.
6. Neighbor Discovery DoS Attack
The attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself by performing Neighbor Solicitations for addresses that do not exist. SEND does not address this threat because it can be addressed by techniques such as rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These are all techniques involved in implementing Neighbor Discovery on the router.
Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism has some security considerations. Some Denial-of-Service attacks remain against NDP and SEND itself. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify by using asymmetric methods. Although safeguards are required to prevent excessive use of resources, this can still render SEND non-operational.
A simple hash verification of the CGA property of the address is performed before the more expensive signature verification. However, even if the CGA verification succeeds, no claims about the validity of the message can be made until the signature has been checked.
When trust anchors and certificates are used for address validation in SEND, the defenses are not quite as effective. Implementations SHOULD track the resources devoted to the processing of packets received with the RSA Signature option and start selectively discarding packets if too many resources are spent. Implementations MAY also first discard packets that are not protected with CGA.
The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by requesting that a large number of certification paths be discovered for different trust anchors. Routers SHOULD defend against such attacks by caching discovered information including negative responses) and by limiting the number of different discovery processes in which they engage.
Attackers may also target hosts by sending a large number of unnecessary certification paths, forcing hosts to spend useless memory and verification resources on them. Hosts can defend against such attacks by limiting the number of resources devoted to the certification paths and their verification. Hosts SHOULD also prioritize advertisements sent as a response to solicitations the hosts have sent about unsolicited advertisements.