Network Working Group J. Arkko Internet-Draft Ericsson Expires: December 4, 2003 J. Kempf DoCoMo Communications Labs USA B. Sommerfeld Sun Microsystems B. Zill Microsoft P. Nikander Ericsson June 5, 2003 SEcure Neighbor Discovery (SEND) draft-ietf-send-ipsec-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 4, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to Arkko, et al. Expires December 4, 2003 [Page 1] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 various attacks. This document specifies an extension to IPsec for securing ND. Contrary to the original ND specifications that also called for use of IPsec, this extension does not require the creation of a large number of manually configured security associations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Neighbor and Router Discovery Overview . . . . . . . . . . 7 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 10 5. Modifications to Neighbor Discovery . . . . . . . . . . . 12 5.1 Unspecified Source Address . . . . . . . . . . . . . 12 5.2 Secure-Solicited-Node Multicast Address . . . . . . 12 5.3 Nonce Option . . . . . . . . . . . . . . . . . . . . 13 5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 14 6. Authorization Delegation Discovery . . . . . . . . . . . . 15 6.1 Delegation Chain Solicitation Message Format . . . . 15 6.2 Delegation Chain Advertisement Message Format . . . 17 6.3 Trusted Root Option . . . . . . . . . . . . . . . . 19 6.4 Certificate Option . . . . . . . . . . . . . . . . . 20 6.5 Router Authorization Certificate Format . . . . . . 21 6.5.1 Field Values . . . . . . . . . . . . . . . . .22 6.6 Processing Rules for Routers . . . . . . . . . . . . 23 6.7 Processing Rules for Hosts . . . . . . . . . . . . . 24 7. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . 27 7.1 The AH_RSA_Sig Transform . . . . . . . . . . . . . . 27 7.1.1 Reserved SPI Number . . . . . . . . . . . . .27 7.1.2 Authentication Data Format . . . . . . . . . .27 7.1.3 AH_RSA_Sig Security Associations . . . . . . .29 7.1.4 Replay Protection . . . . . . . . . . . . . .30 7.1.5 Processing Rules for Senders . . . . . . . . .31 7.1.6 Processing Rules for Receivers . . . . . . . .32 7.2 Other IPsec Extensions . . . . . . . . . . . . . . . 33 7.2.1 Destination Agnostic Security Associations . .33 7.2.2 ICMP Type Specific Selectors . . . . . . . . .33 8. Securing Neighbor Discovery with SEND . . . . . . . . . . 34 8.1 Neighbor Solicitation Messages . . . . . . . . . . . 34 8.1.1 Sending Secure Neighbor Solicitations . . . .34 8.1.2 Receiving Secure Neighbor Solicitations . . .34 8.2 Neighbor Advertisement Messages . . . . . . . . . . 35 8.2.1 Sending Secure Neighbor Advertisements . . . .35 8.2.2 Receiving Secure Neighbor Advertisements . . .35 8.3 Other Requirements . . . . . . . . . . . . . . . . . 36 8.4 Configuration . . . . . . . . . . . . . . . . . . . 36 9. Securing Router Discovery with SEND . . . . . . . . . . . 39 9.1 Router Solicitation Messages . . . . . . . . . . . . 39 9.1.1 Sending Secure Router Solicitations . . . . .39 Arkko, et al. Expires December 4, 2003 [Page 2] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 9.1.2 Receiving Secure Router Solicitations . . . .39 9.2 Router Advertisement Messages . . . . . . . . . . . 39 9.2.1 Sending Secure Router Advertisements . . . . .40 9.2.2 Receiving Secure Router Advertisements . . . .40 9.3 Redirect Messages . . . . . . . . . . . . . . . . . 40 9.3.1 Sending Redirects . . . . . . . . . . . . . .40 9.3.2 Receiving Redirects . . . . . . . . . . . . .41 9.4 Other Requirements . . . . . . . . . . . . . . . . . 41 9.5 Configuration . . . . . . . . . . . . . . . . . . . 42 10. Co-Existence of SEND and ND . . . . . . . . . . . . . . . 44 10.1 Behavior Rules . . . . . . . . . . . . . . . . . . . 44 10.2 Configuration . . . . . . . . . . . . . . . . . . . 46 11. Performance Considerations . . . . . . . . . . . . . . . . 49 12. Implementation Considerations . . . . . . . . . . . . . . 50 13. Security Considerations . . . . . . . . . . . . . . . . . 51 13.1 Threats to the Local Link Not Covered by SEND . . . 51 13.2 How SEND Counters Threats to Neighbor Discovery . . 51 13.2.1 Neighbor Solicitation/Advertisement Spoofing .51 13.2.2 Neighbor Unreachability Detection Failure . .53 13.2.3 Duplicate Address Detection DoS Attack . . . .53 13.2.4 Router Solicitation and Advertisement Attacks 53 13.2.5 Replay Attacks . . . . . . . . . . . . . . . .53 13.2.6 Neighbor Discovery DoS Attack . . . . . . . .54 13.3 Attacks against SEND Itself . . . . . . . . . . . . 54 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 56 Normative References . . . . . . . . . . . . . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 60 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 62 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 63 C. IPR Considerations . . . . . . . . . . . . . . . . . . . . 64 Intellectual Property and Copyright Statements . . . . . . 65 Arkko, et al. Expires December 4, 2003 [Page 3] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 1. Introduction IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6]. Nodes on the same link use the ND protocol to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. The ND protocol is used both by hosts and routers. Its functions include Router Discovery (RD), Address Auto- configuration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection. RFC 2461 called for the use of IPsec for protecting the ND messages. However, it turns out that in this particular application IPsec can only be used with a manual configuration of security associations due to chicken-and-egg problems in using IKE [23, 21] before ND is operational. Furthermore, the number of such manually configured security associations needed for protecting ND is impractically large [24]. Finally, RFC 2461 did not specify detailed instructions for using IPsec to secure ND. Section 4 describes our overall approach to securing ND. This approach involves the use of IPsec AH [3] to secure all advertisements relating to Neighbor and Router Discovery. A new transform for AH allows public keys to be used. Routers are certified by a trusted root, and a zero-configuration mechanism for showing address ownership. The formats, procedures, and cryptographic mechanisms for this zero-configuration mechanism are described in a related specification [27]. Section 6 describes the mechanism for distributing certificate chains to establish authorization delegation chain to a common trusted root. Section 7 describes the necessary modifications to IPsec. Section 8 and Section 9 show how to apply these components to securing Neighbor and Router Discovery. A few small changes are required in the Neighbor Discovery protocol and these are discussed in Section 5. Finally, Section 10 discusses the co-existence of secure and non-secure Neighbor Discovery on the same link, Section 11 discusses performance considerations, Section 12 discusses the implementation considerations related to the IPsec extensions, and Section 13 discusses security considerations for SEND. Arkko, et al. Expires December 4, 2003 [Page 4] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 2. Terms Authorization Certificate (AC) The signer of an authorization certificate has authorized the entity designated in the certificate for a specific task or service. Authorization Delegation Discovery (ADD) This is a process through which SEND nodes can acquire a certificate chain from a peer node to a trusted root. Cryptographically Generated Addresses (CGAs) A technique [27, 30] where the address of the node is cryptographically generated from the public key of the node and some other parameters using a one-way hash function. Duplicate Address Detection (DAD) This mechanism defined in RFC 2462 [7] assures that two IPv6 nodes on the same link are not using the same addresses. Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control signaling protocol. Neighbor Discovery is a part of ICMPv6. Neighbor Discovery (ND) The IPv6 Neighbor Discovery protocol [6]. Neighbor Unreachability Detection (NUD) This mechanism defined in RFC 2461 [6] is used for tracking the reachability of neighbors. Nonce Nonces are random numbers generated by a node. In SEND, they are used to ensure that a particular advertisement is linked to the solicitation that triggered it. Security association A security association is a simplex "connection" that affords security services to the traffic carried by it. Security services Arkko, et al. Expires December 4, 2003 [Page 5] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 are afforded to a security association by the use of AH, or ESP, but not both. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier [2]. Security association database A nominal database containing parameters that are associated with each (active) security association. For inbound and outbound IPsec processing, these databases are separate. Security Parameters Index (SPI) An arbitrary 32-bit value. Together with the destination IP address and security protocol (ESP or AH) identifier, the SPI uniquely identifies the Security Association. Values from 1 to 255 are reserved. Special SPI A Security Parameters Index from the reserved range 1 to 255. Security policy The security policy determines the security services afforded to an IPsec protected packet and the treatment of the packet in the network. Security policy database A nominal database containing a list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. Separate entries for inbound and outbound traffic is required [2]. Arkko, et al. Expires December 4, 2003 [Page 6] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 3. Neighbor and Router Discovery Overview IPv6 Neighbor and Router Discovery have several functions. Many of these functions are overloaded on a few central message types such as the ICMPv6 Neighbor Discovery message. In this section we explain some of these tasks and their effects in order to understand better how the messages should be treated. Where this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs take precedence. In IPv6, many of the tasks traditionally done at lower layers such as ARP have been moved to the IP layer. As a consequence, unified mechanisms can be applied across link layers, security mechanisms or other extensions can be adopted more easily, and a clear separation of the roles between the IP and link layer can be achieved. The main functions of IPv6 Neighbor Discovery are as follows: o Neighbor Unreachability Detection (NUD) is used for tracking the reachability of neighbors, both hosts and routers. NUD is defined in Section 7.3 of RFC 2461 [6]. NUD is security-sensitive, because no higher level traffic can proceed if this procedure flushes out neighbor cache entries after (perhaps incorrectly) determining that the peer is not reachable. o Duplicate Address Detection (DAD) is used for preventing address collisions [7]. A node that intends to assign a new address to one of its interfaces runs first the DAD procedure to verify that other nodes are not using the same address. Since the outlined rules forbid the use of an address until it has been found unique, no higher layer traffic is possible until this procedure has completed. Thus, preventing attacks against DAD can help ensure the availability of communications for the node in question. o Address Resolution is similar to IPv4 ARP [20]. The Address Resolution function resolves a node's IPv6 address to the corresponding link-layer address for nodes on the link. Address Resolution is defined in Section 7.2 of RFC 2461 [6] and it is used for hosts and routers alike. Again, no higher level traffic can proceed until the sender knows the hardware address of the destination node or the next hop router. Note that like its predecessor in ARP, IPv6 Neighbor Discovery does not check the source link layer address against the information learned through Address Resolution. This allows for an easier addition of network elements such as bridges and proxies, and eases the stack implementation requirements as less information needs to be passed from layer to layer. Arkko, et al. Expires December 4, 2003 [Page 7] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 o Address Autoconfiguration is used for automatically assigning addresses to a host [7]. This allows hosts to operate without configuration related to IP connectivity. The Address Autoconfiguration mechanism is stateless, where the hosts use prefix information delivered to them during Router Discovery to create addresses, and then test these addresses for uniqueness using the DAD procedure. A stateful mechanism, DHCPv6 [25], provides additional Autoconfiguration features. Router and Prefix Discovery and Duplicate Address Detection have an effect to the Address Autoconfiguration tasks. o The Redirect function is used for automatically redirecting hosts to an alternate router. Redirect is specified in Section 8 of RFC 2461 [6]. It is similar to the ICMPv4 Redirect message [19]. o The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link. Router Discovery is described in Section 6 of RFC 2461 [6]. The main purpose of Router Discovery is to find neighboring routers that are willing to forward packets on behalf of hosts. Prefix discovery involves determining which destinations are directly on a link; this information is necessary in order to know whether a packet should be sent to a router or to the destination node directly. Typically, address autoconfiguration and other tasks can not proceed until suitable routers and prefixes have been found. The Neighbor Discovery messages follow the ICMPv6 message format and ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 is 58. The actual Neighbor Discovery message includes an ND message header consisting of ICMPv6 header and ND message-specific data, and zero or more ND options: <------------ND Message-----------------> *-------------------------------------------------------------* | IPv6 Header | ICMPv6 | ND message- | ND Message | | Next Header = 58 | Header | specific | Options | | (ICMPv6) | | data | | *-------------------------------------------------------------* <--ND Message header---> The ND message options are formatted in the Type-Length-Value format. All IPv6 ND protocol functions are realized using the following messages: Arkko, et al. Expires December 4, 2003 [Page 8] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 ICMPv6 Type Message ------------------------------------ 133 Router Solicitation (RS) 134 Router Advertisement (RA) 135 Neighbor Solicitation (NS) 136 Neighbor Advertisement (NA) 137 Redirect The functions of the ND protocol are realized using these messages as follows: o Router Discovery uses the RS and RA messages. o Duplicate Address Detection uses the NS and NA messages. o Address Autoconfiguration uses the NS, NA, RS, and RA messages. o Address Resolution uses the NS and NA messages. o Neighbor Unreachability Detection uses the NS and NA messages. o Redirect uses the Redirect message. The destination addresses used in these messages are as follows: o Neighbor Solicitation: The destination address is either the solicited-node multicast address, unicast address, or an anycast address. o Neighbor Advertisement: The destination address is either a unicast address or the All Nodes multicast address [1]. o Router Solicitation: The destination address is typically the All Routers multicast address [1]. o Router Advertisement: The destination address can be either a unicast or the All Nodes multicast address [1]. Like the solicitation message, the advertisement is also local to the link only. o Redirect: This message is always sent from the router's link-local address to the source address of the packet that triggered the Redirect. Hosts verify that the IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. Rules in [1] dictate that unspecified, anycast, or multicast addresses may not be used as source addresses. Therefore, the destination address will always be a unicast address. Arkko, et al. Expires December 4, 2003 [Page 9] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 4. Secure Neighbor Discovery Overview IPsec AH is used in to protect Neighbor and Router Discovery messages. This specification introduces the use of a new transform for IPsec AH, extensions to the current IPsec selectors, an authorization delegation discovery process, and an address ownership proof mechanism. The components of the solution specified in this document are as follows: o Trusted roots are expected to certify the authority of routers. A host and a router must have at least one common trusted root before the host can adopt the router as its default router. Optionally, an authorization certificate can specify the prefixes for which the router is allowed to act as a router. Delegation Chain Solicitation and Advertisement messages are used to discover a certificate chain to the trusted root without requiring the actual Router Discovery messages to carry lengthy certificate chains. o Cryptographically Generated Addresses are used to assure that the sender of a Neighbor or Router Advertisement is the owner of an the claimed address. A public-private key pair needs to be generated by all nodes before they can claim an address. o IPsec AH is used to protect all messages relating to Neighbor and Router discovery. o IPsec security policy database and security association database are configured to require the protection as indicated above. Note that such configuration may take place manually or the operating system may perform it automatically upon enabling Secure Neighbor Discovery. This specification introduces extensions to the required selectors used in security policy database entries. This is necessary in order to enable the protection of specific ICMP message types, while leaving other messages unprotected. o A new transform for IPsec AH allows public keys to be used on a security association directly without the involvement of a key management protocol. Symmetric session keys are not used, public key signatures are used instead. The trust to the public key is established either with the authorization delegation process or the address ownership proof mechanism, depending on configuration and the type of the message protected. Arkko, et al. Expires December 4, 2003 [Page 10] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 The new transform uses also a fixed, standardized SPI (Security Parameters Index) number. This is necessary again in order to avoid the involvement of a key management protocol. Given that Neighbor and Router Discovery messages are in some cases sent to multicast addresses, the new transform uses timestamps as a replay protection mechanism instead of sequence numbers. To provide additional replay protection for the cases where required clock accuracy is not available, nonces are used in the Neighbor Discovery protocol. Arkko, et al. Expires December 4, 2003 [Page 11] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 5. Modifications to Neighbor Discovery Support for the SEND protocol can be added to a Neighbor Discovery implementation by providing the new Neighbor Discovery protocol mechanisms described in Section 6, the IPsec mechanisms described in Section 7, and using them together as specified in Section 9 and Section 8. However, the following aspects of the Neighbor Discovery protocol change with SEND: o The use of the unspecified address as a source address is discouraged. o The solicited-node multicast address is replaced with the securely-solicited-node multicast address. o The Nonce option is required in all Neighbor Discovery solicitations, and for all solicited advertisements. o Proxy Neighbor Discovery is not supported in this specification (it will be specified in a future document). 5.1 Unspecified Source Address In SEND, the unspecified address is not used as the source address in Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, or Redirect messages. A Neighbor Solicitation sent as a part of Duplicate Address Detection uses the tentative address for which the Duplicate Address Detection is being run. The use of the unspecified address is avoided in Router Solicitations, if possible. RFC 2461 requires that Router Solicitations sent from the unspecified address do not cause a modification in the Neighbor Cache. 5.2 Secure-Solicited-Node Multicast Address SEND defines the securely-solicited-node multicast addresses. These addresses are of the form: FF02:0:0:0:0:1:FEXX:XXXX Like the solicited-node multicast address, this multicast address is computed as a function of a node's unicast and anycast addresses. The securely-solicited-node multicast address is formed by taking the low-order 24 bits of the address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FE00::/104 resulting in a multicast address in the range FF02:0:0:0:0:1:FE00:0000 to Arkko, et al. Expires December 4, 2003 [Page 12] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 FF02:0:0:0:0:1:FEFF:FFFF. As discussed in Section 8.1, SEND uses the securely-solicited-node multicast address instead of the solicited-node multicast address when sending secured Neighbor Solicitations. However, in order to allow for co-existence of secure and insecure Neighbor Discovery on the same link, SEND nodes will also send Duplicate Address Detection probes to the solicited-node multicast address (see Section 10). The use of two different addresses is necessary in order to distinguish between these messages in the security policy database. 5.3 Nonce Option The purpose of the Nonce option is to ensure that an advertisement is a fresh response to a solicitation sent earlier by this same node. The format of the Nonce option is as described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Nonce ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the fields are as follows: Type TBD for Nonce. Length The length of the option (including the Type, Length, and Nonce fields) in units of 8 octets. Nonce This field contains a random number selected by the sender of the solicitation message. The length of the number MUST be at least 6 bytes. Arkko, et al. Expires December 4, 2003 [Page 13] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 5.4 Proxy Neighbor Discovery The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in the case of proxy Neighbor Discovery. Proxy Neighbor Discovery is discussed in another specification. Arkko, et al. Expires December 4, 2003 [Page 14] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 6. Authorization Delegation Discovery Several protocols, including IPv6 Neighbor Discovery, allow a node to automatically configure itself based on information it learns shortly after connecting to a new link. It is particularly easy for "rogue" routers to be configured, and it is particularly difficult for a network node to distinguish between valid and invalid sources of information when the node needs this information before communicating off-link. Since the newly-connected node likely can not communicate off-link, it can not be responsible for searching information to help validate the router; however, given a chain of appropriately signed certificates, it can check someone else's search results and conclude that a particular message comes from an authorized source. Similarly, the router, which is already connected to the network, can if necessary communicate off-link and construct the certificate chain. The Secure Neighbor Discovery protocol introduces two new ICMPv6 messages that are used between hosts and routers to allow the client to learn the certificate chain with the assistance of the router. Where hosts have certificates from a trusted root, these messages MAY also optionally be used between hosts to acquire the peer's certificate chain. The Delegation Chain Solicitation message is sent by hosts when they wish to request the certificate chain between a router and the one of the hosts' trusted roots. The Delegation Chain Advertisement message is sent as an answer to this message, or periodically to the All Nodes multicast address. These messages are separate from the rest of the Neighbor Discovery in order to reduce the effect of the potentially voluminous certificate chain information to other messages. The Authorization Delegation Discovery process does not exclude other forms of discovering the certificate chains. For instance, during fast movements mobile nodes may learn information - including the certificate chains - of the next router from the previous router. 6.1 Delegation Chain Solicitation Message Format Hosts send Delegation Chain Solicitations in order to prompt routers to generate Delegation Chain Advertisements quickly. Arkko, et al. Expires December 4, 2003 [Page 15] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface. Destination Address Typically the all-routers multicast address, the securely-solicited-node multicast address (see Section 5.2, or the address of the hosts' default router. Hop Limit 255 ICMP Fields: Type TBD for Delegation Chain Solicitation. Code 0 Checksum The ICMP checksum [8].. Identifier This 16 bit unsigned integer field acts as an identifier to help match advertisements to solicitations. The Identifier field MUST NOT be zero. Arkko, et al. Expires December 4, 2003 [Page 16] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Trusted Root One or more trusted roots that the client is willing to accept. 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. 6.2 Delegation Chain Advertisement Message Format Routers send out Delegation Chain Advertisement messages periodically, or in response to a Delegation Chain 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 | Component | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be a unicast address assigned to the interface from which this message is sent. Destination Address Either the securely-solicited-node multicast address of the receiver or the all-nodes multicast address. Hop Limit 255 Arkko, et al. Expires December 4, 2003 [Page 17] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 ICMP Fields: Type TBD for Delegation Chain Advertisement. Code 0 Checksum The ICMP checksum [8].. Identifier This 16 bit unsigned integer field acts as an identifier to help match advertisements to solicitations. The Identifier field MUST be zero for unsolicited advertisements and MUST NOT be zero for solicited advertisements. Component This is a 16 bit unsigned integer field used for informing the receiver which certificate is being sent, and how many are still left to be sent in the whole chain. A single advertisement MUST be broken into separately sent components if there is more than one Certificate option, in order to avoid excessive fragmentation at the IP layer. Unlike the fragmentation at the IP layer, individual components of an advertisement may be stored and taken in use before all the components have arrived; this makes them slightly more reliable and less prone to Denial-of-Service attacks. The first message in a N-component advertisement has the Component field set to N-1, the second set to N-2, and so on. Zero indicates that there are no more components coming in this advertisement. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Certificate One certificate is provided in Certificate option, to establish Arkko, et al. Expires December 4, 2003 [Page 18] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 a (part of) certificate chain to a trusted root. Trusted Root Zero or more Trusted Root 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. 6.3 Trusted Root Option The format of the Trusted Root option is as described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Name Type | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the fields are as follows: Type TBD for Trusted Root. Length The length of the option (including the Type, Length, Name Type, Name Length, and Name fields) in units of 8 octets. Name Type The type of the name included in the Name field. This specification defines only one legal value for this field: 1 FQDN Arkko, et al. Expires December 4, 2003 [Page 19] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Name Length The length of the Name field, in bytes. Octets beyond this length but within the length specified by the Length field are padding and MUST be set to zero by senders and ignored by receivers. Name When the Name Type field is set to 1, the Name field contains the Fully Qualified Domain Name of the trusted root, for example "trustroot.operator.com". 6.4 Certificate Option The format of the certificate option is as described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Cert Type | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the fields are as follows: Type TBD for Certificate. 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 included in the Name field. This specification defines only one legal value for this field: 1 X.509 Certificate Pad Length The amount of padding beyond the end of the Certificate field but within the length specified by the Length field. Padding MUST be Arkko, et al. Expires December 4, 2003 [Page 20] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 set to zero by senders and ignored by receivers. Certificate When the Cert Type field is set to 1, the Certificate field contains an X.509 certificate [16]. 6.5 Router Authorization Certificate Format The certificate chain of a router terminates in a router authorization certificate that authorizes a specific IPv6 node as a router. Because authorization chains are not common practice in the Internet at the time this specification is being written, the chain MUST consist of standard Public Key Certificates (PKC, in the sense of [11]) for identity from the trusted root shared with the host to the router. This allows the host to anchor trust for the router's public key in the trusted root. The last item in the chain is an Authorization Certificate (AC, in the sense of [12]) authorizing the router's right to route. Stronger certification is necessary here than for CGAs because the right to route must be granted by an authorizing agency. Future versions of this specification may include provision for full authorization certificate chains, should they become common practice. SEND nodes MUST support the RFC 3281 X.509 attribute certificate format [12] as the default format for router authorization certificates, and MAY support other formats. Router authorization certificates MUST be signed by the network operator or other trusted third party whose PKC is above the router's PKC in the delegation chain. Routers MAY advertise multiple ACs if the trust delegation obtains from different trust roots, and the authorized prefixes in those certificates MAY be disjoint. A router SHOULD only advertise one AC corresponding to one trust root and all interfaces and prefixes covered by that trust root MUST be in the AC. In the attribute certificate, the GeneralName type MUST be either a dNSName or iPAddress for the router, unless otherwise specified by RFC 3281. If the GeneralName attribute is a dNSName, it MUST be resolvable to a global unicast address assigned to the router. If the GeneralName attribute is an iPAddress, it MUST be a global unicast address assigned to the router. For purposes of facilitating renumbering, a dNSName SHOULD be used. However, hosts MUST NOT use a dNSName or iPAddress for validating the certificate. The router's public key hash, stored in the acinfo.holder.objectDigestInfo.objectDigest field of the certificate provides the definitive validation. As explained in Section 9.2, the addresses from the certificate can be matched against the global Arkko, et al. Expires December 4, 2003 [Page 21] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 addresses claimed in the Router Advertisement. 6.5.1 Field Values acinfo.holder.entityName This field MAY contain one or several entityNames, of type dNSName or iPAddress, referring to global address(es) belonging to the router. acinfo.objectDigestInfo.digestedObjectType This field MUST be present and of type (1), publicKey. acinfo.holder.digestAlgorithm This field MUST indicate id-sha1 as indicated in RFC 3279 [10]. acinfo.objectDigestInfo.objectDigest This field MUST be a SHA-1 digest over either a PKCS#1 [17] (RSA) or an RFC 3279 Section 2.3.2 representation [10] (DSA) representation of the router's public key. If this digest does not match the digest of the router's public key from its PKC, a node MUST discard the certificate. acinfo.issuer.v2form.issuerName The field MUST contain the distinguished name from the PKC used to sign the router AC. acinfo.attrCertValidityPeriod A node MUST NOT accept a certificate if the validity period has ended or has not yet started. acinfo.attributes This field MUST contain a list of prefixes that the router is authorized to route, or the unspecified prefix if the router is allowed to route any prefix. The field has the following type: name: AuthorizedSubnetPrefix OID: {id-rcert} Syntax: iPAddress values: Multiple allowed Multiple prefix values are allowed. Arkko, et al. Expires December 4, 2003 [Page 22] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 The details of the above syntax are specified in Section 2.2.3.8 of [14]. If the router is authorized only to route specific prefixes, the ipAddress values consist of IPv6 addresses in standard RFC 3513 [13] prefix format. One iPAddress value appears for each prefix routed by the router. If the router is authorized to route any prefix, a single ipAddress value appears with the value of the unspecified address. 6.6 Processing Rules for Routers Routers SHOULD possess a key pair and certificate from at least one certificate authority. A router MUST silently discard any received Delegation Chain Solicitation messages that do not satisfy all of the following validity checks: o The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. o If the message includes an IP Authentication Header, the message authenticates correctly. o ICMP Checksum is valid. o ICMP Code is 0. o ICMP length (derived from the IP length) is 8 or more octets. o Identifier field is non-zero. o All included options have a length that is greater than zero. 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; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored and the packet processed in the normal manner. The only defined option that may appear is the Trusted Root option. A solicitation that passes the validity checks is called a "valid solicitation". Routers MAY send unsolicited Delegation Chain Advertisements for Arkko, et al. Expires December 4, 2003 [Page 23] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 their trusted root. When such advertisements are sent, their timing MUST follow the rules given for Router Advertisements in RFC 2461 [6]. The only defined option that may appear is the Certificate option. At least one such option MUST be present. Router SHOULD also include at least one Trusted Root option to indicate the trusted root on which the Certificate is based. In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A router MUST send the response to the all-nodes multicast address, if the source address in the solicitation was the unspecified address. If the source address was a unicast address, the router MUST send the response to the securely-solicited-node multicast address corresponding to the source address. In a solicited advertisement, the router SHOULD include suitable Certificate options so that a delegation chain to the solicited root can be established. The root is identified by the FQDN from the Trusted Root option being equal to an FQDN in the AltSubjectName field of the root's certificate. The router SHOULD include the Trusted Root option(s) in the advertisement for which the delegation chain was found. If the router is unable to find a chain to the requested root, it SHOULD send an advertisement without any certificates. In this case the router SHOULD include the Trusted Root options which were solicited. Rate limitation of Delegation Chain Advertisements is performed as specified for Router Advertisements in RFC 2461 [6]. 6.7 Processing Rules for Hosts Hosts SHOULD possess the certificate of at least one certificate authority, and MAY possess their own key pair and certificate from this authority. A host MUST silently discard any received Delegation Chain Advertisement messages that do not satisfy all of the following validity checks: o IP Source Address is a unicast address. Note that routers may use multiple addresses, so this address not sufficient for the unique identification of routers. o IP Destination Address is either the all-nodes multicast address or the securely-solicited-node multicast address corresponding to Arkko, et al. Expires December 4, 2003 [Page 24] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 one of the unicast addresses assigned to the host. o The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. o If the message includes an IP Authentication Header, the message authenticates correctly. o ICMP Checksum is valid. o ICMP Code is 0. o ICMP length (derived from the IP length) is 16 or more octets. o All included options have a length that is greater than zero. 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; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Delegation Chain Advertisement messages MUST be ignored and the packet processed in the normal manner. The only defined option that may appear is the Certificate option. An advertisement that passes the validity checks is called a "valid advertisement". Hosts SHOULD store all certificates retrieved in Delegation Chain Advertisements for use in subsequent verification of Neighbor Discovery messages. Note that it may be useful to cache this information and implied verification results for use over multiple attachments to the network. In order to use an advertisement for the verification of a specific Neighbor Discovery message, the host matches the key hash in acinfo.Holder.objectDigestInfo to the public key carried in the IPsec AH Authentication Data field. When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Delegation Chain Advertisement. To obtain such advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation Chain Solicitations SHOULD be sent after any of the following events: o The interface is initialized at system startup time. o The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. o The system changes from being a router to being a host, by having Arkko, et al. Expires December 4, 2003 [Page 25] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 its IP forwarding capability turned off by system management. o The host attaches to a link for the first time. o A movement has been indicated by lower layers or has been inferred from changed information in a Router Advertisement. o The host re-attaches to a link after being detached for some time. o A Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trusted root. Delegation Chain Solicitations MUST NOT be sent if the host has a currently valid certificate chain for the router to a trusted root, including the Attribute Certificate for the desired router (or host). A host MUST send Delegation Chain Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address if it has already been selected. If two hosts communicate with the solicitations and advertisements, the solicitations MUST be sent to the securely-solicited-node multicast address of the receiver. The advertisements MUST be sent as specified above for routers. Delegation Chain Solicitations SHOULD be rate limited and timed similarly with Router Solicitations, as specified in RFC 2461 [6]. When processing a possible advertisement sent as a response to a solicitation, the host MAY prefer to process first those advertisements with the same Identifier field value as in the solicitation. This makes Denial-of-Service attacks against the mechanism harder (see Section 13.3). Arkko, et al. Expires December 4, 2003 [Page 26] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 7. IPsec Extensions In order to use IPsec in securing Neighbor and Router Discovery some extensions have been specified in this document. These include a new transform suitable for the use of public keys and/or CGAs, a timestamp mechanism suitable for replay protection in a multicast environment, and some extensions to security association and security policy databases. These changes are related to the proposed new transform and the reserved SPI number, and do not represent a fundamental change to the IPsec architecture. Some of the changes, such as the treatment of destination addresses, are also being proposed as a part of the revision of the IPsec standards. 7.1 The AH_RSA_Sig Transform The AH_RSA_Sig transform specifies how AH can be used without a symmetric key. This transform introduces the use of a new reserved SPI number and a new format for the Authentication Data field in AH. AH_RSA_Sig MUST NOT be negotiated in IKE. For consistency it has an IPsec DOI [4] Transform ID TBD , however. 7.1.1 Reserved SPI Number The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD . 7.1.2 Authentication Data Format The format of the Authentication Data field in AH depends on the chosen transform. For the AH_RSA_Sig transform, the format is as follows: Arkko, et al. Expires December 4, 2003 [Page 27] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Key Information . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital Signature (remaining bytes) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The meaning of the fields is described below: Timestamp This 64 bit unsigned integer field contains a timestamp used for replay protection (the Sequence Number field in AH is not used for AH_RSA_Sig). The use of this field is discussed in Section 7.1.4. Key Information This variable length field contains the public key of the sender. It also may contain some other additional information which is necessary when CGA is used. The contents of the Key Information field are represented as ASN.1 DER-encoded data item of the following type: SendKeyInformation ::= SEQUENCE { cgaParameters CGAParameters OPTIONAL, signerInfo SubjectPublicKeyInfo OPTIONAL } CGAParameters ::= SEQUENCE { publicKey SubjectPublicKeyInfo, auxParameters CGAAuxParameters OPTIONAL } (The normative definition of the type CGAParameters is in in [27]). At least one or both fields in SendKeyInformation MUST be present. The packet MUST be silently discarded if both are missing. The Arkko, et al. Expires December 4, 2003 [Page 28] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 verification of the CGA is based on the contents of the cgaParameters field. The verification of the Digital Signature field is based on the contents of the signerInfo field if it is present. Otherwise, the verification is based on the publicKey field in the cgaParameters field. This specification requires that if both cgaParameters and signerInfo fields are present, then the public keys in them MUST be the same, and packets received with two different keys MUST be silently discarded. Note that a future extension may provide a mechanism which allows the owner of an address and the signer to be different parties. The length of the Key Information field is determined by the ASN.1 encoding. Digital Signature This variable length field contains the signature made using the sender's private key, over the the whole packet as defined by the usual AH rules [3]. The signature is made using the RSA algorithm and MUST be encoded as private key encryption in PKCS #1 format [17]. The length of this field is determined by the PKCS #1 encoding. 7.1.3 AH_RSA_Sig Security Associations Incoming security associations that specify the use of AH_RSA_Sig transform MUST record the following additional configuration information: CGA flag A flag that indicates whether or not the CGA property must be verified. router authority Whether or not router authority must be verified as described in Section 6.5. root The public key of the trusted root, if authorization delegation is in use. Arkko, et al. Expires December 4, 2003 [Page 29] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 minbits The minimum acceptable key length for peer public keys (and any intermediaries between the trusted root and the peer). The default SHOULD be 768 bits. Implementations MAY also set an upper limit in order to limit the amount of computation they need to perform when verifying packets that use these security associations. minSec The minimum acceptable Sec value, if CGA verification is required (see Section 2 in [27]. Outgoing security associations MUST also record the following additional information: keypair A public-private key pair. If authorization delegation is in use, there must exist a delegation chain from a trusted root to this key pair. CGA flag A flag that indicates whether or not the CGA is used. CGA parameters Optionally any information required to construct CGAs, including the used Sec value and nonce, and the CGA itself. 7.1.4 Replay Protection For AH_RSA_Sig, the Sequence Number field in AH MUST be set to zero by the sender and ignored by receivers. If anti-replay has been enabled in the security association, senders MUST set the Timestamp field to the current time. The format is 64 bits, and the contents are the number of milliseconds since January 1, 1970 00:00 UTC. If anti-replay has been enabled, receivers MUST be configured with an allowed Delta value and maintain a cache of messages received within this time period from each specific source address. Receivers MUST then check the Timestamp field as follows: Arkko, et al. Expires December 4, 2003 [Page 30] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 o A packet with a Timestamp field value beyond the current time plus or minus the allowed Delta value MUST be silently discarded. Recommended default value for the allowed Delta is 3,600 seconds. o A packet accepted according to the above rule MUST be checked for uniqueness within the cache of received messages from the given source address. A packet that has already been seen from the same source with the same Timestamp field value MUST be silently discard. o A packet that passes both of the above tests MUST be registered in the cache for the given source address. o If the cache becomes full, the receiver SHOULD temporarily reduce the Delta value for that source address so that all messages within that value can still be stored. Note that timestamps are not necessary for replay protection in solicited advertisements, but must be included in the messages. 7.1.5 Processing Rules for Senders A node sending a packet using the AH_RSA_Sig transform MUST construct the packet as follows: o The Next Header, Payload Len, and Reserved fields are set as described in RFC 2402. o The Security Parameters Index is set to the value specified in Section 7.1.1. o The Sequence Number field is set to 0. o The Timestamp field is set as described in Section 7.1.4. o The Key Information field in the Authentication Data field is set to the SendKeyInformation structure according to the rules in Section 7.1.2 and [27]. The used public key is the one stored in the security association. o The packet, in the form defined for AH's coverage, is signed using the private key in the security association, and the resulting PCKS #1 signature is put to the Digital Signature field. One of the keys from the Key Information field is used for this purpose, as described in Section 7.1.2. o Additionally, if the use of CGA has been specified for the Arkko, et al. Expires December 4, 2003 [Page 31] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 security association, the source address of the packet MUST be constructed as specified in [27]. 7.1.6 Processing Rules for Receivers A packet received on a security association employing AH_RSA_Sig transform MUST be checked as follows: o Next Header and Payload Len fields are valid as specified in RFC 2402. o The SPI field is equal to the value defined in Section 7.1.1. o The Timestamp field is verified as described in Section 7.1.4. o The Key Information and Digital Signature fields have correct encoding, and do not exceed the length of the Authentication Data field. o If the use of CGA has been specified in the security association, we additionally require the receiving node to verify the source address of the packet using the algorithm described in Section 5 of [27]. The inputs for the algorithm are the contents of the CGAParameters structure from the Key Information field, the source address of the packet, and the minimum acceptable Sec value from the security association. If the CGA verification is successful, the recipient proceeds with the cryptographically more time consuming check of the AH signature. Note that a receiver which does not support CGA or has not specified its use in its security associations can still verify packets using trusted roots, even if CGA had been used on a packet. The CGA property of the address is simply left untested. o The Digital Signature verification shows that it has been calculated as specified in the previous sections. o If the use of a trusted root has been configured for the security association, a valid authorization delegation chain is known between the receiver's trusted root and the sender's public key. Note that the receiver may verify just the CGA property of a packet, even if the sender has used a trusted root as well. Packets that do not pass all the above tests MUST be silently discarded. Arkko, et al. Expires December 4, 2003 [Page 32] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 7.2 Other IPsec Extensions 7.2.1 Destination Agnostic Security Associations In order to allow the same security association to be used when the the node sends packets to different peers using the same addresses, an extension must be provided to the RFC 2401 rules on how security associations are identified. This change is particularly important, for instance, when routers use the same keys and security association to send Router Advertisements for up to number of prefixes x 2^64 hosts on an interface. This extension is mandatory for all nodes that support the AH_RSA_Sig transform. Security associations that use the SPI value specified in Section 7.1.1 MUST be identified solely by the SPI and protocol numbers, not by the destination IP address. Note that this extension can be supported without implementation modifications where the proposed revisions of the IPsec standards are in use [26]. 7.2.2 ICMP Type Specific Selectors In order to allow finer granularity of protection for various ICMPv6 messages, it is necessary to extend the security policy database and security association selectors with the capability to distinguish between different messages. All nodes that support the AH_RSA_Sig transform MUST be capable of using ICMP and ICMPv6 Type field as a selector. Note that this can be achieved in an implementation by using the port number field to contain the ICMP type if the protocol field is ICMP. Arkko, et al. Expires December 4, 2003 [Page 33] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 8. Securing Neighbor Discovery with SEND This section describes how to use IPsec and the mechanisms from [27], Section 6, Section 7 in order to provide security for Neighbor Discovery. 8.1 Neighbor Solicitation Messages All Neighbor Solicitation messages are protected with AH_RSA_Sig. 8.1.1 Sending Secure Neighbor Solicitations Secure Neighbor Solicitation messages are sent as described in RFC 2461 and 2462, with the additional requirements listed in the following. All Neighbor Solicitation messages sent MUST be protected with IPsec, using the AH_RSA_Sig transform. The security associations used for this MUST be configured with the sender's key pair, optionally setting the CGA flag and including additional CGA parameter information. The source address of the message MUST NOT be the unspecified address. A Neighbor Solicitation sent as a part of Duplicate Address Detection MUST use as a source address the tentative address for which the Duplicate Address Detection is being run. In SEND, Neighbor Solicitations MUST be sent either to the target address or to the securely-solicited-node multicast address corresponding to the target address. When an interface is initialized, a node MUST join securely-solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [7]. In such cases the node MUST join and leave the securely-solicited-node multicast address corresponding to the new and old addresses, respectively. Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the securely-solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed. The Nonce option MUST be included in all messages. 8.1.2 Receiving Secure Neighbor Solicitations Received Neighbor Solicitation messages are processed as described in RFC 2461 and 2462, with the additional SEND-related requirements Arkko, et al. Expires December 4, 2003 [Page 34] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 listed in the following. Neighbor Solicitation messages received without an IPsec AH header and the AH_RSA_Sig transform MUST be silently discarded. The security associations used for this MUST be configured with the expected authorization mechanism (CGA or trusted root), the minimum allowable key size, and optionally with the information related to the trusted root and the acceptable minSec value. If source address of the Neighbor Solicitation message is the unspecified address, the message MUST be silently discarded. Neighbor Solicitations received without the Nonce option MUST be silently discarded. 8.2 Neighbor Advertisement Messages All Neighbor Advertisement messages are protected with AH_RSA_Sig. 8.2.1 Sending Secure Neighbor Advertisements Secure Neighbor Advertisement messages are sent as described in RFC 2461 and 2462, with the additional requirements listed in the following. All Neighbor Advertisement messages sent MUST be protected with IPsec, using the AH_RSA_Sig transform. The security associations used for this MUST be configured with the sender's key pair, optionally setting the CGA flag and including additional CGA parameter information. Neighbor Advertisements sent in response to a Neighbor Solicitation MUST contain a copy of the Nonce option included in the solicitation. The source address of the message MUST NOT be the unspecified address. 8.2.2 Receiving Secure Neighbor Advertisements Received Neighbor Advertisement messages are processed as described in RFC 2461 and 2462, with the additional SEND-related requirements listed in the following. Neighbor Advertisement messages received without an IPsec AH header and the AH_RSA_Sig transform MUST be silently discarded. The security associations used for this MUST be configured with the expected authorization mechanism (CGA or trusted root), the minimum allowable key size, and optionally with the information related to Arkko, et al. Expires December 4, 2003 [Page 35] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 the trusted root and the acceptable minSec value. Received Neighbor Advertisements sent to a unicast destination address without a Nonce option MUST be silently discarded. If source address of the Neighbor Advertisement message is the unspecified address, the message MUST be silently discarded. 8.3 Other Requirements Upon receiving a message for which the receiver has no certificate chain to a trusted root, the receiver MAY use Authorization Delegation Discovery to learn the certificate chain of the peer. Hosts that use stateless address autoconfiguration MUST generate a new CGA as specified in Section 4 of [27] for each new autoconfiguration run. It is outside the scope of this specification to describe the use of trusted root authorization between hosts with dynamically changing addresses. Such dynamically changing addresses may be the result of stateful or stateless address autoconfiguration or through the use of RFC 3041 [9]. If the CGA method is not used, hosts would be required to exchange certificate chains that terminate in a certificate authorizing a host to use an IP address having a particular interface identifier. This specification does not specify the format of such certificates, since there are currently a few cases where such certificates are required 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. 8.4 Configuration This section shows example security policy and security associations database entries for the protection of Neighbor Solicitation and Advertisement messages. The following table summarizes the inbound security policy data base along with the inbound security associations: Arkko, et al. Expires December 4, 2003 [Page 36] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: NS | * | own | SA = NS_In | +------------------------------------------------------------------+ | ICMPv6: NS | * | sec-sol-node MC | SA = NS_In | +------------------------------------------------------------------+ | ICMPv6: NA | * | own | SA = NA_In | +------------------------------------------------------------------+ | ICMPv6: NA | * | all-nodes MC | SA = NA_In | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | NS_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | NA_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ The following table summarizes outbound security policy database: Arkko, et al. Expires December 4, 2003 [Page 37] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: NS | own | * | SA = NS_Out | +------------------------------------------------------------------+ | ICMPv6: NA | own | * | SA = NA_Out | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | NS_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | NA_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ Arkko, et al. Expires December 4, 2003 [Page 38] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 9. Securing Router Discovery with SEND This section describes how to use IPsec and the mechanisms from [27], Section 6, Section 7 in order to provide security for Router Discovery. 9.1 Router Solicitation Messages All Router Solicitation messages are protected with AH_RSA_Sig. 9.1.1 Sending Secure Router Solicitations Secure Router Solicitation messages are sent as described in RFC 2461, with the additional requirements listed in the following. All Router Solicitation messages sent MUST be protected with IPsec, using the AH_RSA_Sig transform. The security associations used for this MUST be configured with the sender's key pair, optionally setting the CGA flag and including additional CGA parameter information. Hosts SHOULD avoid the use of the unspecified address as the source address in a Router Solicitation message, if other addresses are available. The Nonce option MUST be included in all messages. 9.1.2 Receiving Secure Router Solicitations Received Router Solicitation messages are processed as described in RFC 2461, with the additional SEND-related requirements listed in the following. Router Solicitation messages received without an IPsec AH header and the AH_RSA_Sig transform MUST be silently discarded. The security associations used for this MUST be configured with the expected authorization mechanism (CGA or trusted root), the minimum allowable key size, and optionally with the information related to the trusted root and the acceptable minSec value. Router Solicitations received without the Nonce option MUST be silently discarded. 9.2 Router Advertisement Messages All Router Advertisement messages are protected with AH_RSA_Sig. Arkko, et al. Expires December 4, 2003 [Page 39] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 9.2.1 Sending Secure Router Advertisements Secure Router Advertisement messages are sent as described in RFC 2461, with the additional requirements listed in the following. All Router Advertisement messages sent MUST be protected with IPsec, using the AH_RSA_Sig transform. The security associations used for this MUST be configured with the sender's key pair, optionally setting the CGA flag and including additional CGA parameter information. Router Advertisements sent in response to a Router Solicitation MUST contain a copy of the Nonce option included in the solicitation. The source address of the message MUST NOT be the unspecified address. 9.2.2 Receiving Secure Router Advertisements Received Router Advertisement messages are processed as described in RFC 2461, with the additional SEND-related requirements listed in the following. Router Advertisement messages received without an IPsec AH header and the AH_RSA_Sig transform MUST be silently discarded. The security associations used for this MUST be configured with the expected authorization mechanism (CGA or trusted root), the minimum allowable key size, and optionally with the information related to the trusted root and the acceptable minSec value. Received Router Advertisements sent to a unicast destination address without a Nonce option MUST be silently discarded. If source address of the Router Advertisement message is the unspecified address, the message MUST be silently discarded. 9.3 Redirect Messages All Redirect messages are protected with AH_RSA_Sig. 9.3.1 Sending Redirects Secure Redirect messages are sent as described in RFC 2461, with the additional requirements listed in the following. All Redirect messages sent MUST be protected with IPsec, using the AH_RSA_Sig transform. The security associations used for this MUST be configured with the sender's key pair, optionally setting the CGA Arkko, et al. Expires December 4, 2003 [Page 40] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 flag and including additional CGA parameter information. The source address of the Redirect message MUST NOT be the unspecified address. 9.3.2 Receiving Redirects Received Redirect messages are processed as described in RFC 2461, with the additional SEND-related requirements listed in the following. Redirect messages received without an IPsec AH header and the AH_RSA_Sig transform MUST be silently discarded. The security associations used for this MUST be configured with the expected authorization mechanism (CGA or trusted root), the minimum allowable key size, and optionally with the information related to the trusted root and the acceptable minSec value. If only CGA-based security associations are used, hosts MUST follow the rules defined below when receiving Redirect messages: 1. The Redirect message MUST be protected as discussed above. 2. The receiver MUST verify that the Redirect message comes from an IP address to which the host may have earlier sent the packet that the Redirect message now partially returns. That is, the source address of the Redirect message must be the default router for traffic sent to the destination of the returned packet. If this is not the case, the message MUST be silently discarded. This step prevents a bogus router from sending a Redirect message when the host is not using the bogus router as a default router. If source address of the Redirect message is the unspecified address, the message MUST be silently discarded. 9.4 Other Requirements The certificate for a router MAY specify the global IP address(es) of the router. If so, only these addresses can appear in advertisements where the Router Address (R) bit [15] is set. All hosts MUST have the certificate of a trusted root. Hosts SHOULD use Authorization Delegation Discovery to learn the certificate chain of their default router or peer host, as explained in Section 6. The receipt of a protected Router Advertisement message for which no router Authorization Certificate and certificate chain is available triggers Authorization Delegation Discovery. Arkko, et al. Expires December 4, 2003 [Page 41] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 9.5 Configuration This section shows example security policy and security associations database entries for the protection of Redirect, Router Solicitation and Advertisement messages. The following table summarizes the inbound security policy data base along with the inbound security associations: Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: RS | * | own | SA = RS_In | +------------------------------------------------------------------+ | ICMPv6: RS | * | all-routers MC | SA = RS_In | +------------------------------------------------------------------+ | ICMPv6: RA | * | own | SA = RA_In | +------------------------------------------------------------------+ | ICMPv6: RA | * | all-nodes MC | SA = RA_In | +------------------------------------------------------------------+ | ICMPv6: REDIRECT | * | own | SA = RE_In | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | RS_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | RA_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | RE_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ The following table summarizes outbound security policy database. The Router Advertisement and Redirect entries are only present in routers. Arkko, et al. Expires December 4, 2003 [Page 42] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: RS | own | * | SA = RS_Out | +------------------------------------------------------------------+ | ICMPv6: RA | own | * | SA = RA_Out | +------------------------------------------------------------------+ | ICMPv6: REDIRECT | own | * | SA = RE_Out | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | RS_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | RA_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | RE_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ Arkko, et al. Expires December 4, 2003 [Page 43] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 10. Co-Existence of SEND and ND During the transition to secure links or as a policy consideration, network operators may want to run a particular link with a mixture of secure and insecure nodes. In such a case, the link is required to operate as two separate logical links, and packets between a secure and insecure node always go through the router. Routers configured for SEND advertise two sets of globally routable prefixes: one set for SEND nodes and one set for nodes that implement insecure Neighbor Discovery. The insecure nodes will ignore the advertisements sent using SEND, as the original Neighbor Discovery specifications require silently discarding packets if they contain an AH header that they can not verify. 10.1 Behavior Rules The following considerations apply to all nodes: o Nodes configured for SEND MUST listen to the solicited-node multicast address in addition to the securely-solicited-node multicast address. The messages received on the solicited-node multicast address are unprotected, but the SEND node MUST respond to them as follows. Upon seeing a Neighbor Solicitation for an address which is currently assigned to its own interface, the SEND node sends as a response a Neighbor Solicitation with the following contents: * Source address is the unspecified address. * Destination address is the solicited-node multicast address of the target address. * Target address is copied from the original Neighbor Solicitation. * No AH header is included. * The Nonce option is included in the Neighbor Solicitation. As a result of seeing this Neighbor Solicitation, the sender of the original Neighbor Solicitation concludes that it is attempting to use an address which another node is also attempting to use. This prevents the non-SEND node from using an address already in use by a SEND node. Arkko, et al. Expires December 4, 2003 [Page 44] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 On some interface types, multicast messages can loop back to the sending node. In order to prevent the SEND node from responding to itself, the above solicitations MUST NOT be sent when the original Neighbor Solicitation included the Nonce option. Note that while SEND nodes attempt to ensure that non-SEND nodes use addresses not assigned to the SEND nodes, the reverse is not true: SEND nodes do not avoid the use of an address which is already claimed to be in use by a non-SEND node. This is necessary in order to prevent a denial-of-service attack on secure Duplicate Address Detection. o Similarly, when performing Duplicate Address Detection, nodes configured for SEND MUST send the Neighbor Solicitations both to the securely-solicited-node multicast address with protection, and to the solicited-node multicast address without protection. The following considerations apply to hosts: o Hosts configured for SEND MUST use SEND for all of their addresses, including link local addresses. o Hosts configured for SEND MUST validate all Router Advertisements with the protocol described in Section 8. Note that this includes discarding advertisements received without a valid IPsec AH header, thus making insecure prefixes invisible to them. o Hosts configured for SEND MUST secure and validate all Neighbor Advertisements with the protocol described in Section 8. Note that this includes discarding advertisements received without a valid IPsec AH header. The following considerations apply to routers: o Routers MUST send two sets of Router Advertisements. The advertisements containing the secure prefixes MUST be secured with the protocol described in Section 9. The advertisements containing the insecure prefixes MUST be sent without AH header. o Routers MUST assign different addresses for their secure and insecure communications, including their link-local addresses. Secure Router and Neighbor Advertisements MUST use a source address that satisfies the security properties outlined in Section 9. Unless this address is link-local, it MUST belong to one of the advertised secure prefixes. Similarly, source addresses for insecure advertisements MUST belong to one of the advertised insecure prefixes, unless the address is link-local. Arkko, et al. Expires December 4, 2003 [Page 45] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 o Routers MUST refrain from sending Redirects to a SEND-secured node with the Destination Address field set to an address for an insecure node. Similarly, routers MUST refrain from sending Redirects to a insecure node with the Destination Address field set to an address for a SEND-secured node The above rules require secure nodes to ignore all insecure Neighbor and Router Discovery messages, and all insecure nodes to ignore all SEND-secured messages. This implies that the secure and insecure nodes will not be able to discover each other, or even realize that the other prefixes are on-link. Thus, these hosts will request the router to route packets destined to a host in the other group. The rules regarding Redirect messages above have been provided to ensure that the router performs its routing task and does not instruct the hosts to communicate directly. One effect of this is that secure hosts can not communicate with insecure hosts using link-local addresses, and vice versa. The security policy or security association database entries are needed for insecure nodes as far as Neighbor Discovery is concerned. SEND-secured nodes have the usual entries required by SEND. 10.2 Configuration This section presents the security policy and security association data base configuration required for the co-existence of SEND and non-SEND hosts. The following table summarizes the inbound configuration on a SEND node: Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: NS | * | own | SA = NS_In | +------------------------------------------------------------------+ | ICMPv6: NS | unspecified | solicited-node MC| pass | +------------------------------------------------------------------+ | ICMPv6: NS | * | sec.sol-node MC | SA = NS_In | +------------------------------------------------------------------+ | ICMPv6: NA | * | own | SA = NA_In | +------------------------------------------------------------------+ | ICMPv6: NA | * | all-nodes MC | SA = NA_In | +------------------------------------------------------------------+ | ICMPv6: RS | * | own | SA = RS_In | +------------------------------------------------------------------+ Arkko, et al. Expires December 4, 2003 [Page 46] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 | ICMPv6: RS | * | all-routers MC | SA = RS_In | +------------------------------------------------------------------+ | ICMPv6: RA | * | own | SA = RA_In | +------------------------------------------------------------------+ | ICMPv6: RA | * | all-nodes MC | SA = RA_In | +------------------------------------------------------------------+ | ICMPv6: REDIRECT | * | own | SA = RE_In | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | NS_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | NA_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | RS_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | RA_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ | RE_In | Inbound | To be | AH | AH_RSA_Sig | | | | assigned | |CGA flag = yes/no| | | | by IANA | | root = ... (opt)| +------------------------------------------------------------------+ The second table summarizes the outbound configuration: Policy entries: +------------------------------------------------------------------+ | Proto: Type | Source | Destination | Treatment | +------------------------------------------------------------------+ | ICMPv6: NS | unspecified | solicited-node MC| pass | +------------------------------------------------------------------+ | ICMPv6: NS | own | * | SA = NS_Out | +------------------------------------------------------------------+ Arkko, et al. Expires December 4, 2003 [Page 47] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 | ICMPv6: NA | own | * | SA = NA_Out | +------------------------------------------------------------------+ | ICMPv6: RS | own | * | SA = RS_Out | +------------------------------------------------------------------+ | ICMPv6: RA | own | * | SA = RA_Out | +------------------------------------------------------------------+ | ICMPv6: REDIRECT | own | * | SA = RE_Out | +------------------------------------------------------------------+ Security associations: +------------------------------------------------------------------+ | Name | Direction | SPI | Proto | Transform | +------------------------------------------------------------------+ | NS_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | NA_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | RS_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | RA_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ | RE_Out | Outbound | To be | AH | AH_RSA_Sig | | | | assigned | | key pair = ... | | | | by IANA | | CGA = yes/no | | | | | | CGA params = ...| | | | | | root = ... (opt)| +------------------------------------------------------------------+ Arkko, et al. Expires December 4, 2003 [Page 48] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 11. Performance Considerations The computations related to AH_RSA_Sig transform are substantially more expensive than those with traditional symmetric transforms. While computational power is increasing, it appears still impractical to use asymmetric transforms for a significant number of packets. In the application for which AH_RSA_Sig has been designed, however, hosts typically have the need to perform only a few operations as they enter a link, and a few operations as they find a new on-link peer with which to communicate. Routers are required to perform a larger number of operations, particularly when the frequency of router advertisements is high due to mobility requirements. Still, the number of operations on a router is on the order of a few dozen operations per second, some of which can be precomputed as discussed below. A large number of router solicitations may cause higher demand for performing asymmetric operations, although RFC 2461 limits the rate at which responses to solicitations can be sent. Signatures related to the use of the AH_RSA_Sig transform MAY be precomputed for Multicast Neighbor and Router Advertisements. Typically, solicited advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the AH integrity protection, it is typically not possible to precompute solicited advertisements. Arkko, et al. Expires December 4, 2003 [Page 49] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 12. Implementation Considerations In addition to the IPsec extensions discussed in this specification, it becomes necessary for the IPsec AH implementation and the Neighbor Discovery implementation to exchange some information. Because IPsec security associations are typically set up either manually or using IKE, keys are shared and traditional IPsec does not have to deal with certificates. SEND uses public key cryptography, however, and therefore the keys included in the AH header must be certified, except in the case where simple proof of IP address ownership using CGAs is being determined. This requires an API between the AH_RSA_Sig transform processing code and the host's certificate store, so that the received keys can be checked. Furthermore, if the necessary certificate chain is not in the certificate store, a Delegation Chain Solicitation message must be triggered to fetch the chain. This may require an additional API, although, depending on how the certificate store is implemented, the API may or may not involve the code for the AH_RSA_Sig transform. Both the extensions and the API are required for all types of IPsec implementations, including Bump-in-the-Stack (BITS) implementations. Arkko, et al. Expires December 4, 2003 [Page 50] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 13. Security Considerations 13.1 Threats to the Local Link Not Covered by SEND SEND does not compensate for an insecure link layer. In particular, there is no cryptographic binding in SEND between the link layer frame address and the IPv6 address. On an insecure link layer that allows nodes to spoof the link layer address of other nodes, an attacker could disrupt IP service by sending out a Neighbor Advertisement having the source address on the link layer frame of a victim, a valid CGA with valid AH signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then proceed to cause a traffic stream to bombard the victim in a DoS attack. To protect against such attacks, link layer security MUST be used. An example of such for 802 type networks is port-based access control [34]. Prior to participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the All Nodes Multicast Group and Solicited Node Multicast Group for the address that they are claiming RFC 2461 [6]. Subscribing to a multicast group requires that the nodes use MLD [22]. MLD contains no provision for security. 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 such an attack because the router sends a Multicast-Address-Specific Query to determine whether any listeners are still on the address, at which point the victim can respond to avoid being dropped from the group. This technique will work if the router on the link has not been compromised. Other attacks using MLD are possible, but they primarily lead to extraneous (but not overwhelming) traffic. 13.2 How SEND Counters Threats to Neighbor Discovery The SEND protocol is designed to counter the threats to IPv6 Neighbor Discovery outlined in [28]. The following subsections contain a regression of the SEND protocol against the threats, to illustrate what aspects of the protocol counter each threat. 13.2.1 Neighbor Solicitation/Advertisement Spoofing This threat is defined in Section 4.1.1 of [28]. The threat is that a spoofed Neighbor Solicitation or Neighbor Advertisement causes a false entry in a node's Neighbor Cache. There are two cases: 1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. There are two cases: Arkko, et al. Expires December 4, 2003 [Page 51] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 1. A router receiving a Router Solicitation with a firm IPv6 source address and a Target Link-Layer Address extension inserts an entry for the IPv6 address into its Neighbor Cache. 2. A node doing Duplicate Address Detection (DAD) that receives a Neighbor Solicitation for the same address regards the situation as a collision and ceases to solicit for the address. 2. Entries made as a result of a Neighbor Advertisement sent as a response to a Neighbor Solicitation for purposes of on-link address resolution. 13.2.1.1 Solicitations with Effect SEND counters the threat of solicitations with effect in the following ways: 1. As discussed in Section 5, SEND nodes preferably send Router Solicitations with a firm IPv6 address and AH header, which the router can verify, so the Neighbor Cache binding is correct. If a SEND node must send a Router Solicitation with the unspecified address, the router will not update its Neighbor Cache, as per RFC 2461. 2. When SEND nodes are performing DAD, they use the tentative address as the source address on the Neighbor Solicitation packet, and include an IPv6 AH header. This allows the receiving SEND node to verify the solicitation. See Section 13.2.5, below, for discussion about replay protection and timestamps. 13.2.1.2 Address Resolution SEND counters attacks on address resolution by requiring that the responding node include an AH header with a signature on the packet, and that the node's interface identifier either be a CGA or that the node be able to produce a certificate authorizing that node to use the interface identifier. The Neighbor Solicitation and Advertisement pairs implement a challenge-response protocol, as explained in Section 8 and discussed in Section 13.2.5 below. Arkko, et al. Expires December 4, 2003 [Page 52] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 13.2.2 Neighbor Unreachability Detection Failure This attack is described in Section 4.1.2 of [28]. SEND counters this attack by requiring a node responding to Neighbor Solicitations sent as NUD probes to include an AH header and proof of authorization to use the interface identifier in the address being probed. If these prerequisites are not met, the node performing NUD discards the responses. 13.2.3 Duplicate Address Detection DoS Attack This attack is described in Section 4.1.3 of [28]. SEND counters this attack by requiring the Neighbor Advertisements sent as responses to DAD to include an AH header and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses. When a SEND node is used on a link that also connects to non-SEND nodes, the SEND node defends its addresses by sending unprotected Neighbor Solicitations with an unspecified address, as explained in Section 10. However, the SEND node ignores any unprotected Neighbor Solicitations or Advertisements that may be send by the non-SEND nodes. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating to non-SEND nodes, at the cost of a potential address collision between a SEND node and non-SEND node. The probability and effects of such an address collision are discussed in [27]. 13.2.4 Router Solicitation and Advertisement Attacks These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of [28]. SEND counters these attacks by requiring Router Advertisements to contain an AH header, and that the signature in the header be calculated using the public key of a host that can prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves it authorization by showing an attribute certificate containing the specific prefix or the indication that the router is allowed to route any prefix. A Router Advertisement without these protections is dropped as part of the IPsec processing. SEND does not protect against brute force attacks on the router, such as DoS attacks, or compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [28]. 13.2.5 Replay Attacks Arkko, et al. Expires December 4, 2003 [Page 53] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 This attack is described in Section 4.3.1 of [28]. SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by including a Nonce option in the solicitation and requiring the advertisement to include a matching option. Together with the signatures this forms a challenge-response protocol. SEND protects against attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects by including a timestamp into the AH header. A window of vulnerability for replay attacks exists until the timestamp expires. When timestamps are used, SEND nodes are 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. Since most SEND nodes are likely to use fairly coarse grained timestamps, as explained in Section 7.1.4, this may affect some nodes. 13.2.6 Neighbor Discovery DoS Attack This attack is described in Section 4.3.2 of [28]. In this attack, the attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself with performing Neighbor Solicitations for addresses that do not exist. SEND does not address this threat because it can be addressed by techniques such as rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These are all techniques involved in implementing Neighbor Discovery on the router. 13.3 Attacks against SEND Itself The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [27]. Some Denial-of-Service attacks against ND and SEND itself remain. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify using asymmetric methods. While safeguards are required to prevent an excessive use of resources, this can still render SEND non-operational. Security associations based on the use of asymmetric cryptography can be vulnerable to Denial-of-Service attacks, particularly when the attacker can guess the SPIs and destination addresses used in the security associations. In SEND this is easy, as both the SPIs and Arkko, et al. Expires December 4, 2003 [Page 54] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 the addresses (such as all nodes multicast address) are standardized. Due to the use of multicast, one packet sent by the attacker will be processed by multiple receivers. When CGA protection is used, SEND deals with these attacks using the verification process described in Section 7.1.6. In this process a simple hash verification of the CGA property of the address is performed first before performing the more expensive signature verification. When trusted roots 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 AH_RSA_Sig transform, and start selectively dropping packets if too many resources are spent. Implementations MAY also drop first 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 request a large number of delegation chains to be discovered for different roots. Routers SHOULD defend against such attacks by caching discovered information (including negative responses) and by limiting the number of different discovery processes they engage in. Attackers may also target hosts by sending a large number of unnecessary certificate chains, forcing hosts to spend useless memory and verification resources for them. Hosts defend against such attacks by limiting the amount of resources devoted to the certificate chains and their verification. Hosts SHOULD also prioritize advertisements sent as a response to their requests above multicast advertisements. Arkko, et al. Expires December 4, 2003 [Page 55] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 14. 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: o The Delegation Chain Solicitation message, described in Section 6.1. o The Delegation Chain Advertisement message, described in Section 6.2. This document defines two new Neighbor Discovery [6] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery messages: o The Trusted Root option, described in Section 6.3. o The Certificate option, described in Section 6.4. o The Nonce option, described in Section 5.3. This document defines a new reserved SPI number in the Reserved SPI range 1-255 [3]. This document defines a new IPSEC AH Transform Identifier for the IPsec DOI [4]. This identifier represents the AH_RSA_Sig transform from Section 7.1. This document defines a new name space for the Name Type field in the Trusted Root option. Future values of this field can be allocated using standards action [5]. Another new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated using standards action [5]. Arkko, et al. Expires December 4, 2003 [Page 56] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Normative References [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [4] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [7] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [8] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [10] Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [11] 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. [12] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [14] Lynn, C., "X.509 Extensions for IP Addresses and AS Identifiers", Internet-Draft (expired) Arkko, et al. Expires December 4, 2003 [Page 57] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 draft-ietf-pkix-x509-ipaddr-as-extn-00, February 2002. [15] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2003. [16] International Organization for Standardization, "The Directory - Authentication Framework", ISO Standard X.509, 2000. [17] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS 1, November 1993. [18] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, . Arkko, et al. Expires December 4, 2003 [Page 58] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Informative References [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [20] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [21] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [22] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [23] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", draft-arkko-icmpv6-ike-effects-01 (work in progress), June 2002. [24] Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), June 2002. [25] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. [26] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-04 (work in progress), March 2003. [27] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-00.txt (work in progress), May 2003. [28] Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-00 (work in progress), October 2002. [29] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and Addresses", draft-montenegro-sucv-03 (work in progress), July 2002. [30] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", Computer Communications Review, April 2001. [31] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Proceedings of the Cambridge Security Protocols Workshop, April 2001. Arkko, et al. Expires December 4, 2003 [Page 59] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 [32] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security Workshop, September 2002. [33] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses", NDSS, February 2002. [34] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. Authors' Addresses 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 Bill Sommerfeld Sun Microsystems 1 Network Drive UBUR02-212 Burlington 01803 USA EMail: sommerfeld@east.sun.com Brian Zill Microsoft USA EMail: bzill@microsoft.com Arkko, et al. Expires December 4, 2003 [Page 60] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Pekka Nikander Ericsson Jorvas 02420 Finland EMail: Pekka.Nikander@nomadiclab.com Arkko, et al. Expires December 4, 2003 [Page 61] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Appendix A. Contributors Steven Bellovin was the first to suggest the use of IPsec in this manner for the protection of Neighbor Discovery. Ran Atkinson and Brian Weis have in the past experimented with public-key based variants of AH for other purposes. Vesa-Matti Mantyla was a co-author of an unpublished draft from which many of the details of this document have been inherited. The theoretical foundations of protecting Neighbor Discovery were laid out in a paper [32] where Tuomas Aura, Vesa-Matti Mantyla, Pekka Nikander, and Mike Roe were co-authors. Arkko, et al. Expires December 4, 2003 [Page 62] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Appendix B. Acknowledgements The authors would like to thank Erik Nordmark, Gabriel Montenegro, Tuomas Aura, Pekka Savola, and Alper Yegin for interesting discussions in this problem space. Arkko, et al. Expires December 4, 2003 [Page 63] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Appendix C. IPR Considerations The optional CGA part of SEND uses public keys and hashes to prove address ownership. Several IPR claims have been made about such methods. Arkko, et al. Expires December 4, 2003 [Page 64] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Arkko, et al. Expires December 4, 2003 [Page 65] Internet-Draft SEcure Neighbor Discovery (SEND) June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arkko, et al. Expires December 4, 2003 [Page 66]