Network Working Group J. Arkko, Ed. Request for Comments: 3971 Ericsson Category: Standards Track J. Kempf DoCoMo Communications Labs USA B. Zill Microsoft P. Nikander Ericsson March 2005 SEcure Neighbor Discovery (SEND) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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.
Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . 4 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6 4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9 5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. Processing Rules for Senders. . . . . . . . . . 11 5.1.2. Processing Rules for Receivers. . . . . . . . . 12 5.1.3. Configuration . . . . . . . . . . . . . . . . . 13 5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14 5.2.1. Processing Rules for Senders. . . . . . . . . . 16 5.2.2. Processing Rules for Receivers. . . . . . . . . 16 5.2.3. Configuration . . . . . . . . . . . . . . . . . 17 5.2.4. Performance Considerations. . . . . . . . . . . 18 5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19 5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19 5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20 5.3.3. Processing Rules for Senders. . . . . . . . . . 21 5.3.4. Processing Rules for Receivers. . . . . . . . . 21 6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24 6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24 6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25 6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26 6.3.1. Router Authorization Certificate Profile. . . . 26 6.3.2. Suitability of Standard Identity Certificates . 29 6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29 6.4.1. Certification Path Solicitation Message Format. 30 6.4.2. Certification Path Advertisement Message Format 32 6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34 6.4.4. Certificate Option. . . . . . . . . . . . . . . 36 6.4.5. Processing Rules for Routers. . . . . . . . . . 37 6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38 6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39 7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40 7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40 7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9.1. Threats to the Local Link Not Covered by SEND . . . . . 44 9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45 9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45 9.2.2. Neighbor Unreachability Detection Failure . . . 46 9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
9.2.4. Router Solicitation and Advertisement Attacks . 46 9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47 9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48 9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48 10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49 10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50 12.1. Normative References. . . . . . . . . . . . . . . . . . 50 12.2. Informative References. . . . . . . . . . . . . . . . . 51 Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 A. Contributors and Acknowledgments. . . . . . . . . . . . 53 B. Cache Management. . . . . . . . . . . . . . . . . . . . 53 C. Message Size When Carrying Certificates . . . . . . . . 54 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55 Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56 1. Introduction IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461  and 2462 . Nodes on the same link use NDP to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. NDP is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection. The original NDP specifications called for the use of IPsec to protect NDP messages. However, the RFCs do not give detailed instructions for using IPsec to do this. In this particular application, IPsec can only be used with a manual configuration of security associations, due to bootstrapping problems in using IKE [19, 15]. Furthermore, the number of manually configured security associations needed for protecting NDP can be very large , making that approach impractical for most purposes. The SEND protocol is designed to counter the threats to NDP. These threats are described in detail in . SEND is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on NDP are a concern. This document is organized as follows. Sections 2 and 3 define some terminology and present a brief review of NDP, respectively. Section 4 describes the overall approach to securing NDP. This approach involves the use of new NDP options to carry public key - based signatures. A zero-configuration mechanism is used for showing
address ownership on individual nodes; routers are certified by a trust anchor . The formats, procedures, and cryptographic mechanisms for the zero-configuration mechanism are described in a related specification . The required new NDP options are discussed in Section 5. Section 6 describes the mechanism for distributing certification paths to establish an authorization delegation chain to a trust anchor. Finally, Section 8 discusses the co-existence of secured and unsecured NDP on the same link, and Section 9 discusses security considerations for SEcure Neighbor Discovery (SEND). The use of identity certificates provisioned on end hosts for authorizing address use is out of the scope for this document, as is the security of NDP when the entity defending an address is not the same as the entity claiming that address (also known as "proxy ND"). These are extensions of SEND that may be treated in separate documents, should the need arise. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" are to be interpreted as described in . 2. Terms Authorization Delegation Discovery (ADD) A process through which SEND nodes can acquire a certification path from a peer node to a trust anchor. Certificate Revocation List (CRL) In one method of certificate revocation, an authority periodically issues a signed data structure called the Certificate Revocation List. This is a time-stamped list identifying revoked certificates, signed by the issuer, and made freely available in a public repository. Certification Path Advertisement (CPA) The advertisement message used in the ADD process.
Certification Path Solicitation (CPS) The solicitation message used in the ADD process. Cryptographically Generated Address (CGA) A technique  whereby an IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key and some other parameters. Distinguished Encoding Rules (DER) An encoding scheme for data values, defined in . Duplicate Address Detection (DAD) A mechanism assuring that two IPv6 nodes on the same link are not using the same address. Fully Qualified Domain Name (FQDN) A fully qualified domain name consists of a host and domain name, including the top-level domain. Internationalized Domain Name (IDN) Internationalized Domain Names can be used to represent domain names that contain characters outside the ASCII set. See RFC 3490 . Neighbor Discovery (ND) The Neighbor Discovery function of the Neighbor Discovery Protocol (NDP). NDP contains functions besides ND. Neighbor Discovery Protocol (NDP) The IPv6 Neighbor Discovery Protocol [7, 8]. The Neighbor Discovery Protocol is a part of ICMPv6 . Neighbor Unreachability Detection (NUD) A mechanism used for tracking the reachability of neighbors.
Non-SEND node An IPv6 node that does not implement this specification but uses only the Neighbor Discovery protocol defined in RFCs 2461 and 2462, as updated, without security. Nonce An unpredictable random or pseudo-random number generated by a node and used exactly once. In SEND, nonces are used to assure that a particular advertisement is linked to the solicitation that triggered it. Router Authorization Certificate An X.509v3  public key certificate using the profile specified in Section 6.3.1. SEND node An IPv6 node that implements this specification. Router Discovery (RD) Router Discovery allows the hosts to discover what routers exist on the link, and what subnet prefixes are available. Router Discovery is a part of the Neighbor Discovery Protocol. Trust Anchor Hosts are configured with a set of trust anchors to protect Router Discovery. A trust anchor is an entity that the host trusts to authorize routers to act as routers. A trust anchor configuration consists of a public key and some associated parameters (see Section 6.5 for a detailed explanation of these parameters). 3. Neighbor and Router Discovery Overview The Neighbor Discovery Protocol has several functions. Many of these are overloaded on a few central message types, such as the ICMPv6 Neighbor Advertisement message. In this section, we review some of these tasks and their effects in order to better understand how the messages should be treated. This section is not normative, and if this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs, as updated, take precedence.
The main functions of NDP are as follows: o The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link. Router Discovery is described in Section 6 of RFC 2461 . The main purpose of Router Discovery is to find neighboring routers willing to forward packets on behalf of hosts. Subnet prefix discovery involves determining which destinations are directly on a link; this information is necessary in order to know whether a packet should be sent to a router or directly to the destination node. o The Redirect function is used for automatically redirecting a host to a better first-hop router, or to inform hosts that a destination is in fact a neighbor (i.e., on-link). Redirect is specified in Section 8 of RFC 2461 . o Address Autoconfiguration is used for automatically assigning addresses to a host . This allows hosts to operate without explicit configuration related to IP connectivity. The default autoconfiguration mechanism is stateless. To create IP addresses, hosts use any prefix information delivered to them during Router Discovery and then test the newly formed addresses for uniqueness. A stateful mechanism, DHCPv6 , provides additional autoconfiguration features. o Duplicate Address Detection (DAD) is used for preventing address collisions : for instance, during Address Autoconfiguration. A node that intends to assign a new address to one of its interfaces first runs the DAD procedure to verify that no other node is using the same address. As the rules forbid the use of an address until it has been found unique, no higher layer traffic is possible until this procedure has been completed. Thus, preventing attacks against DAD can help ensure the availability of communications for the node in question. o The Address Resolution function allows a node on the link to resolve another node's IPv6 address to the corresponding link- layer address. Address Resolution is defined in Section 7.2 of RFC 2461 , and it is used for hosts and routers alike. Again, no higher level traffic can proceed until the sender knows the link layer address of the destination node or the next hop router. Note that the source link layer address on link layer frames is not checked against the information learned through Address Resolution. This allows for an easier addition of network elements such as bridges and proxies and eases the stack implementation requirements, as less information has to be passed from layer to layer.
o Neighbor Unreachability Detection (NUD) is used for tracking the reachability of neighboring nodes, both hosts and routers. NUD is defined in Section 7.3 of RFC 2461 . NUD is security sensitive, because an attacker could claim that reachability exists when in fact it does not. The NDP messages follow the ICMPv6 message format. All NDP functions are realized by using the Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Redirect messages. An actual NDP message includes an NDP message header, consisting of an ICMPv6 header and ND message-specific data, and zero or more NDP options. The NDP message options are formatted in the Type-Length-Value format. <------------NDP Message----------------> *-------------------------------------------------------------* | IPv6 Header | ICMPv6 | ND Message- | ND Message | | Next Header = 58 | Header | specific | Options | | (ICMPv6) | | data | | *-------------------------------------------------------------* <--NDP Message header--> 4. Secure Neighbor Discovery Overview To secure the various functions in NDP, a set of new Neighbor Discovery options is introduced. They are used to protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP. The components of the solution specified in this document are as follows: o Certification 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.
o Cryptographically Generated Addresses are used to make sure that the sender of a Neighbor Discovery message is the "owner" of the claimed address. A public-private key pair is generated by all nodes before they can claim an address. A new NDP option, the CGA option, is used to carry the public key and associated parameters. This specification also allows a node to use non-CGAs with certificates that authorize their use. However, the details of such use are beyond the scope of this specification and are left for future work. o A new NDP option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery. Public key signatures protect the integrity of the messages and authenticate the identity of their sender. The authority of a public key is established either with the authorization delegation process, by using certificates, or through the address ownership proof mechanism, by using CGAs, or with both, depending on configuration and the type of the message protected. Note: RSA is mandated because having multiple signature algorithms would break compatibility between implementations or increase implementation complexity by forcing the implementation of multiple algorithms and the mechanism to select among them. A second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA. If this happens, a stronger signature algorithm can be selected, and SEND can be revised. The relationship between the new algorithm and the RSA- based SEND described in this document would be similar to that between the RSA-based SEND and Neighbor Discovery without SEND. Information signed with the stronger algorithm has precedence over that signed with RSA, in the same way that RSA-signed information now takes precedence over unsigned information. Implementations of the current and revised specs would still be compatible. o In order to prevent replay attacks, two new Neighbor Discovery options, Timestamp and Nonce, 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. 5. Neighbor Discovery Protocol Options The options described in this section MUST be supported.
5.1. CGA Option The CGA option allows the verification of the sender's CGA. The format of the CGA option is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Pad Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . CGA Parameters . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 11 Length The length of the option (including the Type, Length, Pad Length, Reserved, CGA Parameters, and Padding fields) in units of 8 octets. Pad Length The number of padding octets beyond the end of the CGA Parameters field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
CGA Parameters A variable-length field containing the CGA Parameters data structure described in Section 4 of . This specification requires that if both the CGA option and the RSA Signature option are present, then the public key found from the CGA Parameters field in the CGA option MUST be that referred by the Key Hash field in the RSA Signature option. Packets received with two different keys MUST be silently discarded. Note that a future extension may provide a mechanism allowing the owner of an address and the signer to be different parties. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. 5.1.1. Processing Rules for Senders If the node has been configured to use 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. The CGA option MAY be present in other messages. A node sending a message using the CGA option MUST construct the message as follows: The CGA Parameter field in the CGA option is filled according to the rules presented above and in . The public key in the field is taken from the configuration used to generate the CGA, typically from a data structure associated with the source address. The address MUST be constructed as specified in Section 4 of . Depending on the type of the message, this address appears in different places, as follows: Redirect The address MUST be the source address of the message. Neighbor Solicitation The address MUST be the Target Address for solicitations sent for Duplicate Address Detection; otherwise it MUST be the source address of the message.
Neighbor Advertisement The address MUST be the source address of the message. Router Solicitation The address MUST be the source address of the message. Note that the CGA option is not used when the source address is the unspecified address. Router Advertisement The address MUST be the source address of the message. 5.1.2. Processing Rules for Receivers Neighbor Solicitation and Advertisement messages without the CGA option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured messages. Router Solicitation messages without the CGA option MUST also be treated as unsecured, unless the source address of the message is the unspecified address. Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing a CGA option MUST be checked as follows: If the interface has been configured to use CGA, the receiving node MUST verify the source address of the packet by using the algorithm described in Section 5 of . The inputs to the algorithm are the claimed address, as defined in the previous section, and the CGA Parameters field. If the CGA verification is successful, the recipient proceeds with a more time-consuming cryptographic check of the signature. Note that even if the CGA verification succeeds, no claims about the validity of the use can be made until the signature has been checked. A receiver that does not support CGA or has not specified its use for a given interface can still verify packets by using trust anchors, even if a CGA is used on a packet. In such a case, the CGA property of the address is simply left unverified.
5.1.3. Configuration All nodes that support the verification of the CGA option MUST record the following configuration information: minbits The minimum acceptable key length for public keys used in the generation of CGAs. The default SHOULD be 1024 bits. Implementations MAY also set an upper limit for the amount of computation needed when verifying packets that use these security associations. The upper limit SHOULD be at least 2048 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths. All nodes that support the sending of the CGA option MUST record the following configuration information: CGA parameters Any information required to construct CGAs, as described in .
5.2. RSA Signature Option The RSA Signature option allows public key-based signatures to be attached to NDP messages. The format of the RSA Signature option is described in the following diagram: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Hash | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital Signature . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 12 Length The length of the option (including the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets. Reserved A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
Key Hash A 128-bit field containing the most significant (leftmost) 128 bits of a SHA-1  hash of the public key used for constructing the signature. The SHA-1 hash is taken over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message. Digital Signature A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets: 1. The 128-bit CGA Message Type tag  value for SEND, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been generated randomly by the editor of this specification.). 2. The 128-bit Source Address field from the IP header. 3. The 128-bit Destination Address field from the IP header. 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header. 5. The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options. 6. All NDP options preceding the RSA Signature option. The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in . This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field). Padding This variable-length field contains padding, as many bytes long as remain after the end of the signature.
5.2.1. Processing Rules for Senders If the node has been configured to use SEND, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages MUST contain the RSA Signature option. Router Solicitation messages not sent with the unspecified source address MUST contain the RSA Signature option. A node sending a message with the RSA Signature option MUST construct the message as follows: o The message is constructed in its entirety, without the RSA Signature option. o The RSA Signature option is added as the last option in the message. o The data to be signed is constructed as explained in Section 5.2, under the description of the Digital Signature field. o The message, in the form defined above, is signed by using the configured private key, and the resulting PKCS#1 v1.5 signature is put in the Digital Signature field. 5.2.2. Processing Rules for Receivers Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages without the RSA Signature option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). See Section 8. Router Solicitation messages without the RSA Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address. Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing an RSA Signature option MUST be checked as follows: o The receiver MUST ignore any options that come after the first RSA Signature option. (The options are ignored for both signature verification and NDP processing purposes.) o The Key Hash field MUST indicate the use of a known public key, either one learned from a preceding CGA option in the same message, or one known by other means.
o The Digital Signature field MUST have correct encoding and MUST not exceed the length of the RSA Signature option minus the Padding. o The Digital Signature verification MUST show that the signature has been calculated as specified in the previous section. o If the use of a trust anchor has been configured, a valid certification path (see Section 6.3) between the receiver's trust anchor and the sender's public key MUST be known. Note that the receiver may verify just the CGA property of a packet, even if, in addition to CGA, the sender has used a trust anchor. Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack). 5.2.3. Configuration All nodes that support the reception of the RSA Signature options MUST allow the following information to be configured for each separate NDP message type: authorization method This parameter determines the method through which the authority of the sender is determined. It can have four values: trust anchor The authority of the sender is verified as described in Section 6.3. The sender may claim additional authorization through the use of CGAs, but this is neither required nor verified. CGA The CGA property of the sender's address is verified as described in . The sender may claim additional authority through a trust anchor, but this is neither required nor verified.
trust anchor and CGA Both the trust anchor and the CGA verification is required. trust anchor or CGA Either the trust anchor or the CGA verification is required. anchor The allowed trust anchor(s), if the authorization method is not set to CGA. All nodes that support sending RSA Signature options MUST record the following configuration information: keypair A public-private key pair. If authorization delegation is in use, a certification path from a trust anchor to this key pair must exist. CGA flag A flag that indicates whether CGA is used or not. This flag may be per interface or per node. (Note that in future extensions of the SEND protocol, this flag may also be per subnet prefix.) 5.2.4. Performance Considerations The construction and verification of the RSA Signature option is computationally expensive. In the NDP context, however, hosts typically only have to perform a few signature operations as they enter a link, a few operations as they find a new on-link peer with which to communicate, or Neighbor Unreachability Detection with existing neighbors. Routers are required to perform a larger number of operations, particularly when the frequency of router advertisements is high due to mobility requirements. Still, the number of required signature operations is on the order of a few dozen per second, some of which can be precomputed as explained below. A large number of router solicitations may cause a higher demand for performing asymmetric operations, although the base NDP protocol limits the rate at which multicast responses to solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor and Router Advertisements if the timing of the future advertisements is known. Typically, solicited neighbor advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the signature, it is not possible to precompute solicited advertisements. 5.3. Timestamp and Nonce Options 5.3.1. Timestamp Option The purpose of the Timestamp option is to make sure that unsolicited advertisements and redirects have not been replayed. The format of this option is described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 13 Length The length of the option (including the Type, Length, Reserved, and Timestamp fields) in units of 8 octets; i.e., 2. Reserved A 48-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Timestamp A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64K fractions of a second. Implementation note: This format is compatible with the usual representation of time under UNIX, although the number of bits available for the integer and fraction parts may vary. 5.3.2. Nonce Option The purpose of the Nonce option is to make sure that an advertisement is a fresh response to a solicitation sent earlier by the node. The format of this option is described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Nonce ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 Length The length of the option (including the Type, Length, and Nonce fields) in units of 8 octets. Nonce A field containing a random number selected by the sender of the solicitation message. The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets.
5.3.3. Processing Rules for Senders If the node has been configured to use SEND, all solicitation messages MUST include a Nonce. When sending a solicitation, the sender MUST store the nonce internally so that it can recognize any replies containing that particular nonce. If the node has been configured to use SEND, all advertisements sent in reply to a solicitation MUST include a Nonce, copied from the received solicitation. Note that routers may decide to send a multicast advertisement to all nodes instead of a response to a specific host. In such a case, the router MAY still include the nonce value for the host that triggered the multicast advertisement. (Omitting the nonce value may cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps function properly.) If the node has been configured to use SEND, all solicitation, advertisement, and redirect messages MUST include a Timestamp. Senders SHOULD set the Timestamp field to the current time, according to their real time clocks. 5.3.4. Processing Rules for Receivers The processing of the Nonce and Timestamp options depends on whether a packet is a solicited advertisement. A system may implement the distinction in various ways. Section 22.214.171.124 defines the processing rules for solicited advertisements. Section 126.96.36.199 defines the processing rules for all other messages. In addition, the following rules apply in all cases: o Messages received without at least one of the Timestamp and Nonce options MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). o Messages received with the RSA Signature option but without the Timestamp option MUST be silently discarded. o Solicitation messages received with the RSA Signature option but without the Nonce option MUST be silently discarded. o Advertisements sent to a unicast destination address with the RSA Signature option but without a Nonce option SHOULD be processed as unsolicited advertisements.
o An implementation MAY use some mechanism such as a timestamp cache to strengthen resistance to replay attacks. When there is a very large number of nodes on the same link, or when a cache filling attack is in progress, it is possible that the cache holding the most recent timestamp per sender will become full. In this case, the node MUST remove some entries from the cache or refuse some new requested entries. The specific policy as to which entries are preferred over others is left as an implementation decision. However, typical policies may prefer existing entries to new ones, CGAs with a large Sec value to smaller Sec values, and so on. The issue is briefly discussed in Appendix B. o The receiver MUST be prepared to receive the Timestamp and Nonce options in any order, as per RFC 2461 , Section 9. 188.8.131.52. Processing Solicited Advertisements The receiver MUST verify that it has recently sent a matching solicitation, and that the received advertisement contains a copy of the Nonce sent in the solicitation. If the message contains a Nonce option but the Nonce value is not recognized, the message MUST be silently discarded. Otherwise, if the message does not contain a Nonce option, it MAY be considered an unsolicited advertisement and processed according to Section 184.108.40.206. If the message is accepted, the receiver SHOULD store the receive time of the message and the timestamp time in the message, as specified in Section 220.127.116.11. 18.104.22.168. Processing All Other Messages Receivers SHOULD be configured with an allowed timestamp Delta value, a "fuzz factor" for comparisons, and an allowed clock drift parameter. The recommended default value for the allowed Delta is TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ; and for clock drift, TIMESTAMP_DRIFT (see Section 10.2). To facilitate timestamp checking, each node SHOULD store the following information for each peer: o The receive time of the last received and accepted SEND message. This is called RDlast. o The time stamp in the last received and accepted SEND message. This is called TSlast.
An accepted SEND message is any successfully verified Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, or Redirect message from the given peer. The RSA Signature option MUST be used in such a message before it can update the above variables. Receivers SHOULD then check the Timestamp field as follows: o When a message is received from a new peer (i.e., one that is not stored in the cache), the received timestamp, TSnew, is checked, and the packet is accepted if the timestamp is recent enough to the reception time of the packet, RDnew: -Delta < (RDnew - TSnew) < +Delta The RDnew and TSnew values SHOULD be stored in the cache as RDlast and TSlast. o If the timestamp is NOT within the boundaries but the message is a Neighbor Solicitation message that the receiver should answer, the receiver SHOULD respond to the message. However, even if it does respond to the message, it MUST NOT create a Neighbor Cache entry. This allows nodes that have large differences in their clocks to continue communicating with each other by exchanging NS/NA pairs. o When a message is received from a known peer (i.e., one that already has an entry in the cache), the timestamp is checked against the previously received SEND message: TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz If this inequality does not hold, the receiver SHOULD silently discard the message. If, on the other hand, the inequality holds, the receiver SHOULD process the message. Moreover, if the above inequality holds and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. Otherwise, the receiver MUST NOT update RDlast or TSlast. As unsolicited messages may be used in a Denial-of-Service attack to make the receiver verify computationally expensive signatures, all nodes SHOULD apply a mechanism to prevent excessive use of resources for processing such messages.