Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: March 18, 2006 G. Montenegro Microsoft September 14, 2005 Link Layer Hashed Based Addresses (LL-HBA) for Secure Neighbor Discovery (SEND) draft-laganier-send-ll-hba-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 March 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The current mechanisms used by Secure Neighbor Discovery (SEND) to secure the Neighbor Discovery Protocol (NDP) relies almost solely on public key cryptography (i.e. Certificates and/or Cryptographically Laganier & Montenegro Expires March 18, 2006 [Page 1] Internet-Draft LL-HBA for SEND September 2005 Generated Addresses). While these approaches provide very strong guarantees on the authenticity of an IP address to link layer address mapping, they are computationally expensive, which might be a problem on resource-constrained devices. It is also recognized in the SEND specification that it does not compensate for an insecure link layer; more specifically, no protections are offered against spoofing, link disruption, or bombing DoS attacks launched at the link layer. Accordingly, this note suggests an alternative to the current specification of SEND which leverage on the deemed required link layer security to secure NDP. This technique is based on the use of a specific kind of IPv6 addresses, the so-called Link Layer Hashed Based Addresses (LL-HBA), and of link layer address reachability tests. When the link layer security prevents attacker to redirect frames at the link layer layer, this technique allows to provide some level of security to NDP while relying solely on symmetric (i.e., computationally inexpensive) cryptography. Laganier & Montenegro Expires March 18, 2006 [Page 2] Internet-Draft LL-HBA for SEND September 2005 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 2. Link Layer Address Reachability Test . . . . . . . . . . . . . 5 3. Link Layer Hashed Based Addresses (LL-HBA) . . . . . . . . . . 8 3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Processing Rules for Senders . . . . . . . . . . . . . . . 11 3.3 Processing Rules for Receivers . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.1 Third Party Flooding DoS Attack . . . . . . . . . . . . . 13 4.2 Neighbor Solicitation/Advertisement Spoofing . . . . . . . 14 4.3 Neighbor Unreachability Detection Failure . . . . . . . . 14 4.4 Duplicate Address Detection DoS Attacks . . . . . . . . . 14 4.5 Router Solicitation/Advertisement Attacks . . . . . . . . 14 4.6 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 15 4.7 Neighbor Discovery DoS Attacks . . . . . . . . . . . . . . 15 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 Normative References . . . . . . . . . . . . . . . . . . . 15 7.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Laganier & Montenegro Expires March 18, 2006 [Page 3] Internet-Draft LL-HBA for SEND September 2005 1. Introduction and Problem Statement Several security issues with the IPv6 signaling protocol Neighbor Discovery [I-D.ietf-ipv6-2461bis] as well as stateless address autoconfiguration [I-D.ietf-ipv6-rfc2462bis][I-D.ietf-ipv6-privacy- addrs-v2] were identified in [RFC3756]. Other issues are identified within the specifications themselves. The Secure Neighbor Discovery Working Group has produced documents addressing these issues: The Secure Neighbor Discovery (SEND) Protocol [RFC3971] and Cryptographically Generated Addresses (CGA) [RFC3972]. At the heart of these issues is the difficulty in obtaining a security association such that any node can verify another node's authorization when issuing a given IPv6 signaling packet. Such difficulty precludes a straightforward application of IPsec between any two previously unknown nodes (either of which may be a router). The impossibility of always having the choice of obtaining such a security association by leveraging a centralized infrastructure (PKI, KDC, TTC, etc) has led to cryptographic techniques commonly known as CGA or SUCV to be applied under similar constraints to problems of securing Mobile IPv6 [SUCV][updateauth], group management for multicast and anycast [SGM], Secure Neighbor Discovery [RFC3972], etc. However, the CGA method relies heavily on public key cryptography for message generation and verification. This is potentially cumbersome for resource-constrained devices, hence the desire to have a SEND method which relies only on symmetric cryptography (e.g. hashes, HMAC). In the past, similar considerations led to the proposal of "hash- based addresses" (HBAs) [I-D.arkko-mipv6-select-hash]. An HBA is an IPv6 addresses produced by applying a hash to a particular byte string, as opposed to a CGA, in which a hash is applied to a public key. HBAs were subsequently applied to the problem of readdressing for IPv6 multihoming (multi6) [I-D.ietf-multi6-hba]. In the multi6 case, the IPv6 address is derived from a byte string based on the set of network prefixes available to the end node. This binding of a set of HBAs to a set of valid network prefixes allows the node to securely change its source address from one network prefix to another. The SEND and multi6 problems are very similar, namely, they seek to provide a secure mapping between a given address and another set of addresses: SEND needs a secure mapping from an IP address (configured on a set of network interfaces) to a set of link layer addresses (configured on the set of network interfaces using this IP address), while multi6 needs a secure mapping from an IP address (the first Laganier & Montenegro Expires March 18, 2006 [Page 4] Internet-Draft LL-HBA for SEND September 2005 address used to send/receive packets) to another set of IP addresses (the set of addresses configured on the host with distinct network prefixes, on which the stack might need to fail-over). In this document, we apply to SEND HBA and their generalization, Link Layer Hashed Based Addresses. Threats to Neighbor Discovery are particularly serious for multi- access link layers which use addresses to deliver frames or packets [RFC3756]. The local delivery depends on correctly mapping the link layer (also known as MAC) addresses with the corresponding IP addresses. These link layer addresses are usually outside the purview of the IETF. The observation is that this lack of coordination between the IP layer and the underlying link layer is precisely the weakness that makes them so easy to attack. The main idea came from the fact that SEND does not protect from an insecure link layer, in which an attacker is able to redirect or spoof frames at the link layer. Hence, we make the assumption that the link layer security prevents attacker to redirect frames at the link layer. Example of such security mechanisms might be a combination of port-based access control with physical security, 802.1x, 802.11i (shared secret between the access point and the mobile station), or 802.16 security (link layer addresses certified by vendors). Our proposal aims at establishing a (possibly cryptographic) coordination between these two layers, thus closing this gaping hole in ND security. This is a straightforward way to provide lightweight security. The advantage of this mechanism, as opposed to that suggested in [RFC3971] is its simplicity, but above all, the fact that the additional security does not incur a huge additional work load when generating and verifying messages, because it does not use public key cryptography. This point is essential for resource constrained devices, which will become arguably the majority of the node population. Accordingly, this note provides a high level overview of how the suggested techniques (link layer address reachability tests and Link Layer Hashed Based Addresses) can be applied to secure Neighbor Discovery without recourse to public key cryptographic primitives. The initial version of this document aims at generating discussion about the proposed mechanisms. Further details are deferred to further revisions of this document. 2. Link Layer Address Reachability Test To build more trust onto the weak security of Link Layer Hashed Based Address, this section defines a mandatory link layer address Laganier & Montenegro Expires March 18, 2006 [Page 5] Internet-Draft LL-HBA for SEND September 2005 reachability test, which is triggered upon reception of a Neighbor Advertisement requiring a change in the state of the Neighbor Discovery Protocol (e.g. link layer address change in a Neighbor Cache Entry, Neighbor Unreachability Detection, Duplicate Address Detection failure, etc.). This reachability test is implemented by an exchange of unicast NS and NA including a fresh Nonce. The NS must be sent to the target IP address and link layer address. The NA would then echo back the Nonce, completing the reachability test, and establishing the IP address to link layer address mapping. The distinction between a NA part of the initial ND exchange and a NA part of the subsequent reachability test is possible because the the later was sent in response to an unicast NS. When receiving an solicited or unsolicited NA modifying the state of the neighbor cache, a node MUST test the reachability of the Target link layer address by resoliciting a NA with a fresh Nonce option. It does so by sending to the source link layer address of the solicited NA a unicast Neighbor Solicitation including the Nonce option and the Target link layer address, thus including the statement made in the solicited NA (e.g. Target IP Address X is at Target link layer Address Y). The receiver of this packet MUST then reply with a Neighbor Advertisement for this IP Address X with the same Nonce and Target link layer address. Laganier & Montenegro Expires March 18, 2006 [Page 6] Internet-Draft LL-HBA for SEND September 2005 A B ----Multicast---> NS[ Target IP ] [ Source LL ] [ Nonce 1 ] <---Unicast------ NA[ Target IP ] [ Target LL ] [ Nonce 1 ] ----Unicast-----> NS[ Target IP ] [ Source LL ] [ Target LL ] [ Nonce 2 ] <---Unicast------- NA[ Target IP ] [ Target LL ] [ Nonce 2 ] Figure 1: Example of reachability test for solicited NA A R <---Multicast---- NA[ Target IP ] [ Target LL ] [ Nonce 1 ] ----Unicast-----> NS[ Target IP ] [ Source LL ] [ Target LL ] [ Nonce 2 ] <---Unicast------ NA[ Target IP ] [ Target LL ] [ Nonce 2 ] Figure 2: Example of reachability test for unsolicited NA An optimization of this reachability test is, for a node which reachability is being tested by lot of nodes sending NS, to wait for Laganier & Montenegro Expires March 18, 2006 [Page 7] Internet-Draft LL-HBA for SEND September 2005 a certain interval before replying with a NA, while recording all the Nonces it receives in the NS. Then the node can multicast to all nodes a NA including all these Nonces. A,B,C R <---Multicast---- NA[ Target IP ] [ Target LL ] [ Nonce 1 ] ----Unicast-----> NS[ Target IP ] [ Source LL ] [ Target LL ] [ Nonce 2 ] ----Unicast-----> NS[ Target IP ] [ Source LL ] [ Target LL ] [ Nonce 3 ] ----Unicast-----> NS[ Target IP ] [ Source LL ] [ Target LL ] [ Nonce 4 ] <---Multicast---- NA[ Target IP ] [ Target LL ] [ Nonce 2 ] [ Nonce 3 ] [ Nonce 4 ] Figure 3: Example of an optimized reachability test for unsolicited NA 3. Link Layer Hashed Based Addresses (LL-HBA) In this section we describe the concept of Link Layer Hashed Based Addresses (LL-HBA). The family of Link Layer Hashed Based Address consists of all the routable IPv6 address whose Interface Identifier (IID) securely embed an information about a mapping established from the IPv6 address to a Laganier & Montenegro Expires March 18, 2006 [Page 8] Internet-Draft LL-HBA for SEND September 2005 set of link layer addresses. 3.1 Definition A Link Layer Hashed Based Addresses (LL-HBA) is an IPv6 address whose IID embeds a secure mapping from the LL-HBA to a set of link layer addresses. Each node that wants its ND messages to be verifiable (and heeded) by other nodes determines the set of link layer addresses (LL@[1], ..., LL@[n]) at which it will be reachable with a common IP address. This link layer address set SHOULD contain the link layer addresses of all the interfaces of the node and its ND proxies at which it is usually reachable. Once the link layer address set is determined, the node then generates an appropriate LL-HBA by conforming to the following formulas, while the hash values are computed as described later in this section: Mask1 (64 bits) = 0x1cffffffffffffff Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0, 0xffff000000000000000000000000 if Sec=1, 0xffffffff00000000000000000000 if Sec=2, 0xffffffffffff0000000000000000 if Sec=3, 0xffffffffffffffff000000000000 if Sec=4, 0xffffffffffffffffffff00000000 if Sec=5, 0xffffffffffffffffffffffff0000 if Sec=6, and 0xffffffffffffffffffffffffffff if Sec=7 A link layer hash-based address is an IPv6 address for which the following two equations hold: Hash1 & Mask1 == interface identifier & Mask1 Hash2 & Mask2 == 0x0000000000000000000000000000 Notice that this does not mandate that all nodes generate and use LL- HBA. This is only required for those nodes that wish the packets they send to be verifiable as per the procedures defined in this document. Using an LL-HBA allows a node to prove that: (1) The IPv6 address LL-HBA is derived from the set of Link Layer Addresses LL@[1] ... LL@[n] Laganier & Montenegro Expires March 18, 2006 [Page 9] Internet-Draft LL-HBA for SEND September 2005 And consequently that: (2) The owner of LL@[1] ... LL@[n] owns the IPv6 address LL-HBA Which is indeed authorizing to establish the mapping: (3) IPv6 address LL-HBA is at one of the link layer addresses in the set LL@[1] ... LL@[n] Thus, an attacker will need to find a collision on the mapping to redirect packets to another link layer address (i.e. one which is not in the set). In order for LL-HBA to accommodate the simultaneous usage of SEND-CGA [RFC3972] and MULTI6-HBA [I-D.ietf-multi6-hba], we define, a link layer Hash-Based Address (LL-HBA) Extension to the CGA Parameters data structure allowing to generate IPV6 addresses which are, at the same time, CGAs, HBAs (for multi6 purposes), and LL-HBAs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext Type | Ext Len |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LL Type[1] | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LL Type[2] | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[2] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . ... . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LL Type[n] | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[n] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext Type: 8-bit identifier of the LL-HBA Extension (TBD IANA) Ext Len: 8-bit unsigned integer. Length of the Extension in 8-octet units, not including the first 4 octets. Laganier & Montenegro Expires March 18, 2006 [Page 10] Internet-Draft LL-HBA for SEND September 2005 P flag: Set if a public key is included in the Public Key field of the CGA Parameters Data Structure. Reset if an additional Modifier bits are included in the CGA Parameters Data Structure. LL Type[i]: The Type (e.g. 802.11) of the i^th link layer address. The length of this link layer address is inferred from this type; for example the length of an IEEE EUI-48 Identifier, which is used as address by IEEE 802.11 is 6 octets. Link Layer Address[i]: The i^th link layer Addresses, of size LL Addr Len octets. The two hash (Hash1 and Hash2) values MUST be computed as follows. The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When computing Hash1, the input to the SHA-1 algorithm is the CGA Parameters data structure. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When computing Hash2, the input is the same CGA Parameters data structure except that the subnet prefix and collision count are set to zero. The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 160-bit SHA-1 hash value. Note that the hash values are computed over the entire CGA Parameters data structure, including the link layer address extension as well as any unrecognized extension fields. 3.2 Processing Rules for Senders The senders of a Neighbor Solicitation MUST include a fresh Nonce, and store it so it can be matched against the Nonce included in an answered Neighbor Advertisement. The senders of a Neighbor Advertisement sent in reply to a Neighbor Solicitation (i.e. solicited NA) MUST include a Nonce copied from this NS. If a router decide to multicast the NA to all nodes on the link, it MUST include the Nonce in a similar manner. The senders of an unsolicited Neighbor Advertisement MAY have the ability, when it receives the multiple reachability test NS sent by on-link nodes, instead of replying with multiple unicast NA, to wait for a period of time while storing the Nonces received in NS, and then multicast a NA including all the Nonces. 3.3 Processing Rules for Receivers All received Neighbor Solicitation or Advertisement not using CGA and which do not include all of the following options MUST be treated as insecure: Laganier & Montenegro Expires March 18, 2006 [Page 11] Internet-Draft LL-HBA for SEND September 2005 Nonce CGA Parameter including a LL-HBA extension, validating the source link layer address of the frame If the node is using both CGA and LL-HBA, then the entries created as the result of LL-HBA protected NDP MUST be labeled as such, and MUST NOT overwrite an entry created by the CGA technique. The receiver MUST have the ability to correctly parse multiple Nonce options in any order. The receiver of a solicited NA MUST verify that it has recently sent a matching NS, and that the NA include the same Nonce as the one sent in the NS. If the destination link layer address of the matching NS was a multicast address, then the NA MUST be discarded, and the target IP address MUST be resolicited by sending to the source link layer address of the NA frame a unicast NS including a fresh Nonce, as specified in Section 3.2. This round trip exchange implements the link layer address reachability test described in Section 2. The receiver of an unsolicited NA MUST discard it and resolicit the target IP address by sending to the source link layer address of the frame a unicast NS including a fresh Nonce, as specified in Section 3.2. This round trip exchange implements the link layer address reachability test described in Section 2. 4. Security Considerations This document discusses security issues specifically involved with the use of LL-HBA within the SEND protocol. Some of the mechanisms already adopted as part of the SEND solution impose a heavy load on processing nodes due to the use of public key cryptography. The SEND solutions relies on the use of CGA, and public key cryptography to provide proof-of-ownership of an identifier (the CGA) for which a binding needs to be established. The LL-HBA solution hereby proposed lowers the overall security level of SEND with CGA because it provides only a proof-of-binding between an identifier (the IPv6 LL-HBA) and the set of identifiers it is bound to (the set of link layer addresses used as carriers for this LL-HBA), instead of the CGA proof-of-ownership. This is similar in essence to an authorization to act as a link layer address, issued by the LL-HBA to one or multiple link layer addresses. In spite of this, we believe than for certain scenarios, Neighbor Discovery security might be provided by weaker and cheaper Laganier & Montenegro Expires March 18, 2006 [Page 12] Internet-Draft LL-HBA for SEND September 2005 cryptographic primitives without diminishing notably its security level. The idea exposed in this document stems from the observation that SEND does not protect from an attacker able to disrupt the link layer service (by, e.g., causing an address collision at the link layer, succeeds in preventing frames sent to a given link layer Address to be delivered to their legitimate recipient). On the other hand, if one make the assumption that a combination of physical and link layer security prevents the attacks above, thus making it hard for an attacker to: 1. Collide with another node link layer Address 2. Get packets sent to a link layer Address to be dropped 3. Get packets sent to a link layer Address redirected to another LL Address Then combining LL-HBA and link layer reachability tests gives a solution almost as secure and robust than SEND. To avoid redirections towards a link layer address which is not reachable on the link, a node SHOULD use a given link layer address as input to the LL-HBA generation if and only if it can ensure is always reachable at this link layer address on the same prefix as the LL-HBA. These multiple LL addresses might be those of multiple Network Interfaces, and possibly those of a Neighbor Discovery Proxy or a Mobile IPv6 Home Agent handling ND messages on a remote link on behalf of the node. The following sub-sections analyse the security-related differences between our LL-HBA proposal and the original SEND [RFC3971], in light of the threats outlined in [RFC3756]. 4.1 Third Party Flooding DoS Attack This threat is defined in section 9.1 of [RFC3971] and is not countered by SEND. The threat is that because the link layer address address is not cryptographically bound to the IP address, nothing prevents an on-link attacker to spoof its victim link layer address and send valid neighbor advertisement with a fabricated CGA, a valid signature, while the target link layer address is the victim's one. Such attacker would then cause a traffic stream to flood the victim in a DoS attack, preventing it to receive valid data. LL-HBA does not counter this threat. The reachability test requires a successful attacker to be able to send frames spoofing its victim link layer address. Laganier & Montenegro Expires March 18, 2006 [Page 13] Internet-Draft LL-HBA for SEND September 2005 4.2 Neighbor Solicitation/Advertisement Spoofing This threat is defined in section 4.1.1 of [RFC3756], and SEND counters it as described in section 9.2.1 of [RFC3971]. The threat is that a spoofed message may cause a false entry in the Neighbor Cache of a node. LL-HBA counters this threat by requiring the Target link layer address to be reachable and in the link layer address set of entry to be updated. Hence, nobody can prevent packets to be delivered to the correct host because the binding will be established towards a valid link layer address. 4.3 Neighbor Unreachability Detection Failure This threat is defined in section 4.1.2 of [RFC3756], and SEND counters it as described in section 9.2.2 of [RFC3971]. The threat is that spoofed or replayed messages may prevent a node from detecting unreachability of one of its neighbor. LL-HBA does not counter this threat. The reachability test requires a successful attacker to be able to snoop frames sent to its victim link layer address, and to send frames spoofing its victim link layer address. 4.4 Duplicate Address Detection DoS Attacks This threat is defined in section 4.1.3 of [RFC3756], and SEND counters it as described in section 9.2.3 of [RFC3971]. The threat is that an attacker sending fabricated NA/NS messages to a node performing DAD may prevent it from acquiring any stateless autoconfigured address [I-D.ietf-ipv6-rfc2462bis] [I-D.ietf-ipv6- privacy-addrs-v2]. This is a DoS attack. LL-HBA and reachability tests counter this threat by requiring a valid LL-HBA to be bound to a given set of reachable link layer addresses. We made the assumption that an attacker cannot create a collision with, or redirect frames sent to its victim link layer address. Hence, an attacker which claims that a collision occurs at the IP layer with its LL-HBA, is using the same link layer address set and the same set of parameters. This will cause the reachability test triggered onto these link layer addresses to fail if the attacker is unaware of the Nonce sent in the reachability test NS. On the other hand the reachability test provides no protection against an attacker able to snoop frames sent to its victim link layer address and to send frames spoofing its victim link layer address. 4.5 Router Solicitation/Advertisement Attacks These threats are defined in sections 4.2.1, 4.2.4, 4.2.5, 4.2.6 and 4.2.7 of [RFC3756], and SEND counters them as described in section 9.2.4 of [RFC3971]. The threat is that an attacker sending fabricated RA/RS messages may siphon off all the traffic sent to a Laganier & Montenegro Expires March 18, 2006 [Page 14] Internet-Draft LL-HBA for SEND September 2005 set of network prefixes. LL-HBA does not protect against this. Note that SEND's protection against these attacks is not based on CGAs but rather on authorization certificates issued by a trust anchor for routing delivery. Therefore, it implies that nodes on a LAN have been provisioned with the anchor public key. 4.6 Replay Attacks This threat is defined in section 4.3.1 of [RFC3756], and SEND counters it as described in section 9.2.5 of [RFC3971]. As explained before, LL-HBA does not protect protect against replay attacks, and the reachability test requires from the attacker the ability to snoop frames sent to its victim link layer address and to send frames spoofing its victim link layer address. Under such conditions, any node might replay the packets, misleading Neighbor Unreachability Detection to incorrectly assume liveness for the original sender of the packets. 4.7 Neighbor Discovery DoS Attacks This threat is defined in section 4.3.2 of [RFC3756], and SEND does not address it, as explained in section 9.2.6 of [RFC3971]. LL-HBA is consistent with respect to this. 5. Conclusion This note presents a high level overview of how a combination of the LL-HBA technique with reachability tests can be used to secure Neighbor Discovery. The proposal works in the absence of any previously established direct or indirect (via a broker, AAA roaming operator or trusted third party) security relationship, and does not impose heavy computation on networked nodes. Because of this, these methods are very practical and deployable. 6. Acknowledgements Thanks to Erik Nordmark and Marcelo Bagnulo for their useful comments and discussion. 7. References 7.1 Normative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-04 (work in progress), July 2005. [I-D.ietf-ipv6-rfc2462bis] Laganier & Montenegro Expires March 18, 2006 [Page 15] Internet-Draft LL-HBA for SEND September 2005 Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06 (work in progress), October 2004. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 7.2 Informative References [I-D.arkko-mipv6-select-hash] Arkko, J., Nikander, P., and G. Montenegro, "Selection of MIPv6 Security Level Using a Hashed Address", draft-arkko-mipv6-select-hash-00 (work in progress), June 2002. [I-D.ietf-ipv6-privacy-addrs-v2] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", draft-ietf-ipv6-privacy-addrs-v2 (work in progress), October 2004. [I-D.ietf-multi6-hba] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-multi6-hba-00 (work in progress), December 2004. [I-D.thaler-ipv6-ndproxy] Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-03 (work in progress), October 2004. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Laganier & Montenegro Expires March 18, 2006 [Page 16] Internet-Draft LL-HBA for SEND September 2005 [SGM] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", 8th IEEE Symposium on Computers and Communications (ISCC 2003), , July 2003. [SUCV] Montenegro, G. and C. Castelluccia, "Crypto-based IDs (CBIDs): Concepts and Applications", ACM Transactions on Information and System Security (TISSEC) Volume 7, Number 1, February 2004. [updateauth] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth (work in progress), February 2002. Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond WA 98052 USA Email: gabriel_montenegro_2000@yahoo.com Laganier & Montenegro Expires March 18, 2006 [Page 17] Internet-Draft LL-HBA for SEND September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Laganier & Montenegro Expires March 18, 2006 [Page 18]