idnits 2.17.1 draft-laganier-send-ll-hba-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...or cache, a node MUST test the reachab...' RFC 2119 keyword, line 211: '... The receiver of this packet MUST then...' RFC 2119 keyword, line 320: '...ayer address set SHOULD contain the li...' RFC 2119 keyword, line 415: '...nd Hash2) values MUST be computed as f...' RFC 2119 keyword, line 429: '...bor Solicitation MUST include a fresh ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 338 has weird spacing: '...fffffff if Se...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 14, 2005) is 6797 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 382 -- Looks like a reference, but probably isn't: '2' on line 386 == Unused Reference: 'RFC3513' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-privacy-addrs-v2' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-ipv6-ndproxy' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-ipv6-rfc2462bis-06 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: March 18, 2006 G. Montenegro 5 Microsoft 6 September 14, 2005 8 Link Layer Hashed Based Addresses (LL-HBA) for Secure Neighbor Discovery 9 (SEND) 10 draft-laganier-send-ll-hba-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document may not be modified, and derivative works of it may not 19 be created, except to publish it as an RFC and to translate it into 20 languages other than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 18, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The current mechanisms used by Secure Neighbor Discovery (SEND) to 47 secure the Neighbor Discovery Protocol (NDP) relies almost solely on 48 public key cryptography (i.e. Certificates and/or Cryptographically 49 Generated Addresses). While these approaches provide very strong 50 guarantees on the authenticity of an IP address to link layer address 51 mapping, they are computationally expensive, which might be a problem 52 on resource-constrained devices. 54 It is also recognized in the SEND specification that it does not 55 compensate for an insecure link layer; more specifically, no 56 protections are offered against spoofing, link disruption, or bombing 57 DoS attacks launched at the link layer. Accordingly, this note 58 suggests an alternative to the current specification of SEND which 59 leverage on the deemed required link layer security to secure NDP. 60 This technique is based on the use of a specific kind of IPv6 61 addresses, the so-called Link Layer Hashed Based Addresses (LL-HBA), 62 and of link layer address reachability tests. 64 When the link layer security prevents attacker to redirect frames at 65 the link layer layer, this technique allows to provide some level of 66 security to NDP while relying solely on symmetric (i.e., 67 computationally inexpensive) cryptography. 69 Table of Contents 71 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 72 2. Link Layer Address Reachability Test . . . . . . . . . . . . . 5 73 3. Link Layer Hashed Based Addresses (LL-HBA) . . . . . . . . . . 8 74 3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2 Processing Rules for Senders . . . . . . . . . . . . . . . 11 76 3.3 Processing Rules for Receivers . . . . . . . . . . . . . . 11 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 4.1 Third Party Flooding DoS Attack . . . . . . . . . . . . . 13 79 4.2 Neighbor Solicitation/Advertisement Spoofing . . . . . . . 14 80 4.3 Neighbor Unreachability Detection Failure . . . . . . . . 14 81 4.4 Duplicate Address Detection DoS Attacks . . . . . . . . . 14 82 4.5 Router Solicitation/Advertisement Attacks . . . . . . . . 14 83 4.6 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 15 84 4.7 Neighbor Discovery DoS Attacks . . . . . . . . . . . . . . 15 85 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.1 Normative References . . . . . . . . . . . . . . . . . . . 15 89 7.2 Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 91 Intellectual Property and Copyright Statements . . . . . . . . 18 93 1. Introduction and Problem Statement 95 Several security issues with the IPv6 signaling protocol Neighbor 96 Discovery [I-D.ietf-ipv6-2461bis] as well as stateless address 97 autoconfiguration [I-D.ietf-ipv6-rfc2462bis][I-D.ietf-ipv6-privacy- 98 addrs-v2] were identified in [RFC3756]. Other issues are identified 99 within the specifications themselves. The Secure Neighbor Discovery 100 Working Group has produced documents addressing these issues: The 101 Secure Neighbor Discovery (SEND) Protocol [RFC3971] and 102 Cryptographically Generated Addresses (CGA) [RFC3972]. 104 At the heart of these issues is the difficulty in obtaining a 105 security association such that any node can verify another node's 106 authorization when issuing a given IPv6 signaling packet. Such 107 difficulty precludes a straightforward application of IPsec between 108 any two previously unknown nodes (either of which may be a router). 109 The impossibility of always having the choice of obtaining such a 110 security association by leveraging a centralized infrastructure (PKI, 111 KDC, TTC, etc) has led to cryptographic techniques commonly known as 112 CGA or SUCV to be applied under similar constraints to problems of 113 securing Mobile IPv6 [SUCV][updateauth], group management for 114 multicast and anycast [SGM], Secure Neighbor Discovery [RFC3972], 115 etc. 117 However, the CGA method relies heavily on public key cryptography for 118 message generation and verification. This is potentially cumbersome 119 for resource-constrained devices, hence the desire to have a SEND 120 method which relies only on symmetric cryptography (e.g. hashes, 121 HMAC). 123 In the past, similar considerations led to the proposal of "hash- 124 based addresses" (HBAs) [I-D.arkko-mipv6-select-hash]. An HBA is an 125 IPv6 addresses produced by applying a hash to a particular byte 126 string, as opposed to a CGA, in which a hash is applied to a public 127 key. HBAs were subsequently applied to the problem of readdressing 128 for IPv6 multihoming (multi6) [I-D.ietf-multi6-hba]. In the multi6 129 case, the IPv6 address is derived from a byte string based on the set 130 of network prefixes available to the end node. This binding of a set 131 of HBAs to a set of valid network prefixes allows the node to 132 securely change its source address from one network prefix to 133 another. 135 The SEND and multi6 problems are very similar, namely, they seek to 136 provide a secure mapping between a given address and another set of 137 addresses: SEND needs a secure mapping from an IP address (configured 138 on a set of network interfaces) to a set of link layer addresses 139 (configured on the set of network interfaces using this IP address), 140 while multi6 needs a secure mapping from an IP address (the first 141 address used to send/receive packets) to another set of IP addresses 142 (the set of addresses configured on the host with distinct network 143 prefixes, on which the stack might need to fail-over). In this 144 document, we apply to SEND HBA and their generalization, Link Layer 145 Hashed Based Addresses. 147 Threats to Neighbor Discovery are particularly serious for multi- 148 access link layers which use addresses to deliver frames or packets 149 [RFC3756]. The local delivery depends on correctly mapping the link 150 layer (also known as MAC) addresses with the corresponding IP 151 addresses. These link layer addresses are usually outside the 152 purview of the IETF. The observation is that this lack of 153 coordination between the IP layer and the underlying link layer is 154 precisely the weakness that makes them so easy to attack. 156 The main idea came from the fact that SEND does not protect from an 157 insecure link layer, in which an attacker is able to redirect or 158 spoof frames at the link layer. Hence, we make the assumption that 159 the link layer security prevents attacker to redirect frames at the 160 link layer. Example of such security mechanisms might be a 161 combination of port-based access control with physical security, 162 802.1x, 802.11i (shared secret between the access point and the 163 mobile station), or 802.16 security (link layer addresses certified 164 by vendors). 166 Our proposal aims at establishing a (possibly cryptographic) 167 coordination between these two layers, thus closing this gaping hole 168 in ND security. This is a straightforward way to provide lightweight 169 security. The advantage of this mechanism, as opposed to that 170 suggested in [RFC3971] is its simplicity, but above all, the fact 171 that the additional security does not incur a huge additional work 172 load when generating and verifying messages, because it does not use 173 public key cryptography. This point is essential for resource 174 constrained devices, which will become arguably the majority of the 175 node population. 177 Accordingly, this note provides a high level overview of how the 178 suggested techniques (link layer address reachability tests and Link 179 Layer Hashed Based Addresses) can be applied to secure Neighbor 180 Discovery without recourse to public key cryptographic primitives. 181 The initial version of this document aims at generating discussion 182 about the proposed mechanisms. Further details are deferred to 183 further revisions of this document. 185 2. Link Layer Address Reachability Test 187 To build more trust onto the weak security of Link Layer Hashed Based 188 Address, this section defines a mandatory link layer address 189 reachability test, which is triggered upon reception of a Neighbor 190 Advertisement requiring a change in the state of the Neighbor 191 Discovery Protocol (e.g. link layer address change in a Neighbor 192 Cache Entry, Neighbor Unreachability Detection, Duplicate Address 193 Detection failure, etc.). 195 This reachability test is implemented by an exchange of unicast NS 196 and NA including a fresh Nonce. The NS must be sent to the target IP 197 address and link layer address. The NA would then echo back the 198 Nonce, completing the reachability test, and establishing the IP 199 address to link layer address mapping. The distinction between a NA 200 part of the initial ND exchange and a NA part of the subsequent 201 reachability test is possible because the the later was sent in 202 response to an unicast NS. 204 When receiving an solicited or unsolicited NA modifying the state of 205 the neighbor cache, a node MUST test the reachability of the Target 206 link layer address by resoliciting a NA with a fresh Nonce option. 207 It does so by sending to the source link layer address of the 208 solicited NA a unicast Neighbor Solicitation including the Nonce 209 option and the Target link layer address, thus including the 210 statement made in the solicited NA (e.g. Target IP Address X is at 211 Target link layer Address Y). The receiver of this packet MUST then 212 reply with a Neighbor Advertisement for this IP Address X with the 213 same Nonce and Target link layer address. 215 A B 217 ----Multicast---> 218 NS[ Target IP ] 219 [ Source LL ] 220 [ Nonce 1 ] 222 <---Unicast------ 223 NA[ Target IP ] 224 [ Target LL ] 225 [ Nonce 1 ] 227 ----Unicast-----> 228 NS[ Target IP ] 229 [ Source LL ] 230 [ Target LL ] 231 [ Nonce 2 ] 233 <---Unicast------- 234 NA[ Target IP ] 235 [ Target LL ] 236 [ Nonce 2 ] 238 Figure 1: Example of reachability test for solicited NA 240 A R 242 <---Multicast---- 243 NA[ Target IP ] 244 [ Target LL ] 245 [ Nonce 1 ] 247 ----Unicast-----> 248 NS[ Target IP ] 249 [ Source LL ] 250 [ Target LL ] 251 [ Nonce 2 ] 253 <---Unicast------ 254 NA[ Target IP ] 255 [ Target LL ] 256 [ Nonce 2 ] 258 Figure 2: Example of reachability test for unsolicited NA 260 An optimization of this reachability test is, for a node which 261 reachability is being tested by lot of nodes sending NS, to wait for 262 a certain interval before replying with a NA, while recording all the 263 Nonces it receives in the NS. Then the node can multicast to all 264 nodes a NA including all these Nonces. 266 A,B,C R 268 <---Multicast---- 269 NA[ Target IP ] 270 [ Target LL ] 271 [ Nonce 1 ] 273 ----Unicast-----> 274 NS[ Target IP ] 275 [ Source LL ] 276 [ Target LL ] 277 [ Nonce 2 ] 279 ----Unicast-----> 280 NS[ Target IP ] 281 [ Source LL ] 282 [ Target LL ] 283 [ Nonce 3 ] 285 ----Unicast-----> 286 NS[ Target IP ] 287 [ Source LL ] 288 [ Target LL ] 289 [ Nonce 4 ] 291 <---Multicast---- 292 NA[ Target IP ] 293 [ Target LL ] 294 [ Nonce 2 ] 295 [ Nonce 3 ] 296 [ Nonce 4 ] 298 Figure 3: Example of an optimized reachability test for unsolicited 299 NA 301 3. Link Layer Hashed Based Addresses (LL-HBA) 303 In this section we describe the concept of Link Layer Hashed Based 304 Addresses (LL-HBA). 306 The family of Link Layer Hashed Based Address consists of all the 307 routable IPv6 address whose Interface Identifier (IID) securely embed 308 an information about a mapping established from the IPv6 address to a 309 set of link layer addresses. 311 3.1 Definition 313 A Link Layer Hashed Based Addresses (LL-HBA) is an IPv6 address whose 314 IID embeds a secure mapping from the LL-HBA to a set of link layer 315 addresses. 317 Each node that wants its ND messages to be verifiable (and heeded) by 318 other nodes determines the set of link layer addresses (LL@[1], ..., 319 LL@[n]) at which it will be reachable with a common IP address. This 320 link layer address set SHOULD contain the link layer addresses of all 321 the interfaces of the node and its ND proxies at which it is usually 322 reachable. 324 Once the link layer address set is determined, the node then 325 generates an appropriate LL-HBA by conforming to the following 326 formulas, while the hash values are computed as described later in 327 this section: 329 Mask1 (64 bits) = 0x1cffffffffffffff 331 Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0, 332 0xffff000000000000000000000000 if Sec=1, 333 0xffffffff00000000000000000000 if Sec=2, 334 0xffffffffffff0000000000000000 if Sec=3, 335 0xffffffffffffffff000000000000 if Sec=4, 336 0xffffffffffffffffffff00000000 if Sec=5, 337 0xffffffffffffffffffffffff0000 if Sec=6, and 338 0xffffffffffffffffffffffffffff if Sec=7 340 A link layer hash-based address is an IPv6 address for which the 341 following two equations hold: 343 Hash1 & Mask1 == interface identifier & Mask1 345 Hash2 & Mask2 == 0x0000000000000000000000000000 347 Notice that this does not mandate that all nodes generate and use LL- 348 HBA. This is only required for those nodes that wish the packets 349 they send to be verifiable as per the procedures defined in this 350 document. 352 Using an LL-HBA allows a node to prove that: 354 (1) The IPv6 address LL-HBA is derived from the set of Link Layer 355 Addresses LL@[1] ... LL@[n] 357 And consequently that: 359 (2) The owner of LL@[1] ... LL@[n] owns the IPv6 address LL-HBA 361 Which is indeed authorizing to establish the mapping: 363 (3) IPv6 address LL-HBA is at one of the link layer addresses in 364 the set LL@[1] ... LL@[n] 366 Thus, an attacker will need to find a collision on the mapping to 367 redirect packets to another link layer address (i.e. one which is not 368 in the set). 370 In order for LL-HBA to accommodate the simultaneous usage of SEND-CGA 371 [RFC3972] and MULTI6-HBA [I-D.ietf-multi6-hba], we define, a link 372 layer Hash-Based Address (LL-HBA) Extension to the CGA Parameters 373 data structure allowing to generate IPV6 addresses which are, at the 374 same time, CGAs, HBAs (for multi6 purposes), and LL-HBAs. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Ext Type | Ext Len |P| Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | LL Type[1] | Reserved | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[1] + 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | LL Type[2] | Reserved | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[2] + 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 . . 390 . ... . 391 . . 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | LL Type[n] | Reserved | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[n] + 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Ext Type: 8-bit identifier of the LL-HBA Extension (TBD IANA) 400 Ext Len: 8-bit unsigned integer. Length of the Extension in 8-octet 401 units, not including the first 4 octets. 403 P flag: Set if a public key is included in the Public Key field of 404 the CGA Parameters Data Structure. Reset if an additional Modifier 405 bits are included in the CGA Parameters Data Structure. 407 LL Type[i]: The Type (e.g. 802.11) of the i^th link layer address. 408 The length of this link layer address is inferred from this type; for 409 example the length of an IEEE EUI-48 Identifier, which is used as 410 address by IEEE 802.11 is 6 octets. 412 Link Layer Address[i]: The i^th link layer Addresses, of size LL Addr 413 Len octets. 415 The two hash (Hash1 and Hash2) values MUST be computed as follows. 416 The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA 417 Parameters. When computing Hash1, the input to the SHA-1 algorithm 418 is the CGA Parameters data structure. The 64-bit Hash1 is obtained 419 by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When 420 computing Hash2, the input is the same CGA Parameters data structure 421 except that the subnet prefix and collision count are set to zero. 422 The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 423 160-bit SHA-1 hash value. Note that the hash values are computed 424 over the entire CGA Parameters data structure, including the link 425 layer address extension as well as any unrecognized extension fields. 427 3.2 Processing Rules for Senders 429 The senders of a Neighbor Solicitation MUST include a fresh Nonce, 430 and store it so it can be matched against the Nonce included in an 431 answered Neighbor Advertisement. 433 The senders of a Neighbor Advertisement sent in reply to a Neighbor 434 Solicitation (i.e. solicited NA) MUST include a Nonce copied from 435 this NS. If a router decide to multicast the NA to all nodes on the 436 link, it MUST include the Nonce in a similar manner. 438 The senders of an unsolicited Neighbor Advertisement MAY have the 439 ability, when it receives the multiple reachability test NS sent by 440 on-link nodes, instead of replying with multiple unicast NA, to wait 441 for a period of time while storing the Nonces received in NS, and 442 then multicast a NA including all the Nonces. 444 3.3 Processing Rules for Receivers 446 All received Neighbor Solicitation or Advertisement not using CGA and 447 which do not include all of the following options MUST be treated as 448 insecure: 450 Nonce 452 CGA Parameter including a LL-HBA extension, validating the source 453 link layer address of the frame 455 If the node is using both CGA and LL-HBA, then the entries created as 456 the result of LL-HBA protected NDP MUST be labeled as such, and MUST 457 NOT overwrite an entry created by the CGA technique. 459 The receiver MUST have the ability to correctly parse multiple Nonce 460 options in any order. 462 The receiver of a solicited NA MUST verify that it has recently sent 463 a matching NS, and that the NA include the same Nonce as the one sent 464 in the NS. If the destination link layer address of the matching NS 465 was a multicast address, then the NA MUST be discarded, and the 466 target IP address MUST be resolicited by sending to the source link 467 layer address of the NA frame a unicast NS including a fresh Nonce, 468 as specified in Section 3.2. This round trip exchange implements the 469 link layer address reachability test described in Section 2. 471 The receiver of an unsolicited NA MUST discard it and resolicit the 472 target IP address by sending to the source link layer address of the 473 frame a unicast NS including a fresh Nonce, as specified in 474 Section 3.2. This round trip exchange implements the link layer 475 address reachability test described in Section 2. 477 4. Security Considerations 479 This document discusses security issues specifically involved with 480 the use of LL-HBA within the SEND protocol. 482 Some of the mechanisms already adopted as part of the SEND solution 483 impose a heavy load on processing nodes due to the use of public key 484 cryptography. The SEND solutions relies on the use of CGA, and 485 public key cryptography to provide proof-of-ownership of an 486 identifier (the CGA) for which a binding needs to be established. 488 The LL-HBA solution hereby proposed lowers the overall security level 489 of SEND with CGA because it provides only a proof-of-binding between 490 an identifier (the IPv6 LL-HBA) and the set of identifiers it is 491 bound to (the set of link layer addresses used as carriers for this 492 LL-HBA), instead of the CGA proof-of-ownership. This is similar in 493 essence to an authorization to act as a link layer address, issued by 494 the LL-HBA to one or multiple link layer addresses. 496 In spite of this, we believe than for certain scenarios, Neighbor 497 Discovery security might be provided by weaker and cheaper 498 cryptographic primitives without diminishing notably its security 499 level. The idea exposed in this document stems from the observation 500 that SEND does not protect from an attacker able to disrupt the link 501 layer service (by, e.g., causing an address collision at the link 502 layer, succeeds in preventing frames sent to a given link layer 503 Address to be delivered to their legitimate recipient). 505 On the other hand, if one make the assumption that a combination of 506 physical and link layer security prevents the attacks above, thus 507 making it hard for an attacker to: 509 1. Collide with another node link layer Address 511 2. Get packets sent to a link layer Address to be dropped 513 3. Get packets sent to a link layer Address redirected to another LL 514 Address 516 Then combining LL-HBA and link layer reachability tests gives a 517 solution almost as secure and robust than SEND. 519 To avoid redirections towards a link layer address which is not 520 reachable on the link, a node SHOULD use a given link layer address 521 as input to the LL-HBA generation if and only if it can ensure is 522 always reachable at this link layer address on the same prefix as the 523 LL-HBA. These multiple LL addresses might be those of multiple 524 Network Interfaces, and possibly those of a Neighbor Discovery Proxy 525 or a Mobile IPv6 Home Agent handling ND messages on a remote link on 526 behalf of the node. 528 The following sub-sections analyse the security-related differences 529 between our LL-HBA proposal and the original SEND [RFC3971], in light 530 of the threats outlined in [RFC3756]. 532 4.1 Third Party Flooding DoS Attack 534 This threat is defined in section 9.1 of [RFC3971] and is not 535 countered by SEND. The threat is that because the link layer address 536 address is not cryptographically bound to the IP address, nothing 537 prevents an on-link attacker to spoof its victim link layer address 538 and send valid neighbor advertisement with a fabricated CGA, a valid 539 signature, while the target link layer address is the victim's one. 540 Such attacker would then cause a traffic stream to flood the victim 541 in a DoS attack, preventing it to receive valid data. LL-HBA does 542 not counter this threat. The reachability test requires a successful 543 attacker to be able to send frames spoofing its victim link layer 544 address. 546 4.2 Neighbor Solicitation/Advertisement Spoofing 548 This threat is defined in section 4.1.1 of [RFC3756], and SEND 549 counters it as described in section 9.2.1 of [RFC3971]. The threat 550 is that a spoofed message may cause a false entry in the Neighbor 551 Cache of a node. LL-HBA counters this threat by requiring the Target 552 link layer address to be reachable and in the link layer address set 553 of entry to be updated. Hence, nobody can prevent packets to be 554 delivered to the correct host because the binding will be established 555 towards a valid link layer address. 557 4.3 Neighbor Unreachability Detection Failure 559 This threat is defined in section 4.1.2 of [RFC3756], and SEND 560 counters it as described in section 9.2.2 of [RFC3971]. The threat 561 is that spoofed or replayed messages may prevent a node from 562 detecting unreachability of one of its neighbor. LL-HBA does not 563 counter this threat. The reachability test requires a successful 564 attacker to be able to snoop frames sent to its victim link layer 565 address, and to send frames spoofing its victim link layer address. 567 4.4 Duplicate Address Detection DoS Attacks 569 This threat is defined in section 4.1.3 of [RFC3756], and SEND 570 counters it as described in section 9.2.3 of [RFC3971]. The threat 571 is that an attacker sending fabricated NA/NS messages to a node 572 performing DAD may prevent it from acquiring any stateless 573 autoconfigured address [I-D.ietf-ipv6-rfc2462bis] [I-D.ietf-ipv6- 574 privacy-addrs-v2]. This is a DoS attack. LL-HBA and reachability 575 tests counter this threat by requiring a valid LL-HBA to be bound to 576 a given set of reachable link layer addresses. We made the 577 assumption that an attacker cannot create a collision with, or 578 redirect frames sent to its victim link layer address. Hence, an 579 attacker which claims that a collision occurs at the IP layer with 580 its LL-HBA, is using the same link layer address set and the same set 581 of parameters. This will cause the reachability test triggered onto 582 these link layer addresses to fail if the attacker is unaware of the 583 Nonce sent in the reachability test NS. On the other hand the 584 reachability test provides no protection against an attacker able to 585 snoop frames sent to its victim link layer address and to send frames 586 spoofing its victim link layer address. 588 4.5 Router Solicitation/Advertisement Attacks 590 These threats are defined in sections 4.2.1, 4.2.4, 4.2.5, 4.2.6 and 591 4.2.7 of [RFC3756], and SEND counters them as described in section 592 9.2.4 of [RFC3971]. The threat is that an attacker sending 593 fabricated RA/RS messages may siphon off all the traffic sent to a 594 set of network prefixes. LL-HBA does not protect against this. Note 595 that SEND's protection against these attacks is not based on CGAs but 596 rather on authorization certificates issued by a trust anchor for 597 routing delivery. Therefore, it implies that nodes on a LAN have 598 been provisioned with the anchor public key. 600 4.6 Replay Attacks 602 This threat is defined in section 4.3.1 of [RFC3756], and SEND 603 counters it as described in section 9.2.5 of [RFC3971]. As explained 604 before, LL-HBA does not protect protect against replay attacks, and 605 the reachability test requires from the attacker the ability to snoop 606 frames sent to its victim link layer address and to send frames 607 spoofing its victim link layer address. Under such conditions, any 608 node might replay the packets, misleading Neighbor Unreachability 609 Detection to incorrectly assume liveness for the original sender of 610 the packets. 612 4.7 Neighbor Discovery DoS Attacks 614 This threat is defined in section 4.3.2 of [RFC3756], and SEND does 615 not address it, as explained in section 9.2.6 of [RFC3971]. LL-HBA 616 is consistent with respect to this. 618 5. Conclusion 620 This note presents a high level overview of how a combination of the 621 LL-HBA technique with reachability tests can be used to secure 622 Neighbor Discovery. The proposal works in the absence of any 623 previously established direct or indirect (via a broker, AAA roaming 624 operator or trusted third party) security relationship, and does not 625 impose heavy computation on networked nodes. Because of this, these 626 methods are very practical and deployable. 628 6. Acknowledgements 630 Thanks to Erik Nordmark and Marcelo Bagnulo for their useful comments 631 and discussion. 633 7. References 635 7.1 Normative References 637 [I-D.ietf-ipv6-2461bis] 638 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 639 draft-ietf-ipv6-2461bis-04 (work in progress), July 2005. 641 [I-D.ietf-ipv6-rfc2462bis] 642 Thomson, S. and T. Narten, "IPv6 Stateless Address 643 Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06 (work in 644 progress), October 2004. 646 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 647 (IPv6) Addressing Architecture", RFC 3513, April 2003. 649 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 650 Neighbor Discovery (SEND)", RFC 3971, March 2005. 652 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 653 RFC 3972, March 2005. 655 7.2 Informative References 657 [I-D.arkko-mipv6-select-hash] 658 Arkko, J., Nikander, P., and G. Montenegro, "Selection of 659 MIPv6 Security Level Using a Hashed Address", 660 draft-arkko-mipv6-select-hash-00 (work in progress), 661 June 2002. 663 [I-D.ietf-ipv6-privacy-addrs-v2] 664 Narten, T. and R. Draves, "Privacy Extensions for 665 Stateless Address Autoconfiguration in IPv6", 666 draft-ietf-ipv6-privacy-addrs-v2 (work in progress), 667 October 2004. 669 [I-D.ietf-multi6-hba] 670 Bagnulo, M., "Hash Based Addresses (HBA)", 671 draft-ietf-multi6-hba-00 (work in progress), 672 December 2004. 674 [I-D.thaler-ipv6-ndproxy] 675 Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery 676 Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-03 (work in 677 progress), October 2004. 679 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 680 Stateless Address Autoconfiguration in IPv6", RFC 3041, 681 January 2001. 683 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 684 Discovery (ND) Trust Models and Threats", RFC 3756, 685 May 2004. 687 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 688 in IPv6", RFC 3775, June 2004. 690 [SGM] Castelluccia, C. and G. Montenegro, "Securing Group 691 Management in IPv6 with Cryptographically Generated 692 Addresses", 8th IEEE Symposium on Computers and 693 Communications (ISCC 2003), , July 2003. 695 [SUCV] Montenegro, G. and C. Castelluccia, "Crypto-based IDs 696 (CBIDs): Concepts and Applications", ACM Transactions on 697 Information and System Security (TISSEC) Volume 7, Number 698 1, February 2004. 700 [updateauth] 701 Roe, M., Aura, T., O'Shea, G., and J. Arkko, 702 "Authentication of Mobile IPv6 Binding Updates and 703 Acknowledgments", draft-roe-mobileip-updateauth (work in 704 progress), February 2002. 706 Authors' Addresses 708 Julien Laganier 709 DoCoMo Communications Laboratories Europe GmbH 710 Landsberger Strasse 312 711 Munich 80687 712 Germany 714 Phone: +49 89 56824 231 715 Email: julien.ietf@laposte.net 716 URI: http://www.docomolab-euro.com/ 718 Gabriel Montenegro 719 Microsoft Corporation 720 One Microsoft Way 721 Redmond WA 98052 722 USA 724 Email: gabriel_montenegro_2000@yahoo.com 726 Intellectual Property Statement 728 The IETF takes no position regarding the validity or scope of any 729 Intellectual Property Rights or other rights that might be claimed to 730 pertain to the implementation or use of the technology described in 731 this document or the extent to which any license under such rights 732 might or might not be available; nor does it represent that it has 733 made any independent effort to identify any such rights. Information 734 on the procedures with respect to rights in RFC documents can be 735 found in BCP 78 and BCP 79. 737 Copies of IPR disclosures made to the IETF Secretariat and any 738 assurances of licenses to be made available, or the result of an 739 attempt made to obtain a general license or permission for the use of 740 such proprietary rights by implementers or users of this 741 specification can be obtained from the IETF on-line IPR repository at 742 http://www.ietf.org/ipr. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights that may cover technology that may be required to implement 747 this standard. Please address the information to the IETF at 748 ietf-ipr@ietf.org. 750 Disclaimer of Validity 752 This document and the information contained herein are provided on an 753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 755 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 756 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 757 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Copyright Statement 762 Copyright (C) The Internet Society (2005). This document is subject 763 to the rights, licenses and restrictions contained in BCP 78, and 764 except as set forth therein, the authors retain all their rights. 766 Acknowledgment 768 Funding for the RFC Editor function is currently provided by the 769 Internet Society.