RFC 3971
SEcure Neighbor Discovery (SEND)
Network Working Group RFC 3971 ✨ SEcure Neighbor Discovery (SEND) 🦋
okay bestie, let's get into this one. 💖 RFC 3971 is the SEcure Neighbor Discovery (SEND) spec, and it's a Standards Track document from March 2005 🌸. The authors are J. Arkko (Ed.) from Ericsson, J. Kempf from DoCoMo Communications Labs USA, B. Zill from Microsoft, and P. Nikander from Ericsson 👑. It's categorised as Standards Track, which means it's a real protocol spec the internet community is meant to implement 💅.
Nothing in the title block says it obsoletes or updates another RFC, so it doesn't replace anything and doesn't change anything else 🫶.
Okay, so what's the drama? 🙈 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to find each other on the link, figure out each other's link-layer addresses, find routers, and keep tabs on whether the paths to their neighbours are still working. Without any security, NDP is super vulnerable to attacks 💀. This document is the fix 🔥. It specifies security mechanisms for NDP, and unlike the original NDP specs, it doesn't use IPsec ✨.
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements 💜. For the standardisation state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🌈. Distribution of this memo is unlimited 🎀.
Copyright Notice 💅
Copyright (C) The Internet Society (2005) 🦋.
Abstract 🧚
IPv6 nodes use NDP to discover other nodes on the link 🌸, determine their link-layer addresses, find routers 👑, and maintain reachability information about the paths to active neighbours 🔥. If NDP isn't secured, it's vulnerable to all kinds of attacks 💀. This document specifies security mechanisms for NDP ✨. Unlike the original NDP specifications, these mechanisms don't 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 . . . . . . . . . . . . . . . . . . . . 561. Introduction 🌷
1. Introduction 🌷
IPv6 defines NDP in RFCs 2461 [4] and 2462 [5] 📚. Nodes on the same link use NDP to discover each other's presence and link-layer addresses 👀, find routers 🛣️, and keep reachability info about paths to active neighbours 💖. 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 specs called for IPsec to protect NDP messages 🔐. But the RFCs don't give detailed instructions for doing that 🙃. In this particular application, IPsec can only be used with manually configured security associations, because of bootstrapping problems in using IKE [19, 15] 😩. On top of that, the number of manually configured security associations needed to protect NDP can be very large [20] 😭, which makes that approach impractical for most purposes 💀.
SEND is designed to counter the threats to NDP 🛡️. These threats are described in detail in [22] 📖. SEND is applicable in environments where physical security on the link isn't assured (like over wireless 📶), and where attacks on NDP are a concern ⚠️.
This document is organised like this 🗺️. Sections 2 and 3 define some terminology and give a brief review of NDP 🧠. Section 4 describes the overall approach to securing NDP 🔑. That approach uses new NDP options to carry public key-based signatures 🗝️. A zero-configuration mechanism shows address ownership on individual nodes, and routers are certified by a trust anchor [7] 🌟. The formats, procedures, and cryptographic mechanisms for the zero-configuration mechanism are described in a related specification [11] 📘.
The required new NDP options are discussed in Section 5 🧩. Section 6 describes how certification paths are distributed to establish an authorization delegation chain to a trust anchor 🔗.
Finally, Section 8 covers co-existence of secured and unsecured NDP on the same link 🤝, and Section 9 covers security considerations for SEcure Neighbor Discovery (SEND) 🚨.
The use of identity certificates provisioned on end hosts for authorising address use is out of scope for this document 🙅♀️. So is the security of NDP when the entity defending an address isn't the same as the entity claiming it (also known as "proxy ND") 👻. These could be extensions of SEND 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 capitalised. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" are to be interpreted as described in [2] 💅.
Part 1 of 11 is done bestie 🎀. Next up is Section 2 (Terms) 💜.
2. Terms ✨
Authorization Delegation Discovery (ADD)
Okay so this is the process where SEND nodes go hunting for a certification path from a peer node all the way 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. It's a time-stamped list of revoked certificates, signed by the issuer and made freely available in a public repository 📜🌸
Certification Path Advertisement (CPA)
This is the advertisement message used in the ADD process 📣
Certification Path Solicitation (CPS)
This is the solicitation message used in the ADD process 🙋♀️
Cryptographically Generated Address (CGA)
A technique [11] where a node's IPv6 address is cryptographically generated, using a one-way hash function on the node's public key plus some other parameters. It's giving math magic 🪄🔐
Distinguished Encoding Rules (DER)
An encoding scheme for data values, defined in [12] 🧾
Duplicate Address Detection (DAD)
A mechanism that makes sure two IPv6 nodes on the same link aren't using the same address. No twins allowed here 🙅♀️👯
Fully Qualified Domain Name (FQDN)
A fully qualified domain name is a host name plus a domain name, including the top-level domain. Full name energy 🎀
Internationalized Domain Name (IDN)
Internationalized Domain Names can represent domain names that contain characters outside the ASCII set. See RFC 3490 [9] 🌍✨
Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol (NDP). Plot twist: NDP has other functions besides ND 🤭
Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].
The Neighbor Discovery Protocol is a part of ICMPv6 [6] 💅
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. It only uses the Neighbor Discovery protocol defined in RFCs 2461 and 2462, as updated, and it does so without security. Basically the no-protection squad 🫣
Nonce
An unpredictable random or pseudo-random number, generated by a node and used exactly once. In SEND, nonces make sure a particular advertisement is linked to the solicitation that triggered it. It's the couple's matching bracelets of networking 💍🦋
Router Authorization Certificate
An X.509v3 [7] public key certificate that uses the profile specified in Section 6.3.1 📜👑
SEND node
An IPv6 node that implements this specification. The main characters 🌟
Router Discovery (RD)
Router Discovery lets hosts find out what routers exist on the link and what subnet prefixes are available. It's 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 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). It's the VIP list for routers 👑🫶
3. Neighbor and Router Discovery Overview 🦋
Okay so NDP has a bunch of functions, and a lot of them are crammed onto a few central message types, like the ICMPv6 Neighbor Advertisement message. In this section we review some of these tasks and their effects so we understand how the messages should be treated. This section is not normative. If it conflicts with the original Neighbor Discovery RFCs, the original RFCs, as updated, take precedence 📚💅
The main functions of NDP are as follows:
- The Router Discovery function lets IPv6 hosts discover the local routers on an attached link. Router Discovery is described in Section 6 of RFC 2461 [4]. Its main purpose is finding neighboring routers that are willing to forward packets on behalf of hosts. Subnet prefix discovery works out which destinations are directly on a link. That info matters because it tells you whether a packet should go to a router or straight to the destination node 🗺️✨
- The Redirect function automatically redirects a host to a better first-hop router, or tells hosts that a destination is actually a neighbor (i.e., on-link). Redirect is specified in Section 8 of RFC 2461 [4] 🔀
- Address Autoconfiguration automatically assigns addresses to a host [5]. This lets hosts work without explicit configuration related to IP connectivity. The default autoconfiguration mechanism is stateless. To create IP addresses, hosts use any prefix information they got during Router Discovery, then test the newly formed addresses for uniqueness. A stateful mechanism, DHCPv6 [18], provides additional autoconfiguration features 🏡
- Duplicate Address Detection (DAD) is used for preventing address collisions [5], for instance during Address Autoconfiguration. A node that wants 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. Since the rules forbid using an address until it's been found unique, no higher layer traffic is possible until this procedure is done. So preventing attacks against DAD can help keep communications available for the node in question 🛡️
- The Address Resolution function lets a node on the link resolve another node's IPv6 address to the matching link-layer address. Address Resolution is defined in Section 7.2 of RFC 2461 [4], and hosts and routers both use it. Again, no higher level traffic can go ahead until the sender knows the link layer address of the destination node or the next hop router. Also, the source link layer address on link layer frames is not checked against the information learned through Address Resolution. This makes it easier to add network elements like bridges and proxies, and it eases the stack implementation requirements, since less information has to be passed from layer to layer 🌉
- 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 [4]. NUD is security sensitive, because an attacker could claim that reachability exists when it really doesn't 😱
The NDP messages follow the ICMPv6 message format. All NDP functions are carried out 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, which consists of an ICMPv6 header and ND message-specific data, plus 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 lock down the various NDP functions, a set of new Neighbor Discovery options gets introduced. They protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for using these components in NDP. Let's go 🔐💫
The components of the solution in this document are as follows:
- Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor that the router has a certification path to, 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. Receiving a protected Router Advertisement for which no certification path is available triggers the authorization delegation discovery process 🛤️
- Cryptographically Generated Addresses are used to make sure the sender of a Neighbor Discovery message is the "owner" of the claimed address. Every node generates a public-private key pair before it can claim an address. A new NDP option, the CGA option, carries 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 🔮
- 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 through 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 message being protected.
Note: RSA is mandated because having multiple signature algorithms would break compatibility between implementations, or increase implementation complexity by forcing implementations to support multiple algorithms and a 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 that 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 the one between the RSA-based SEND and Neighbor Discovery without SEND. Information signed with the stronger algorithm has precedence over information signed with RSA, the same way RSA-signed information now takes precedence over unsigned information. Implementations of the current and revised specs would still be compatible 🤝
- In order to prevent replay attacks, two new Neighbor Discovery options, Timestamp and Nonce, are introduced. Since 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 ✨
okay so the CGA option is the thing that lets you verify the sender's CGA 🦋 here's what it looks like:
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 💅
The value is 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 [11].
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 [11]. 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 [11]. 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 [11]. 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 [11].
5.2. RSA Signature Option 🔐
The RSA Signature option lets public key-based signatures get attached to NDP messages. Here's the format 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 💖
The value is 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 [14] 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:
- The 128-bit CGA Message Type tag [11] value for SEND,
0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been generated randomly by the editor of this specification.). - The 128-bit Source Address field from the IP header.
- The 128-bit Destination Address field from the IP header.
- The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
- The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options.
- 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 [13].
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:
- The message is constructed in its entirety, without the RSA Signature option.
- The RSA Signature option is added as the last option in the message.
- The data to be signed is constructed as explained in Section 5.2, under the description of the Digital Signature field.
- 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 ✨
Okay bestie, let's talk about what the receiver does 🫶 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages that come without the RSA Signature option MUST be treated as unsecured, which means they get handled exactly like NDP messages from 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.
Now the spicy part ⚡ Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages that do have an RSA Signature option MUST be checked as follows:
- 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.)
- 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.
- The Digital Signature field MUST have correct encoding and MUST not exceed the length of the RSA Signature option minus the Padding.
- The Digital Signature verification MUST show that the signature has been calculated as specified in the previous section.
- 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 fail any of 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 they 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 [11]. 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
Okay, real talk: the construction and verification of the RSA Signature option is computationally expensive 🥵 In the NDP context, though, 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 to talk to, or Neighbor Unreachability Detection with existing neighbors 🌸.
Routers are required to perform a larger number of operations, especially when router advertisements are sent frequently because of mobility requirements 🚀. Still, the number of required signature operations is on the order of a few dozen per second, and some of them can be precomputed, as explained below. A large number of router solicitations may cause a higher demand for 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 whole point of the Timestamp option is to make sure that unsolicited advertisements and redirects haven't been replayed 🕰️ Here's what the format looks like:
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 the node sent earlier 🌈 Here's the format:
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, and a system may implement that distinction in various ways 🧩. Section 5.3.4.1 defines the processing rules for solicited advertisements. Section 5.3.4.2 defines the processing rules for all other messages.
In addition, the following rules apply in all cases:
- 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) 🙅.
- Messages received with the RSA Signature option but without the Timestamp option MUST be silently discarded.
- Solicitation messages received with the RSA Signature option but without the Nonce option MUST be silently discarded.
- Advertisements sent to a unicast destination address with the RSA Signature option but without a Nonce option SHOULD be processed as unsolicited advertisements.
- 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.
- The receiver MUST be prepared to receive the Timestamp and Nonce options in any order, as per RFC 2461 [4], Section 9 💖.
5.3.4.1. Processing Solicited Advertisements 🎀
okay so bestie, this is the check for solicited ads. the receiver MUST verify that it has recently sent a matching solicitation 👀 and that the advertisement actually has a copy of the Nonce from that solicitation. no faking it 💅
if the message has a Nonce option but the Nonce value isn't one it recognizes, the message MUST be silently discarded 🙈 bye bye 👋
otherwise, if there's no Nonce option at all, it MAY be treated as an unsolicited advertisement and processed the way Section 5.3.4.2 describes 🦋
and if the message gets accepted, the receiver SHOULD store the receive time of the message and the timestamp time in the message, just like Section 5.3.4.2 says ✨
5.3.4.2. 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 for the allowed Delta is TIMESTAMP_DELTA, the fuzz factor is TIMESTAMP_FUZZ, and the clock drift is TIMESTAMP_DRIFT (see Section 10.2) 💖
to make timestamp checking possible, each node SHOULD store this info for each peer:
- The receive time of the last received and accepted SEND message. This is called RDlast.
- 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 variables above. no shortcuts, periodt 💅
receivers SHOULD then check the Timestamp field like this:
- When a message comes from a new peer (one that isn't in the cache), the received timestamp, TSnew, gets checked. The packet is accepted if the timestamp is recent enough compared to the reception time of the packet, RDnew:
-Delta < (RDnew - TSnew) < +DeltaThe RDnew and TSnew values SHOULD be stored in the cache as RDlast and TSlast ✨
- If the timestamp is not within those boundaries, but the message is a Neighbor Solicitation that the receiver should answer, the receiver SHOULD respond to it 💌 Even so, even if it does respond, it MUST NOT create a Neighbor Cache entry. This is lowkey genius because nodes with really different clocks can keep talking by swapping NS/NA pairs 🍓
- When a message comes from a known peer (one that already has a cache entry), the timestamp gets checked against the previous SEND message:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzzIf this inequality does not hold, the receiver SHOULD silently discard the message 🙈 If the inequality holds, the receiver SHOULD process the message 🔥
Moreover, if the inequality holds and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. Otherwise, the receiver MUST NOT update RDlast or TSlast 👑
now the scary part 😭 unsolicited messages can be used in a Denial-of-Service attack to make the receiver verify computationally expensive signatures. so all nodes SHOULD apply a mechanism to stop excessive use of resources when processing such messages. please protect your nodes, it's giving "don't let them drain you" 🚨
6. Authorization Delegation Discovery ✨
okay so NDP lets a node configure itself automatically using info it picks up shortly after connecting to a new link 🦋 it's super easy to set up "rogue" routers on an unsecured link, and it's really hard for a node to tell valid router info from invalid info, because the node needs this info before it can talk to nodes off the link 😭
since the newly connected node can't talk off-link, it can't be the one searching for info to validate the router(s) 🙅♀️ but if it's given a certification path, it can check someone else's search results and conclude that a particular message comes from an authorized source 💅 typically, a router that's already connected beyond the link can talk to off-link nodes when needed and build that certification path 🌈
the Secure Neighbor Discovery Protocol mandates a certificate format and adds two new ICMPv6 messages used between hosts and routers, so the host can learn a certification path with the router's help 🧚
6.1. Authorization Model 💜
to protect Router Discovery, SEND requires that routers be authorized to act as routers 🔐 this authorization gets provisioned in both routers and hosts. routers get certificates from a trust anchor, and hosts are configured with the trust anchor(s) so they can authorize routers. this provisioning is specific to SEND and doesn't assume that certificates already deployed for some other purpose can be reused 🙈
the authorization for routers in SEND is twofold:
- Routers are authorized to act as routers. The router belongs to the set of routers trusted by the trust anchor. Everyone in this set has the same authorization.
- Optionally, routers may also be authorized to advertise a certain set of subnet prefixes. A specific router gets a specific set of subnet prefixes to advertise, and other routers have authorization to advertise other prefixes. Trust anchors may also delegate a certain set of subnet prefixes to someone (like an ISP) who then delegates parts of that set to individual routers 🌸
note that when they talk to hosts, routers usually present a bunch of other parameters too. For instance, routers have their own IP addresses, subnet prefixes have lifetimes, and routers control stateless and stateful address autoconfiguration 🍓 but being a router and the subnet prefixes are the most fundamental things to authorize. The host needs to pick a router to use as its default router, and the advertised prefixes affect the addresses the host uses. The prefixes also make a claim about where the router sits in the network 🗺️
care should be taken if the certificates used in SEND are also used to provide authorization elsewhere, like with routing protocols. The authorization info needs to be appropriate for all applications 👀 SEND certificates may authorize a bigger set of subnet prefixes than the router is allowed to advertise on a given interface. For example, SEND allows the null prefix, which might cause verification or routing problems in other applications 💀 it is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND 🫶
and end hosts don't need their own certified public keys, just like Web clients today don't need end host provisioning with certified keys 💅 public keys for CGA generation don't have to be certified either, because those keys get their ability to authorize operations on the CGA from the tie to the address 🦋
6.2. Deployment Model 🌈
the trust anchor deployment model can be either a globally rooted public key infrastructure, or a more local, decentralized setup like what TLS uses on Web servers today 🌍 the centralized model assumes a global root that can authorize routers and, optionally, the address space they advertise. End hosts get configured with the public keys of that global root. The global root could operate under the Internet Assigned Numbers Authority (IANA), or as a co-operative among Regional Internet Registries (RIRs). But no such global root currently exists 😭
in the decentralized model, end hosts are configured with a collection of trusted public keys. Those keys could come from different places, like a) a public key for the end host's own organization, b) a public key for the end host's home ISP and for ISPs the home ISP has a roaming agreement with, or c) public keys for roaming brokers acting as middlemen for ISPs that don't want to run their own certification authority 🎀
this decentralized model works even when a SEND node is used in networks that have certified routers and in networks that don't. As discussed in Section 8, a SEND node can fall back to a non-SEND router. That makes it possible to start with a local trust anchor even if there isn't a trust anchor for every possible network ✨
6.3. Certificate Format 📜
the certification path of a router ends at a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router 🧚 authorization paths aren't really common practice on the Internet at the time of this writing, so the path MUST consist of standard Public Key Certificates (PKC, in the sense of [8]). The certification path MUST start from the identity of a trust anchor shared by the host and the router. That lets the host anchor trust for the router's public key in the trust anchor 💖 note that there MAY be multiple certificates issued by a single trust anchor 👑
6.3.1. Router Authorization Certificate Profile ✨
okay so Router Authorization Certificates are X.509v3 certificates (as defined in RFC 3280 [7]) and they SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in [10] 💖 the parent certificates in the certification path SHOULD have one or more X.509 IP address extensions too, all the way back up to a trusted party (like the user's ISP) that set up the original IP address block for the router, or that handed out the right to do it 🦋 the certificates for the intermediate delegating authorities SHOULD have X.509 IP address extension(s) for subdelegations. the router's certificate is signed by the delegating authority for the subnet prefixes the router is allowed to advertise. it's giving chain of custody 🔗
the X.509 IP address extension MUST have at least one addressesOrRanges element. that element MUST have an addressPrefix element holding an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. if the entity is allowed to route any prefix, the IPv6 address prefix used is the null prefix, ::/0 🌈 the addressFamily element of the IPAddrBlocks sequence element MUST contain the IPv6 Address Family Identifier (0002), as specified in [10], for IPv6 subnet prefixes. instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. the X.509 IP address extension MAY also contain additional IPv6 subnet prefixes, written as either an addressPrefix or an addressRange 🧚
the first thing a node does when it gets a Router Authorization Certificate is check whether the certificate's signature was generated by the delegating authority. MUST, no skipping 💅 then the client SHOULD check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. if an addressPrefix or addressRange is NOT contained within the delegating authority's subnet prefixes or ranges, the client MAY try taking an intersection of the ranges/subnet prefixes and using that intersection instead. if the resulting intersection is empty, the client MUST NOT accept the certificate. literally a hard no 🙅♀️ if the addressPrefix in the certificate is missing or is the null prefix, ::/0, the parent prefix or range SHOULD be used. and if there is no parent prefix or range, the subnet prefixes the router advertises are said to be unconstrained (see Section 7.3). that means the router is allowed to advertise any prefix 👑
the above checks SHOULD be done for all certificates in the path. if any of the checks fail, the client MUST NOT accept the certificate. the client also has to validate the advertised subnet prefixes, as discussed in Section 7.3 🫶
hosts MUST check the subjectPublicKeyInfo field within the last certificate in the certificate path, so that only RSA public keys are used to try validating router signatures. hosts MUST disregard the certificate for SEND if it does NOT contain an RSA key. no RSA, no entry, periodt 🔥
some public key certificates used with SEND might not have the X.509 IP address extension element right away, so an implementation MAY have facilities that let the prefix and range checks be relaxed. BUT any such configuration options SHOULD be switched off by default 🙈 the system SHOULD have a default configuration that requires rigorous prefix and range checks. rigorous, babe 💜
okay now for the example certification path! isp_group_example.net is the trust anchor, and the host has this certificate:
Certificate 1:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net
Extensions:
IP address delegation extension:
Prefixes: P1, ..., Pk
... possibly other extensions ...
... other certificate parameters ...when the host attaches to a link served by router_x.isp_foo_example.net, it gets the following certification path:
Certificate 2:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes: Q1, ..., Qk
... possibly other extensions ...
... other certificate parameters ...
Certificate 3:
Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes R1, ..., Rk
... possibly other extensions ...
... other certificate parameters ...when all three certificates get processed, the usual RFC 3280 [7] certificate path validation is performed. BUT (and this is a big but 😭) when a node checks certificates received from a router, it usually doesn't have an Internet connection yet, so it isn't possible to do an on-line Certificate Revocation List (CRL) check, if needed. until that check happens, accepting the certificate MUST be treated as provisional, and the node MUST perform the check as soon as it has connected to the Internet through the router.
if the router has been compromised, it could interfere with the CRL check. and if the CRL check gets disrupted or fails, the node SHOULD immediately stop using that router as a default and use another router on the link instead. this part is seriously important, bestie 🚨
in addition, the IP addresses in the delegation extension MUST be a subset of the IP addresses in the delegation extension of the issuer's certificate. so in this example, R1, ..., Rs MUST be a subset of Q1,...,Qr, and Q1,...,Qr MUST be a subset of P1,...,Pk. if the certification path is valid, then router_foo.isp_foo_example.com is authorized to route the prefixes R1,...,Rs. the chain holds together, iykyk 🎀
6.3.2. Suitability of Standard Identity Certificates ✨
so deploying the IP address extension is not super common yet 🥹 which means a network service provider MAY choose to put standard identity certificates on the router, to supply the router's public key for signed Router Advertisements. cute workaround, honestly 🍓
if there's no prefix information further up in the certification path, a host reads a standard identity certificate as allowing unconstrained prefix advertisements.
if the other certificates DO have prefix information, a standard identity certificate is read as allowing those subnet prefixes 🌸
6.4. Certificate Transport 🚚
the Certification Path Solicitation (CPS) message is sent by a host when it wants to request a certification path between a router and one of the host's trust anchors. the Certification Path Advertisement (CPA) message is sent back in reply to the CPS message. these messages are kept separate from the rest of Neighbor and Router Discovery, so the potentially huge certification path info doesn't weigh down the other messages 🧳
the Authorization Delegation Discovery (ADD) process doesn't rule out other ways of finding certification paths, either 👀 for example, during fast movements, mobile nodes might learn info (including the certification paths) about the next router from a previous router, or nodes might be preconfigured with certification paths from roaming partners. the options are giving variety 🦋
where hosts are themselves certified by a trust anchor, these messages MAY also optionally be used between hosts to get the peer's certification path. HOWEVER, the details of that kind of usage are beyond the scope of this specification 🙃
6.4.1. Certification Path Solicitation Message Format ✨
hosts send Certification Path Solicitations to prompt routers into generating Certification Path Advertisements 📣
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IP Fields:
- Source Address
- A link-local unicast address assigned to the sending interface, or to the unspecified address if no address is assigned to the sending interface. 🌿
- Destination Address
- Typically the All-Routers multicast address, the Solicited-Node multicast address, or the address of the host's default router. 📍
- Hop Limit
255🔢
ICMP Fields:
- Type
148💫
- Code
0
- Checksum
- The ICMP checksum [6].
- Identifier
- A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. This randomness does NOT have to be cryptographically hard, because its only purpose is avoiding collisions. 🎲
- Component
- This 16-bit unsigned integer field is set to
65,535if the sender wants to retrieve ALL certificates. Otherwise, it is set to the component identifier for the certificate the receiver wants to retrieve (see Sections 6.4.2 and 6.4.6). 🧩
- This 16-bit unsigned integer field is set to
Valid Options:
- Trust Anchor
- One or more trust anchors that the client is willing to accept. The first (or only) Trust Anchor option MUST contain a DER Encoded X.501 Name; see Section 6.4.3. If there is more than one Trust Anchor option, the options beyond the first MAY contain any type of trust anchor. ⚓
Future versions of this protocol might define new option types. Receivers MUST silently ignore any options they do NOT recognize and keep right on processing the message 🫠 All included options MUST have a length greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets. 💅
that's the whole profile, bestie! 🌈✨
6.4.2. Certification Path Advertisement Message Format 🎀
okay so routers send out Certification Path Advertisement messages whenever they get a Certification Path Solicitation 💌
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IP Fields:
Source Address 🌸
A link-local unicast address on the interface this message is sent from. ngl routers can use multiple addresses, so this one on its own isn't enough to uniquely identify a router 🫶
Destination Address 🦋
Either the Solicited-Node multicast address of the receiver, or the link-scoped All-Nodes multicast address.
Hop Limit 🔥
255
ICMP Fields:
Type 💖
149
Code 💖
0
Checksum ✨
The ICMP checksum [6].
Identifier 🧚
A 16-bit unsigned integer field that acts as an identifier, helping match advertisements to solicitations. The Identifier field MUST be zero for advertisements sent to the All-Nodes multicast address, and MUST NOT be zero for others. iykyk 🙈
All Components 👑
A 16-bit unsigned integer field used to tell the receiver how many certificates are in the entire path.
A single advertisement SHOULD be broken into separately sent components if there is more than one certificate in the path, so we don't get excessive fragmentation at the IP layer. 💅
Individual certificates in a path MAY be stored and used as they're received, before all the certificates have arrived. This makes the protocol slightly more reliable and less prone to Denial-of-Service attacks. 🛡️
Examples of packet lengths of Certification Path Advertisement messages for typical certification paths are listed in Appendix C. 📚
Component 🍓
A 16-bit unsigned integer field used to tell the receiver which certificate is being sent.
The first message in an N-component advertisement has the Component field set to N-1, the second set to N-2, and so on. A zero means there are no more components coming in this advertisement. 🌈
The components SHOULD be sent in an order where the certificate after the trust anchor goes first. Each certificate sent after the first can be verified with the ones sent before it. The sender's own certificate comes last. The trust anchor certificate SHOULD NOT be sent. 🫶
Reserved 🍬
An unused field. It MUST be initialized to zero by the sender, and MUST be ignored by the receiver. 💜
Valid Options:
Certificate 📜
One certificate is provided in each Certificate option to help establish part of a certification path to a trust anchor.
The certificate of the trust anchor itself SHOULD NOT be sent. 🙅♀️
Trust Anchor ⭐
Zero or more Trust Anchor options may be included to help receivers decide which advertisements are useful for them. If present, these options MUST appear in the first component of a multi-component advertisement. 💖
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length that is greater than zero. ✨
The ICMP length (derived from the IP length) MUST be 8 or more octets. 🎀
6.4.3. Trust Anchor Option 🦋
okay here's how the Trust Anchor option is laid out 👀
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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖
15
Length 🌸
The length of the option, including the Type, Length, Name Type, Pad Length, and Name fields, in units of 8 octets.
Name Type 🧚
The type of the name in the Name field. This specification defines two legal values for this field:
1 DER Encoded X.501 Name
2 FQDNPad Length 🫧
The number of padding octets beyond the end of the Name field but still within the length given by the Length field. Padding octets MUST be set to zero by senders, and MUST be ignored by receivers. 🍓
Name 🔥
When Name Type is set to 1, the Name field holds a DER encoded X.501 Name identifying the trust anchor. The value is encoded as defined in [12] and [7].
When Name Type is set to 2, the Name field holds a Fully Qualified Domain Name of the trust anchor, for example "trustanchor.example.com". The name is stored as a string in the DNS wire format, as specified in RFC 1034 [1]. On top of that, the restrictions discussed in RFC 3280 [7], Section 4.2.1.7 apply. 🧐
In the FQDN case, the Name field is an "IDN-unaware domain name slot", as defined in [9]. That means it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see [9] for more information. 🌍
All systems MUST support the DER Encoded X.501 Name. Implementations MAY support the FQDN name type. 👑
Padding 🎀
A variable-length field that makes the option length a multiple of 8. It starts right after the previous field ends and runs to the end of the option, as specified by the Length field. 🫶
6.4.4. Certificate Option 📜
here's the layout for the certificate option 🥰
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 | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖
16
Length 🌸
The length of the option, including the Type, Length, Cert Type, Pad Length, and Certificate fields, in units of 8 octets.
Cert Type 🧚
The type of the certificate in the Certificate field. This specification defines only one legal value for this field:
1 X.509v3 Certificate, as specified belowReserved 🍬
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. 💜
Certificate 📜
When Cert Type is set to 1, the Certificate field holds an X.509v3 certificate [7], as described in Section 6.3.1. ✨
Padding 🎀
A variable-length field that makes the option length a multiple of 8. It starts after the ASN.1 encoding of the previous field [7, 15] ends, and runs to the end of the option, as specified by the Length field. 🫧
6.4.5. Processing Rules for Routers 👑
okay routers, this is your checklist, bestie 📋
A router MUST silently discard any received Certification Path Solicitation messages that do not conform to the message format defined in Section 6.4.1. The contents of the Reserved field and of any unrecognized options MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options, while backward-incompatible changes may use different Code values. The contents of any defined options that aren't specified to be used with Router Solicitation messages MUST be ignored, and the packet gets processed in the normal manner. The only defined option that may appear is the Trust Anchor option. A solicitation that passes the validity checks is called a "valid solicitation". 🚫
Routers SHOULD send advertisements in response to valid solicitations received on an advertising interface. If the source address in the solicitation was the unspecified address, the router MUST send the response to the link-scoped All-Nodes multicast address. If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address, except when under load, as specified below. Routers SHOULD NOT send Certification Path Advertisements more than MAX_CPA_RATE times within a second. When there are more solicitations, the router SHOULD send the response to the All-Nodes multicast address, regardless of the source address that appeared in the solicitation. 🦋
In an advertisement, the router SHOULD include suitable Certificate options, so a certification path can be established to the solicited trust anchor (or a part of it, if the Component field in the solicitation is not equal to 65,535). Note also that a single advertisement is broken into separately sent components and ordered in a particular way (see Section 6.4.2) when there is more than one certificate in the path. 🔗
The anchor is identified by the Trust Anchor option. If the Trust Anchor option is represented as a DER Encoded X.501 Name, then the Name has to be equal to the Subject field in the anchor's certificate. If the Trust Anchor option is represented as an FQDN, the FQDN has to be equal to an FQDN in the subjectAltName field of the anchor's certificate. The router SHOULD include the Trust Anchor option(s) in the advertisement for which the certification path was found. 🌈
If the router can't find a path to the requested anchor, it SHOULD send an advertisement without any certificates. In this case, the router SHOULD include the Trust Anchor options that were solicited. 🥺
6.4.6. Processing Rules for Hosts 💖
okay so hosts have their own rulebook for Certification Path Advertisement messages 🎀 first things first, a host MUST silently discard any received Certification Path Advertisement messages that don't match the message format in Section 6.4.2 🙅♀️ no drama, just gone ✨ the contents of the Reserved field and of any unrecognized options MUST be ignored 🫶 future backward-compatible updates MAY specify what the Reserved field holds or add new options, but backward-incompatible changes MUST use different Code values 🧚 any defined options that aren't meant for Certification Path Advertisement messages MUST be ignored too, and the packet gets processed in the normal manner 💅 the only defined options that may appear are the Certificate and Trust Anchor options 💜 an advertisement that passes the validity checks is called a "valid advertisement" 🦋
hosts SHOULD store certification paths they get from Certification Path Discovery messages if those paths start from an anchor the host trusts 🌸 but the paths MUST be verified, as defined in Section 6.3, before they get stored 🔥 and routers send the certificates one by one, starting from the trust anchor end of the path 🌈
Note: Except to allow for message loss and reordering for temporary purposes, hosts might not store certificates received in a Certification Path Advertisement unless they contain a certificate that can be immediately verified either to the trust anchor or to a certificate that has been verified earlier. This measure is intended to prevent Denial-of-Service attacks, whereby an attacker floods a host with certificates that the host cannot validate and overwhelms memory for certificate storage. 🙈💀
caching this info is lowkey a performance win 📈 like, caching this information, and the implied verification results between network attachments for use over multiple attachments to the network, can help improve performance ✨ but periodic certificate revocation checks are still needed, even with cached results, to make sure that the certificates are still valid 🫶
the host SHOULD retrieve a certification path when a Router Advertisement has been received with a public key that is not available from a certificate in the host's cache, or when there is no certification path to one of the host's trust anchors 🔥 in those situations the host MAY send a Certification Path Solicitation message to retrieve the path 🧚 if there is no response within CPS_RETRY seconds, the message should be retried 🎀 the wait interval for each subsequent retransmission MUST exponentially increase, doubling each time 📈 if there is no response after CPS_RETRY_MAX seconds, the host abandons the certification path retrieval process 🙅♀️ if the host receives only a part of a certification path within CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in addition transmit a Certification Path Solicitation message with the Component field set to a value not equal to 65,535 🌸 this message can be retransmitted by using the same process as for the initial message 💅 if there are multiple missing certificates, additional CPS messages can be sent after getting a response to the first one 🦋 however, the complete retrieval process may last at most CPS_RETRY_MAX seconds ⏳
Certification Path Solicitations SHOULD NOT be sent if the host has a currently valid certification path from a reachable router to a trust anchor 🚫✨
when soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it hasn't selected a default router yet, or to the default router's IP address, if a default router has already been selected 🎯
if two hosts want to establish trust with the CPS and CPA messages, the CPS message SHOULD be sent to the Solicited-Node multicast address of the receiver 🫶 the advertisements SHOULD be sent as specified above for routers 💜 however, the exact details are outside the scope of this specification 🤷♀️
when processing possible advertisements sent as responses to a solicitation, the host MAY prefer to process those advertisements with the same Identifier field value as that of the solicitation first 🧠 this makes Denial-of-Service attacks against the mechanism harder (see Section 9.3) 🛡️👑
6.5. Configuration 🎀
end hosts get configured with a set of trust anchors so they can protect Router Discovery 🫶 a trust anchor configuration has these items:
- A public key signature algorithm and associated public key, which may optionally include parameters.
- A name as described in Section 6.4.3.
- An optional public key identifier.
- An optional list of address ranges for which the trust anchor is authorized.
if the host has been configured to use SEND, it SHOULD possess the above information for at least one trust anchor 🔐
routers get configured with a collection of certification paths and a collection of certificates containing certified keys, all the way down to the key and certificate for the router itself 🌈 certified keys are required for routers so that a certification path can be established between the router's certificate and the public key of a trust anchor 💖
if the router has been configured to use SEND, it should be configured with its own key pair and certificate, and with at least one certification path 🧚
7. Addressing ✨
7.1. CGAs 🦋
by default, a SEND-enabled node SHOULD use only CGAs for its own addresses 💜 other types of addresses MAY be used in testing, in diagnostics, or for other purposes 🧪 however, this document does not describe how to choose between different types of addresses for different communications 🤷♀️ a dynamic selection can be provided by an API, such as the one defined in [21] 🔥
7.2. Redirect Addresses 🌸
if the Target Address and Destination Address fields in the ICMP Redirect message are equal, then this message is used to inform hosts that a destination is, in fact, a neighbor 🫶 in this case, the receiver MUST verify that the given address falls within the range defined by the router's certificate 🛡️ Redirect messages failing this check MUST be treated as unsecured, as described in Section 7.3 🙅♀️
note that base NDP rules prevent a host from accepting a Redirect message from a router that the host is not using to reach the destination mentioned in the redirect 💅 this stops an attacker from tricking a node into redirecting traffic when the attacker is not the default router 👑
7.3. Advertised Subnet Prefixes 🎀
the router's certificate defines the address range(s) that it is allowed to advertise securely 🔐 a router MAY, however, advertise a combination of certified and uncertified subnet prefixes 🌈 uncertified subnet prefixes are treated as unsecured (i.e., processed in the same way as unsecured router advertisements sent by non-SEND routers) 🙈 the processing of unsecured messages is specified in Section 8 📜 note that SEND nodes that don't attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information 🗑️
certified subnet prefixes fall into the following two categories 💖
Constrained
If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension 🎯 these routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof 🫶
Unconstrained
Network operators that don't want to constrain routers this way should configure routers with certificates containing either the null prefix or no prefix extension at all 🦋
upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension 🔍 options failing this check are treated as containing uncertified subnet prefixes 🙅♀️
nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration ✨ if none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available 🧚 if the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified subnet prefixes, and SHOULD NOT use the address if the prefix is not certified 🚫💀
7.4. Limitations 🙈
this specification does not address the protection of NDP packets for nodes configured with a static address (e.g., PREFIX::1) 😭 future certification path-based authorization specifications are needed for these nodes 🔮 this specification also does not apply to addresses generated by the IPv6 stateless address autoconfiguration from a fixed interface identifiers (such as EUI-64) 🌸
it is outside the scope of this specification to describe the use of trust anchor authorization between nodes with dynamically changing addresses 🫠 these addresses may be the result of stateful or stateless address autoconfiguration, or may have resulted from the use of RFC 3041 [17] addresses 🌈 if the CGA method is not used, nodes are required to exchange certification paths that terminate in a certificate authorizing a node to use an IP address having a particular interface identifier 🔑 this specification does not specify the format of these certificates, as there are currently only a few cases where they are provided by the link layer, and it is up to the link layer to provide certification for the interface identifier 🧠 this may be the subject of a future specification 👀 it is also outside the scope of this specification to describe how stateful address autoconfiguration works with the CGA method 🙃
the Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification 🎀
8. Transition Issues ✨
okay so, while we're moving over to secured links (or just because an operator wants it that way 🧚), a link might end up with a mix of nodes, some accepting secured messages and some accepting unsecured ones. That's totally allowed, and honestly it's giving practical. Nodes that support SEND SHOULD support using secured and unsecured NDP messages at the same time 🫶
In a mixed setup, SEND nodes receive both kinds of messages but give priority to the secured ones 💅 Here, "secured" means a message that has a valid signature option (as specified above), and "unsecured" means a message with no signature option at all.
A SEND node SHOULD have a configuration option that makes it ignore every unsecured Neighbor Solicitation and Advertisement, Router Solicitation and Advertisement, and Redirect message. This is how you enforce SEND-only networks, bestie 🔒 The default for this option SHOULD be that both secured and unsecured messages are allowed.
A SEND node MAY also have a configuration option that turns SEND off completely, even for the messages it sends itself 🙈 This option SHOULD be switched off by default, which means SEND is used. Plain non-SEND NDP nodes will obviously only send unsecured messages. Per RFC 2461 [4], those nodes ignore the unknown options and treat secured messages exactly the same way they treat unsecured ones 🤷♀️ Secured and unsecured nodes share the same network resources, like subnet prefixes and address spaces, so they're all in the same friend group 🌸
SEND nodes that use SEND at least in their own messages behave in a mixed environment the way explained below ✨
SEND follows the rules of the base NDP protocol, with the following exceptions, so listen up:
- All solicitations sent by a SEND node MUST be secured.
- Unsolicited advertisements sent by a SEND node MUST be secured.
- A SEND node MUST send a secured advertisement in response to a secured solicitation. Advertisements sent in response to an unsecured solicitation MUST be secured as well, but MUST NOT contain the
Nonceoption 🎀 - A SEND node that uses the
CGAauthorization method to protect Neighbor Solicitations SHOULD perform Duplicate Address Detection like this 💖 If Duplicate Address Detection shows the tentative address is already in use, the node generates a new tentativeCGA. If after three consecutive attempts no non-unique address is generated, it logs a system error and gives up on generating an address for that interface 💀
When it's doing Duplicate Address Detection for the first tentative address, the node accepts both secured and unsecured Neighbor Advertisements and Solicitations that come back in response to the Neighbor Solicitations. When it's doing it for the second or third tentative address, it ignores the unsecured ones 👑 (The security implications of this are discussed in Section 9.2.3 and in [11]. Go read that, it's juicy 🍓)
- The node MAY have a configuration option that makes it ignore unsecured advertisements, even while doing Duplicate Address Detection for the first tentative address. This option SHOULD be disabled by default. It's a recovery mechanism for when attacks against the first address start getting common 🛡️
- Neighbor Cache, Prefix List, and Default Router list entries MUST have a
secured/unsecuredflag that shows whether the message that created or last updated the entry was secured or unsecured. Received unsecured messages MUST NOT change existing secured entries in the Neighbor Cache, Prefix List, or Default Router List. Received secured messages MUST update the matching entries, and those entries MUST be flagged as secured 🔐 - Neighbor Solicitations for Neighbor Unreachability Detection (NUD) MUST be sent to that neighbor's solicited-nodes multicast address if the entry is not secured with SEND.
Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT move the neighbor cache state from STALE to REACHABLE on a SEND node if that entry has never been REACHABLE before. This makes sure that if an entry spoofing a valid SEND host gets created by a non-SEND attacker without being solicited, NUD will be done with the entry within five seconds of use for data transmission ⏱️
So, in mixed mode, attackers can only take over a SEND node's Neighbor Cache entry for a longer time if (a) the SEND node wasn't communicating with the victim node (so there's no secure entry for it), and (b) the SEND node isn't currently on the link (or can't respond). Not gonna lie, that's a pretty specific situation 😭
- The conceptual sending algorithm gets modified so that an unsecured router is only selected if there's no reachable SEND router for the prefix. In other words, the default router selection algorithm favors reachable SEND routers over reachable non-SEND ones 👑
- A node MAY adopt a router that sends unsecured messages, or a router for which secured messages have been received but full security checks haven't been completed yet, while security checking is still happening. The security checks in this case include certification path solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt a router that sends unsecured messages if a router known to be secured becomes unreachable. But because the unreachability might be the result of an attack, it SHOULD try to find a router known to be secured as soon as possible 🏃♀️
Note that although this can speed up attaching to a new network, accepting a router that sends unsecured messages, or one whose security checks aren't complete, opens the node up to possible attacks. Nodes that choose to accept such routers do so at their own risk ⚠️ In any case, the node SHOULD prefer a router known to be secure as soon as one is available with completed security checks 🌈
9. Security Considerations
9.1. Threats to the Local Link Not Covered by SEND
okay this section is serious, bestie, so pay attention 🥺
SEND does not provide confidentiality for NDP communications. Not even a little 🙈
SEND does not make up for an unsecured link layer. For example, there's no guarantee that payload packets actually come from the same peer that NDP was run against 😬
There may not be cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could let nodes spoof the link layer address of other nodes. An attacker could disrupt IP service by sending out a Neighbor Advertisement on an unsecured link layer, with the link layer source address in the frame set to the source address of a victim, a valid CGA address and a valid signature that belong to the attacker, and a Target Link-layer Address extension that corresponds to the victim. The attacker could then make a traffic stream bombard the victim in a DoS attack 💀 This can't be prevented just by securing the link layer.
Even on a secured link layer, SEND doesn't require that the addresses on the link layer and the Neighbor Advertisements match up. However, performing these checks is RECOMMENDED if the link layer technology permits it 🔍
Before participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the link-scoped All-Nodes Multicast Group and the Solicited-Node Multicast Group for the address they're claiming as their own. See RFC 2461 [4]. Subscribing to a multicast group requires that the nodes use MLD [16]. MLD has no provision for security at all 😭 An attacker could send an MLD Done message to unsubscribe a victim from the Solicited-Node Multicast address. However, the victim should be able to detect this attack, because the router sends a Multicast-Address-Specific Query to find out whether any listeners are still on the address. At that point the victim can respond so it doesn't get dropped from the group 🫶 This technique works as long as the router on the link hasn't been compromised. Other attacks using MLD are possible, but they mostly lead to extra traffic that isn't necessarily overwhelming 📉
9.2. How SEND Counters Threats to NDP
The SEND protocol is designed to counter the threats to NDP outlined in [22]. The following subsections go through the SEND protocol against those threats, to show which parts of the protocol counter each threat 🧩
9.2.1. Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [22]. The threat is that a spoofed message may cause a false entry in a node's Neighbor Cache. There are two cases:
- Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router that receives a Router Solicitation with a
Target Link-Layer Addressextension, and an IPv6 source address that isn't the unspecified address, inserts an entry for that IPv6 address into its Neighbor Cache. Also, a node performing Duplicate Address Detection (DAD) that receives a Neighbor Solicitation for the same address treats it as a collision and stops soliciting for that 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 the Neighbor Cache binding is correct ✅ If a SEND node has to send a Router Solicitation with the unspecified address, the router won't update its Neighbor Cache, as per base NDP.
- Entries made as a result of a Neighbor Advertisement message. SEND counters this threat by requiring that the
RSA SignatureandCGAoptions be present in these advertisements 🔐
Also see Section 9.2.5, below, for discussion about replay protection and timestamps ⏰
9.2.2. Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [22]. SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes includes an RSA Signature option and proof of authorization to use the interface identifier in the address being probed. If these prerequisites aren't met, the node performing NUD throws the responses away 🗑️
9.2.3. Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [22]. 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 aren't 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 by attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node. The probability and effects of such an address collision are discussed in [11] 🦋
9.2.4. Router Solicitation and Advertisement Attacks 🚦
okay so these attacks are covered in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of [22] 🙈. SEND fights back by making Router Advertisements carry an RSA Signature option, with the signature made using the public key of a node that can prove it's actually allowed to route the subnet prefixes in any Prefix Information Options. The router proves this by showing a certificate that has the specific prefix in it, or an indication that it can route any prefix. A Router Advertisement without these protections gets discarded 🗑️ no exceptions, bestie.
SEND does not protect against brute force attacks on the router, like DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [22]. 💀 that's a real limit, so keep it in mind.
9.2.5. Replay Attacks 🔁
This attack is described in Section 4.3.1 of [22]. SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by putting a Nonce option in the solicitation and requiring that the advertisement include a matching option. Together with the signatures, that makes a challenge-response protocol ✨.
SEND protects against attacks from unsolicited messages, like 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 timestamp 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, as explained in Section 5.3.1, this may affect some nodes. 😬
- Attacks against time synchronization protocols such as NTP [23] 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. 🕰️
9.2.6. Neighbor Discovery DoS Attack 🌊
This attack is described in Section 4.3.2 of [22]. In it, the attacker bombards the router with packets for fictitious addresses on the link, which keeps the router busy doing Neighbor Solicitations for addresses that don't 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. 🧠
9.3. Attacks against SEND Itself 🛡️
The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [11].
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 an excessive use of resources, this can still render SEND non-operational. 😱
When CGA protection is used, SEND deals with the DoS attacks by using the verification process described in Section 5.2.2. In this process, 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 amount 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. 💅
10. Protocol Values 🎀
10.1. Constants 💖
Host constants:
CPS_RETRY 1 second
CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 secondsRouter constants:
MAX_CPA_RATE 10 times per second10.2. Variables ✨
TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)11. IANA Considerations 📋
This document defines two new ICMP message types, used in Authorization Delegation Discovery. These messages must be assigned ICMPv6 type numbers from the informational message range:
- The Certification Path Solicitation message (148), described in Section 6.4.1.
- The Certification Path Advertisement message (149), described in Section 6.4.2.
This document defines six new Neighbor Discovery Protocol [4] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery Protocol messages:
- The CGA option (11), described in Section 5.1.
- The RSA Signature option (12), described in Section 5.2.
- The Timestamp option (13), described in Section 5.3.1.
- The Nonce option (14), described in Section 5.3.2.
- The Trust Anchor option (15), described in Section 6.4.3.
- The Certificate option (16), described in Section 6.4.4.
This document defines a new 128-bit value under the CGA Message Type [11] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are:
1 DER Encoded X.501 Name
2 FQDNAnother new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are:
1 X.509v3 Certificate12. References 📚
12.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[12] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 1, November 2002.
[14] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
12.2. Informative References
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work in Progress, March 2003.
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", Work in Progress, June 2002.
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Address Selection", Work in Progress, October 2003.
[22] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth Annual Computer Security Conference Proceedings, December 1990.
Appendix A. Contributors and Acknowledgments 🫶
Tuomas Aura contributed the transition mechanism specification in Section 8. Jonathan Trostle contributed the certification path example in Section 6.3.1. Bill Sommerfeld was involved with much of the early design work.
The authors would also like to thank Tuomas Aura, Bill Sommerfeld, Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for interesting discussions in this problem space and for feedback regarding the SEND protocol. 💜
Appendix B. Cache Management 💅
okay bestie, this appendix is the cache-management corner 🎀 It lays out an algorithm that lets a node stay partially functional even when someone is flooding its cache (a cache-filling DoS attack) 😭 It's informational, so it's not a strict must-follow spec, but real implementations SHOULD use different algorithms so we don't all end up with the same mono-cultural code 🌈 Diversity is the whole point.
There are at least two distinct cache-related attack scenarios:
- There are a number of nodes on a link, and someone launches a cache filling attack. The goal here is to make sure that the nodes can continue to communicate even if the attack is going on. 🫶
- There is already a cache-filling attack going on, and a new node arrives to the link. The goal here is to make it possible for the new node to become attached to the network, in spite of the attack. 🦋
As the intent is to limit the damage to existing, valid cache entries, it is clearly better to be very selective about throwing out entries ✨ Reducing the timestamp Delta value is very discriminatory against nodes with a large clock difference, and an attacker can reduce its clock difference arbitrarily, so tossing out old entries just because their clock difference is large seems like a bad approach 🙈
It's reasonable to have separate cache spaces for new and old entries, where, when under attack, the newly cached entries would be more readily dropped. You could track traffic and only allow reasonable new entries that receive genuine traffic to be converted into old cache entries. Although such a scheme can make attacks harder, it will not fully prevent them. For example, an attacker could send a little traffic (i.e., a ping or TCP syn) after each NS to trick the victim into promoting its cache entry to the old cache. 💀 To counter this, the node can be more intelligent about keeping its cache entries than it would be just by having a black/white old/new boundary. Main character energy for the cache 👑
Distinguishing the Sec parameter from the CGA Parameters when forcing cache entries out, by keeping entries with larger Sec parameters preferentially, also appears to be a possible approach, as CGAs with higher Sec parameters are harder to spoof. 🔥
Appendix C. Message Size When Carrying Certificates 🌸
In one example scenario using SEND, an Authorization Delegation Discovery test run was made with a certification path length of 4. Three certificates are sent by using Certification Path Advertisement messages, as the trust anchor's certificate is already known by both parties. With a key length of 1024 bits, the certificate lengths in the test run ranged from 864 to 888 bytes. The variation is due to the differences in the certificate issuer names and address prefix extensions. The different certificates had between 1 and 4 address prefix extensions. 🧚
The three Certification Path Advertisement messages ranged from 1050 to 1,066 bytes on an Ethernet link layer. The certificate itself accounts for the bulk of the packet. The rest is the trust anchor option, ICMP header, IPv6 header, and link layer header. ✨
Authors' Addresses 🎀
Here are the people who wrote this one, bestie 🫶
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@ericsson.com
James Kempf
DoCoMo Communications Labs USA
181 Metro Drive
San Jose, CA 94043
USA
EMail: kempf@docomolabs-usa.com
Brian Zill
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
EMail: bzill@microsoft.com
Pekka Nikander
Ericsson
Jorvas 02420
Finland
EMail: Pekka.Nikander@nomadiclab.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Intellectual Property 🦋
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc3971 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms