rfc-3971

SEcure Neighbor Discovery (SEND)

J. Arkko (Editor), J. Kempf, B. Zill, P. Nikander
date2005-03 streamIETF areaint wgsend statusPROPOSED STANDARD pages56 canonicalhttps://www.rfc-editor.org/rfc/rfc3971 doi10.17487/RFC3971 errataview
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. [STANDARDS-TRACK]

updated by

Extracted elements (32)

design-rationale §6.4

Certification Path Solicitation and Advertisement messages are kept separate from Router and Neighbor Discovery messages to reduce the impact of potentially voluminous certificate path data on other NDP messages, thereby avoiding excessive IP fragmentation.

security, ip, pkix

design-rationale §4

RSA is the sole mandated signature algorithm in SEND. Multiple signature algorithms would either break interoperability between implementations or require implementing all of them plus a selection mechanism. A second algorithm is only needed as a recovery mechanism if RSA is found to be flawed.

security, crypto

design-rationale §1

SEND avoids IPsec because IKE bootstrapping problems require manual security association configuration for NDP protection, and the number of manually configured SAs needed is impractically large for most deployments. A new approach using public-key-based NDP options was developed instead.

security, ip, crypto

interoperability-note §5.1.2

SEND nodes interoperate with non-SEND nodes by treating unsigned NDP messages as unsecured and processing them according to Section 8. SEND nodes that do not wish to interoperate with non-SEND nodes MAY simply discard messages lacking the CGA or RSA Signature options.

security, ip

normative-requirement §7.1 SHOULD

By default, a SEND-enabled node SHOULD use only CGAs for its own addresses. Upon receiving a Redirect, the receiver MUST verify that the Target Address falls within the range defined by the router's certificate; failing Redirect messages MUST be treated as unsecured.

security, ip

normative-requirement §6.3.1 MUST

Hosts MUST check that the last certificate in the certification path contains an RSA public key (subjectPublicKeyInfo); certificates without an RSA key MUST be disregarded for SEND. The certification path MUST start from the identity of a trust anchor shared by host and router.

security, pkix, crypto

normative-requirement §6.4.6 MUST

Hosts MUST send CPS messages to the All-Routers multicast address if no default router has been selected, or to the default router's IP address if one has been selected. If there is no response within CPS_RETRY seconds, the host MUST retry with exponentially doubling wait intervals, abandoning after CPS_RETRY_MAX seconds.

security, ip

normative-requirement §5.1 MUST

If both the CGA option and RSA Signature option are present in a message, the public key in the CGA Parameters field MUST be the same key referenced by the Key Hash field in the RSA Signature option; packets received with two different keys MUST be silently discarded.

security, ip, crypto

normative-requirement §5.3.4 MUST

Messages received without at least one of the Timestamp and Nonce options MUST be treated as unsecured. Messages bearing the RSA Signature option but lacking the Timestamp option MUST be silently discarded; solicitations with RSA Signature but no Nonce MUST also be silently discarded.

security, ip

normative-requirement §5.1.2 MUST

NS and NA messages without the CGA option MUST be treated as unsecured. Receivers that do not support CGA for a given interface may still verify packets using trust anchors, leaving the CGA property unverified.

security, ip

normative-requirement §5.2.2 MUST

Receivers MUST ignore any options that follow the first RSA Signature option (for both signature verification and NDP processing). NS, NA, RA, and Redirect messages without the RSA Signature option MUST be treated as unsecured.

security, ip

normative-requirement §5.1.3 SHOULD

The minimum acceptable key length (minbits) for CGA public keys SHOULD default to 1024 bits; the upper limit for verification computation SHOULD be at least 2048 bits.

security, crypto

normative-requirement §6.3.1 MUST

The Router Authorization Certificate is an X.509v3 certificate whose IP address delegation extension MUST contain at least one addressesOrRanges element with an IPv6 address prefix (AFI 0002). The IP addresses in each certificate's delegation extension MUST be a subset of those in the issuer's certificate.

security, pkix, ip

normative-requirement §6.3.1 MUST

When a host cannot perform an online CRL check (because it has no Internet connection yet), acceptance of the router certificate MUST be considered provisional; the host MUST perform the CRL check as soon as a connection is established and SHOULD immediately stop using the router if the check fails or is disrupted.

security, pkix, ip

normative-requirement §5.3.3 MUST

When using SEND, all solicitation messages MUST include a Nonce (stored by the sender for reply matching); all reply advertisements MUST copy the Nonce from the solicitation; and all solicitation, advertisement, and redirect messages MUST include a Timestamp.

security, ip

normative-requirement §5.2.1 MUST

When using SEND, NS, NA, RA, and Redirect messages MUST contain the RSA Signature option added as the last option in the message. Router Solicitation messages not sent with the unspecified source address MUST also contain the RSA Signature option.

security, ip, crypto

normative-requirement §5.1.1 MUST

When using SEND, the CGA option MUST be present in all Neighbor Solicitation and Advertisement messages, and MUST be present in Router Solicitation messages unless they are sent with the unspecified source address.

security, ip

protocol-element §6.4.4

The Certificate Option (Type 16) carries a single X.509v3 certificate (Cert Type=1) used to establish a segment of a certification path to a trust anchor, transported in CPA messages one certificate per option.

security, pkix, ip

protocol-element §6.4.2

The Certification Path Advertisement (CPA) is a new ICMPv6 message (Type 149) sent by routers in response to CPS. It includes Identifier, All Components (total number of certificates in path), and Component (index of current certificate, sent in order from trust-anchor end, with the trust anchor's own certificate omitted).

security, pkix, ip

protocol-element §6.4.1

The Certification Path Solicitation (CPS) is a new ICMPv6 message (Type 148) sent by hosts to prompt routers to supply a certification path. It includes a non-zero randomly generated 16-bit Identifier and a Component field (65535 = request all certificates).

security, pkix, ip

protocol-element §5.1

The CGA Option (Type 11) carries the CGA Parameters data structure (containing the node's public key and associated parameters as defined in RFC 3972) to allow receivers to verify that the sender owns the claimed IPv6 address. It includes Type, Length, Pad Length, Reserved, CGA Parameters, and variable-length Padding fields.

security, ip, crypto

protocol-element §5.2

The RSA Signature Option (Type 12) Digital Signature field is computed over: (1) a 128-bit CGA Message Type tag for SEND (0x086FCA5E10B200C99C8CE001642...77C08), (2) source and destination IPv6 addresses, (3) ICMPv6 Type, Code, and Checksum, (4) the NDP message header, and (5) all NDP options preceding the RSA Signature option.

security, crypto, ip

protocol-element §6.4.3

The Trust Anchor Option (Type 15) identifies a trust anchor by Name Type: value 1 (mandatory) indicates a DER Encoded X.501 Name; value 2 (optional) indicates an FQDN in DNS wire format. Used in CPS messages to specify which anchor the host trusts, and in CPA messages to indicate which anchor the path was built for.

security, pkix, ip

registry §11

SEND registers six new IPv6 Neighbor Discovery option types (CGA Option=11, RSA Signature Option=12, Timestamp Option=13, Nonce Option=14, Trust Anchor Option=15, Certificate Option=16) and two new ICMPv6 message types (Certification Path Solicitation=148, Certification Path Advertisement=149).

registry, ip, security

security-consideration §5.2.2

RSA signature verification is computationally expensive and can be exploited in a CPU-exhaustion DoS attack by flooding a node with unsolicited NDP messages. All nodes SHOULD apply rate-limiting for unsolicited message processing; receivers MAY silently discard packets under apparent DoS conditions.

security, ip

security-consideration §9.2.1

SEND counters Neighbor Solicitation/Advertisement spoofing by requiring senders to prove ownership of their IPv6 address via CGAs: since the interface identifier is derived from the node's public key, only the holder of the private key can produce a valid RSA signature for that CGA.

security, ip, crypto

security-consideration §9.2.5

SEND counters replay attacks using Timestamp options (checked against a per-peer Delta/drift window) for unsolicited messages, and Nonce options (must echo the solicitation's nonce) for solicitation-advertisement pairs. Both mechanisms are mandatory for a message to be considered secured.

security, ip

security-consideration §9.1

SEND does not protect against threats requiring physical access to the link or involving a compromised router. It is specifically designed for environments where physical link security is not assured (e.g., wireless), and threats from within the link (e.g., a malicious router that passes certification but misuses its role) are outside SEND's scope.

security, ip

state-machine §5.3.4.2

Timestamp validation distinguishes two states: new peer — accept if -Delta < (RDnew - TSnew) < +Delta and store as RDlast/TSlast; known peer — accept if TSnew + fuzz > TSlast + (RDnew - RDlast)×(1-drift) - fuzz, updating RDlast/TSlast only when TSnew > TSlast.

security, ip

wire-format §5.3.2

The Nonce Option (Type 14) carries a random nonce value of at least 6 bytes chosen by the solicitation sender. The total option length must be a multiple of 8 octets.

security, ip

wire-format §5.2

The RSA Signature Option (Type 12) contains a 16-bit Reserved field, a 128-bit Key Hash field (leftmost 128 bits of SHA-1 over the sender's public key), a variable-length Digital Signature field (RSASSA-PKCS1-v1_5 with SHA-1), and variable-length Padding to align to 8-octet boundaries.

security, crypto, ip

wire-format §5.3.1

The Timestamp Option (Type 13, fixed Length=2) carries a 64-bit unsigned integer: the first 48 bits encode integer seconds since 1970-01-01 00:00 UTC; the remaining 16 bits encode 1/65536 fractions of a second. Preceded by a 48-bit Reserved field.

security, ip