idnits 2.17.1 draft-ietf-csi-sndp-prob-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1140. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 20, 2008) is 5661 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 983, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 csi Working Group G. Daley 3 Internet-Draft 4 Intended status: Informational J-M. Combes 5 Expires: April 23, 2009 Orange Labs 6 S. Krishnan 7 Ericsson Research 8 October 20, 2008 10 Securing Neighbor Discovery Proxy Problem Statement 11 draft-ietf-csi-sndp-prob-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 23, 2009. 38 Abstract 40 Neighbor Discovery Proxy is used to provide an address presence on a 41 link from nodes which are no themselves present. It allows a node to 42 receive packets directed at its address by allowing another device to 43 Neighbor advertise on its behalf. 45 Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols 46 to provide reachability from nodes on the home network when a Mobile 47 Node is not at home, by allowing the Home Agent to act as proxy. It 48 is also used as a mechanism to allow a global prefix to span multiple 49 links, where proxies act as relays for Neighbor discovery messages. 51 Neighbor Discovery Proxy currently cannot be secured using SEND. 52 Today, SEND assumes that a node advertising an address is the address 53 owner and in possession of appropriate public and private keys for 54 that node. This document describes how existing practice for proxy 55 Neighbor Discovery relates to Secured Neighbor Discovery. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 3 62 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 5 63 2.3. Bridge-like ND proxies . . . . . . . . . . . . . . . . . . 5 64 3. Proxy ND and Mobility . . . . . . . . . . . . . . . . . . . . 7 65 4. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 10 66 4.1. CGA signatures and Proxy Neighbor Discovery . . . . . . . 11 67 4.2. Non-CGA signatures and Proxy Neighbor Discovery . . . . . 11 68 4.3. Securing proxy DAD . . . . . . . . . . . . . . . . . . . . 12 69 5. Potential Approaches to Securing Proxy ND . . . . . . . . . . 13 70 5.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 14 71 5.1.1. Mobile IPv6 and Router-based authorization . . . . . . 14 72 5.1.2. Mobile IPv6 and per-address authorization . . . . . . 14 73 5.1.3. Cryptographic based solutions . . . . . . . . . . . . 15 74 5.1.4. 'Point-to-Point' link model based solution . . . . . . 15 75 5.2. Secured Proxy ND and Bridge-like proxies . . . . . . . . . 15 76 5.2.1. Authorization Delegation . . . . . . . . . . . . . . . 15 77 5.2.2. Unauthorized routers and proxies . . . . . . . . . . . 16 78 5.2.3. Multiple proxy spans . . . . . . . . . . . . . . . . . 16 79 5.2.4. Routing Infrastructure Delegation . . . . . . . . . . 17 80 5.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 17 81 5.2.6. Host delegation of trust to proxies . . . . . . . . . 18 82 5.3. Proxying unsecured addresses . . . . . . . . . . . . . . . 19 83 6. Two or more nodes defending a same address . . . . . . . . . . 19 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 8.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 20 87 8.2. Certificate Transport . . . . . . . . . . . . . . . . . . 20 88 8.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 21 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Appendix A. Changes from the previous versions . . . . . . . . . 23 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 95 Intellectual Property and Copyright Statements . . . . . . . . . . 25 97 1. Introduction 99 Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery 100 [RFC4861]. It is used in networks where a prefix has to span 101 multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in 102 Mobile IPv6 based protocols like NEMO [RFC3963], FMIPv6 [RFC5268] or 103 HMIPv6 [RFC5380]) and in IKEv2 [RFC4306]. It allows a device which 104 is not physically present on a link to have another advertise its 105 presence, and forward on packets to the off-link device. 107 Neighbor Discovery Proxy relies upon another device, the proxy, to 108 monitor for Neighbor Solicitations (NS), and answer with Neighbor 109 Advertisements (NA). These proxy Neighbor Advertisements direct data 110 traffic through the proxy. Proxied traffic is then forwarded on to 111 the end destination. 113 2. Scenarios 115 This section describes the different scenarios where the interaction 116 between SEND and ND-Proxy raises issues. 118 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy 120 When moving in the Internet, the aim of IPv6 mobility is to allow a 121 device continued packet delivery, whether present on its home network 122 or not. The following text is focused on Mobile IPv6 but the issue 123 is the same with Mobile IPv6 based protocols (e.g. NEMO, HMIPv6). 125 For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing 126 sessions going even when one leaves the home network. If a Neighbor 127 is actively delivering packets to a Mobile Node which is at home, 128 this Neighbor will have a valid Neighbor cache entry pointed at the 129 MN's link-layer address on the Home link. 131 As seen in Figure 1, solicitors send a multicast solicitation to the 132 solicited nodes address of the absent node (based on the unicast 133 address). 135 Absent Mobile Proxy Solicitor 137 NS:SL3=S,DL3=Sol(A),TA=A 138 +-----+ SL2=s,DL2=sol(a),SLL=s 139 | |<================ 140 | | 141 | |================> 142 +-----+ NA:SL3=P,DL3=S,TA=A, 143 SL2=p,DL2=s,TLL=p 145 Legend: 146 SL3: Source IPv6 Address NS: Neighbor Solicitation 147 DL3: Destination IPv6 Address NA: Neighbor Advertisement 148 SL2: Source Link-Layer Address RS: Router Solicitation 149 DL2: Destination Link-Layer Address RA: Router Advertisement 150 TA: Target Address 151 SLL/TLL: Source/Target Link-Layer Address Option 153 Figure 1 155 The Proxy, which listens to this address responds with a Neighbor 156 Advertisement which originates at its own IPv6 address and has the 157 proxy's address as the Target Link-Layer Address, but contains the 158 absent mobile in the Target Address field of the Neighbor 159 Advertisement. In this case, no solicitations are proxied, as the 160 advertisements originate within the proxy itself. 162 If Cryptographically Generated Addressing (CGA) [RFC3972] is 163 available, the MN may be able to secure its Neighbor cache bindings 164 while at home using Secured Neighbor Discovery (SEND) [RFC3971]. 165 SEND assumes that the address owner is the advertiser and therefore 166 has access to the keys required to sign advertisements about the 167 address. Movement away from the home link requires that a proxy 168 undertake Neighbor Discovery. 170 In Mobile IPv6, the role of the proxy is undertaken by the Home 171 Agent. While the Home agent has a security association with the MN, 172 it as proxy will not have access to the public-private key pair used 173 to generate the MN's cryptographic address. This prevents Proxy 174 Neighbor Discovery from using SEND as defined [RFC3971]. 176 Where a host moves from the home network to a visited network, the 177 proxy needs to override existing valid Neighbor cache entries which 178 may have SEND protection. This is needed in order to redirect 179 traffic to use the proxy's link-layer address, allowing packets to 180 flow onto the tunnel connecting the Home Agent/Proxy and the MN. 181 With current specifications, any solicitation or advertisement sent 182 by the proxy will not be able to update the MN's home address if the 183 existing NC entry is protected by SEND. Such existing Neighbor cache 184 entries will time-out after Neighbor Unreachability Detection 185 [RFC4861]. 187 Where secured proxy services are not able to be provided, a proxy's 188 advertisement may be overridden by a bogus proxy without it even 189 knowing the attack has occurred. 191 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 193 This scenario is a sub-case from the previous one. The IPv6 node 194 will never be on the link where the ND messages are proxied. This is 195 case with IKEv2 [RFC4306] when a node needs an IP address in the 196 network protected by a security gateway and this latest assigns it 197 dynamically using Configuration Payload during IKEv2 exchanges. The 198 security gateway will have to proxy ND messages to be able to 199 intercept messages, sent to the node, to tunnel them to this latest. 201 2.3. Bridge-like ND proxies 203 Where proxies exist between two segments, messages may be sent by the 204 proxy on the far link, in order to gain or pass on Neighbor 205 information. The proxy in this case forwards messages while 206 modifying their source and destination MAC addresses, and rewrites 207 their Link-Layer Address Options solicited and override flags. This 208 is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389]. 210 This rewriting is incompatible with SEND signed messages for a number 211 of reasons: 213 o Rewriting elements within the message will break the digital 214 signature. 216 o The source IP address of the packets is the packet's origin, not 217 the proxy's address. The proxy is unable to generate another 218 signature for this address, as it doesn't have the CGA private key 219 [RFC3971]. 221 Proxy modification of SEND solicitations and advertisements require 222 removal of (at least) CGA and Signature options, and may also need 223 new options with proxy capabilities if non-CGA signatures are added 224 to SEND. 226 While bridge-like ND proxies aim to provide as little interference 227 with ND mechanisms as possible, SEND has been designed to prevent 228 modification or spoofing of advertisements by devices on the link. 230 Of particular note is the fact that ND Proxy performs a different 231 kind of proxy Neighbor discovery to Mobile IPv6 [RFC3775] [RFC4389]. 232 The Mobile IPv6 RFC specifies that the Home Agent as proxy sends 233 Neighbor Advertisements from its own address with the Target Address 234 set to the absent Mobile Node's address. The Home Agent's own link- 235 layer address is placed in the Target Link-Layer address option 236 [RFC3775]. 238 ND Proxy resends messages containing their original address, even 239 after modification [RFC4389]. Figure 2 describes packet formats for 240 proxy Neighbor solicitation and advertisement as specified by the 241 specification. 243 Advertisor Proxy Solicitor 245 NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A, 246 SL2=p,DL2=sol(A),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s 247 <==================| |<================ 248 | | 249 ==================>| |================> 250 NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A 251 SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p 253 Figure 2 255 In order to use the same security procedures for both ND Proxy and 256 Mobile IPv6, changes may be needed to the proxying procedures in 257 [RFC4389], as well as changes to SEND. 259 An additional (and undocumented) requirement for bridge-like proxying 260 is the operation of router discovery. Router Discovery packets may 261 similarly modify Neighbor cache state, and require protection from 262 SEND. 264 In Figure 3, the router discovery messages propagate without 265 modification to the router address, but elements within the message 266 change. This is consistent with the description of Neighbor 267 Discovery above. 269 Advertisor Proxy Solicitor 271 RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR, 272 SL2=p,DL2=sol(A),SLL=p +-----+ SL2=s,DL2=allr,SLL=s 273 <==================| |<================ 274 | | 275 ==================>| |================> 276 RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S, 277 SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p 278 Figure 3 280 Once again, these messages may not be signed with a CGA signature by 281 the re-advertisor, because it does not own the source address. 283 Additionally, multicast Authorization Delegation Discovery ICMPv6 284 messages need to be exchanged for bridge-like ND proxies to prove 285 their authority to forward. Unless the proxy receives explicit 286 authority to act as a router, or the router knows of its presence, no 287 authorization may be made. This explicit authorization requirement 288 may be at odds with zero configuration goal of ND proxying [RFC4389]. 290 An alternative (alluded to in an appendix of ND Proxy) suggests that 291 the proxy send Router Advertisements (RA) from its own address. As 292 described by ND Proxy, this is insufficient for providing proxied 293 Neighbor Advertisement service, but may be matched with Neighbor 294 solicitation and advertisement services using the proxy's source 295 address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This 296 means that all router and Neighbor advertisements would come from the 297 proxied address, but may contain a target address which allows 298 proxied Neighbor presence to be established with peers on other 299 segments. Router Discovery in this case has the identity of the 300 original (non-proxy) router completely obscured in router discovery 301 messages. 303 The resultant proxy messages would have no identifying information 304 indicating their origin, which means that proxying between multiple 305 links would require state to be stored on outstanding solicitations 306 (effectively a ND only NAT). This level of state storage may be 307 undesirable. 309 Mobile IPv6 does not experience this issue when supplying its own 310 address, since ND messages are never forwarded on to the absent node 311 (the Home Agent having sufficient information to respond itself). 313 Authorization from a router may still be required for Router 314 Advertisement, and will be discussed in Section 5.2. 316 3. Proxy ND and Mobility 318 Whenever a mobile device moves off a link and requires another device 319 to forward packets from that address to the MN's new location, proxy 320 Neighbor Discovery is required. 322 In the Mobile IPv6 case, where the Mobile Node moves away from home, 323 a Home Agent needs to be able to override existing Neighbor cache 324 entries in order to redirect packet flow over a tunnel to the Mobile 325 Node's Care-of-Address (CoA) [RFC3775]. 327 In Fast Handovers for Mobile IPv6, local Neighbors or routers with 328 existing valid Neighbor cache states need to be told the PAR's link- 329 layer address when the MN is departing for a new link, or after 330 arrival on the new link when tunnel forwarding begins [RFC5268]. 331 This allows the MN to maintain reachability to the hosts on that link 332 until it is able to send Mobile IPv6 Binding signalling subsequent to 333 address configuration on the new network. 335 As shown in Figure 4, after the mobile node departs, the Home Agent 336 or Proxy sends an overriding Neighbor advertisement, in order to 337 update existing Neighbor cache entries. 339 Absent Mobile Proxy Solicitor 341 +-----+ 342 Binding Update | | 343 ---------------->| | 344 or Fast BU | |================> 345 +-----+ NA:SL3=P,DL3=AllN,TA=A, 346 SL2=p,DL2=alln,TLL=p 348 Figure 4 350 Where the proxy forwards between segments of a network, nodes may 351 move between segments [RFC4389]. For this scenario, the proxy is 352 responsible for updating Neighbor cache entries as incorrect state is 353 left in them after the move. 355 Devices which were on the same segment as the moving node, 356 subsequently have incorrect Neighbor cache state, as they now need to 357 traverse the proxy to get to the other node. Devices which were 358 previously being proxied may now be on the same segment as the mobile 359 node, and may go direct. 361 As illustrated in Figure 5, the nodes may have incorrect Neighbor 362 cache state, even if the proxy knows of the departure to another 363 segment. 365 Mobile Node Proxy Mobile Node - M 366 (Departed) P (New Location) 368 + - - + +-----+ NC: 369 ' ' NC: NC: | | N -> n 370 + - - + N -> n+-----+M -> m +-----+ 371 | | | | 372 ------------------| |-------------------- 373 | | | 374 +-----+NC: +-----+ 375 | |M -> m 376 +-----+ 378 Existing 379 Neighbor - N 381 Figure 5 383 While Neighbor cache state times out, and causes devices to probe for 384 the location of a peer, long delays may occur before timeouts of 385 Neighbor cache state [RFC4861]. In cases where these delays are too 386 long, the proxy may have to override the Neighbor cache entries of 387 hosts which were previously on the same segment as the moving node. 389 Those devices now resident on the same segment as the mobile node 390 will have the proxy's link-layer address in its Neighbor cache. In 391 ND Proxy, it is indicated that packets are never forwarded back to 392 the same segment upon which they arrived (potentially to prevent 393 forwarding loops) [RFC4389]. 395 Similarly, if the mobile node is unaware of its movement, it too may 396 have incorrect Neighbor cache entries for devices which it is now on 397 the same segment as. This is shown below in Figure 6. 399 Mobile Node Proxy Mobile Node - M 400 (Departed) P (New Location) 402 + - - + +-----+ NC: 403 ' ' NC: NC: | | N -> p2 404 + - - + +-----+M -> m +-----+ 405 | | |N -> n | 406 ------------------| |-------------------- 407 | | | 408 P2+-----+P1 +-----+ NC: 409 | | M -> p1 410 +-----+ 412 Existing 413 Neighbor - N 415 Figure 6 417 For the remaining duration of their incorrect Neighbor cache entry 418 (up to around 35 seconds), all packets will be dropped. Therefore, 419 these devices may need to be updated with the present node's link- 420 layer address. 422 Procedures regarding updating caches rely upon Section 7.2.6 of IPv6 423 Neighbor Discovery [RFC4861], which allows proxies to Neighbor 424 advertise to all-nodes with the override flag set when becoming a 425 proxy or addresses change. 427 For either environment, updates are required to Neighbor cache 428 entries which may be for SEND nodes. These advertisements must 429 therefore have enough authority to override Neighbor cache entries 430 even though they are secured. 432 4. Proxy Neighbor Discovery and SEND 434 There are currently no existing secured Neighbor Discovery procedures 435 for proxied addresses, and all Neighbor Advertisements from SEND 436 nodes are required to have equal source and target addresses, and be 437 signed by the transmitter (section 7.4 of [RFC3971]). 439 Signatures over SEND messages are required to be applied on the CGA 440 source address of the message, and there is no way of indicating that 441 a message is proxied. 443 Even if the message is able to be transmitted from the original 444 owner, differences in link-layer addressing and options require 445 modification by a proxy. If a message is signed with a CGA-based 446 signature, the proxy is unable to regenerate a signature over the 447 changed message as it lacks the keying material. 449 Therefore, a router wishing to provide proxy Neighbor Advertisement 450 service can not use existing SEND procedures on those messages. 452 A host may wish to establish a session with a device which is not on- 453 link but is proxied. As a SEND host, it prefers to create Neighbor 454 cache entries using secured procedures. Since SEND signatures cannot 455 be applied to an existing proxy Neighbor Advertisement, it must 456 accept non-SEND advertisements in order to receive proxy Neighbor 457 Advertisements. 459 Neighbor Cache spoofing of another node therefore becomes trivial, as 460 any address may be proxy advertised to the SEND node, and overridden 461 only if the node is there to protect itself. When a node is present 462 to defend itself, it may also be difficult for the solicitor 463 determine the difference between a proxy-spoofing attack, and a 464 situation where a proxied device returns to a link and overrides 465 other proxy advertisers [RFC4861]. 467 4.1. CGA signatures and Proxy Neighbor Discovery 469 SEND defines one public-key and signature format for use with 470 Cryptographically Generated Addresses (CGAs) [RFC3971]. CGAs are 471 intended to tie address ownership to a particular Public/Private key 472 pair. 474 In SEND as defined today, Neighbor Discovery Messages (including the 475 IP Addresses from the IPv6 header) are signed with the same key used 476 to generate the CGA. This means that message recipients have proof 477 that the signer of the message owned the address. 479 Where a proxy replaces the message source with its own CGA, the 480 existing CGA option and RSA signature option need to be replaced with 481 the proxy's. Such a message will validate using SEND, except that 482 the Target Address field will not match the IPv6 Source Address in 483 Neighbor Advertisements [RFC3971]. 485 Additional authorization information may be needed to prove that the 486 proxy is indeed allowed to advertise for the target address, as is 487 described in Section 5. 489 4.2. Non-CGA signatures and Proxy Neighbor Discovery 491 Where a proxy retains the original source address in a proxied 492 message, existing SEND-CGA checks will fail, since fields within the 493 message will be changed. In order to achieve secured proxy Neighbor 494 discovery in this case, new signature authentication mechanisms may 495 be needed for SEND. 497 SEND provides interfaces for extension of SEND to non-CGA based 498 authorization. Messages are available for Authorization Delegation 499 Discovery, which is able to carry arbitrary PKIX/X.509 certificates 500 [RFC5280]. 502 There is no specification though of keying information option formats 503 analogous to the SEND CGA Option [RFC3971]. The existing option 504 allows a host to verify message integrity by specifying a key and 505 algorithm for digital signature, without providing authorization for 506 functions other than CGA ownership. 508 The digital signature in SEND is transported in the RSA Signature 509 Option. As currently specified, the signature operation is performed 510 over a CGA Message type, and infers support for CGA verification. 511 Clarification or changing of this issue for non-CGA operations may be 512 necessary. 514 Within SEND, more advanced functions such as routing may be 515 authorized by certificate path verification using Authorization 516 Delegation Discovery. 518 With non-CGA signatures and authentication, certificate contents for 519 authorization may need to be determined, as outlined in Section 5. 521 While SEND provides for extensions to new non-CGA methods, existing 522 SEND hosts may silently discard messages with unverifiable RSA 523 signature options (Section 5.2.2 of [RFC3971]), if configured only to 524 accept SEND messages. In cases where unsecured Neighbor cache 525 entries are still accepted, messages from new algorithms will be 526 treated as unsecured. 528 4.3. Securing proxy DAD 530 Initiation of Proxy Neighbor Discovery also requires Duplicate 531 Address Detection (DAD) checks of the address [RFC4862]. These DAD 532 checks need to be performed by sending Neighbor Solicitations, from 533 the unspecified source address, with the target being the proxied 534 address. 536 In existing SEND procedures, the address which is used for CGA tests 537 on DAD NS is the target address. A Proxy which originates this 538 message while the proxied address owner is absent is unable to 539 generate a CGA-based signature for this address and must undertake 540 DAD with an unsecured NS. It may be possible that the proxy can 541 ensure that responding NA's are secured though. 543 Where bridge-like ND proxy operations are being performed, DAD NS's 544 may be copied from the original source, without modification 545 (considering they have an unspecified source address and contain no 546 link-layer address options) [RFC4389] 548 If non-CGA based signatures are available, then the signature over 549 the DAD NS doesn't need to have a CGA relationship to the Target 550 Address, but authorization for address configuration needs to be 551 shown using certificates. Where SEND-only nodes do not understand 552 the signature format. 554 5. Potential Approaches to Securing Proxy ND 556 SEND nodes already have the concept of delegated authority through 557 requiring external authorization of routers to perform their routing 558 and advertisement roles. The authorization of these routers takes 559 the form of delegation certificates. 561 Proxy Neighbor Discovery requires a delegation of authority on behalf 562 of the absent address owner, to the proxier. Without this authority, 563 other devices on the link have no reason to trust an advertiser. 565 For bridge-like proxies, it is assumed that there is no preexisting 566 trust between the host owning the address and the proxy. Therefore, 567 authority may necessarily be dynamic or based on topological roles 568 within the network [RFC4389]. 570 Existing trust relationships lend themselves to providing authority 571 for proxying in two alternative ways. 573 First, the SEND router authorization mechanisms described above 574 provide delegation from the organization responsible for routing in 575 an address domain, to the certified routers. It may be argued that 576 routers so certified may be trusted to provide service for nodes 577 which form part of a link's address range, but are themselves absent. 578 Devices which are proxies could either be granted the right to proxy 579 by the network's router, or be implicitly allowed to proxy by virtue 580 of being an authorized router. 582 Second, where the proxied address is itself a CGA, the holder of the 583 public and private keys is seen to be authoritative about the 584 address' use. If this address owner was able to sign the proxier's 585 address and public key information, it would be possible to identify 586 that the proxy is known and trusted by the CGA address owner for 587 proxy service. This method requires that the proxied address know or 588 learn the proxy's address and public key, and that the certificate 589 signed by the proxied node's is passed to the proxy, either while 590 they share the same link, or at a later stage. 592 In both methods, the original address owner's advertisements need to 593 override the proxy if it suddenly returns, and therefore timing and 594 replay protection from such messages need to be carefully considered. 596 5.1. Secured Proxy ND and Mobile IPv6 598 Mobile IPv6 has a security association between the Mobile Node and 599 Home Agent. The Mobile Node sends a Binding Update to the Home 600 Agent, to indicate that it is not at home. This implies that the 601 Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery 602 operations for its home address(es). 604 5.1.1. Mobile IPv6 and Router-based authorization 606 A secured Proxy Neighbor Advertisements proposal based on existing 607 router trust would require no explicit authorization signalling 608 between HA and MN to allow proxying. Hosts on the home link will 609 believe proxied advertisements solely because they come from a 610 trusted router. 612 Where the home agent operates as a router without explicit trust to 613 route from the advertising routing infrastructure (such as in a home, 614 with a router managed by an ISP), more explicit proxying 615 authorization may be required, as described in Section 5.2. 617 5.1.2. Mobile IPv6 and per-address authorization 619 Where proxy Neighbor Discovery is delegated by the MN to the home 620 agent, the MN needs to learn the public key for the Home Agent, so 621 that it can generate a certificate authorizing the public-private 622 key-pair to be used in proxying. It may conceivably either do this 623 using Certificate Path Solicitations over a home tunnel, over the 624 Internet, or Router Discovery while still at home [RFC3971] 625 [RFC3775]. 627 When sending its Binding Update to the HA, the MN would need to 628 provide a certificate containing the subject(proxy-HA)'s public key 629 and address, the issuer(MN)'s CGA and public key, and timestamps 630 indicating when the authority began and when it ends. This 631 certificate would need to be passed near to binding time, possibly in 632 a Certificate Path Advertisement [RFC3971]. Messaging or such an 633 exchange mechanism would have to be developed. 635 5.1.3. Cryptographic based solutions 637 Specific cryptographic algorithms may help to allow trust between 638 entities of a same group. 640 This is the case, for example, with ring signature algorithms, a type 641 of signature generated using the private key of any entity from the 642 same group but to check the signature, the public keys of all group 643 members are required. Applied to SEND, the addresses are 644 cryptographically generated using multiple public keys and the 645 Neighbor Discovery messages are signed with an RSA ring signature. 647 5.1.4. 'Point-to-Point' link model based solution 649 Another approach is to use the 'Point-to-Point' link model. 651 In this model, one prefix is provided per MN and only a MN and the HA 652 are on a same link. The consequence is the HA no more needs to act 653 as ND Proxy. 655 One way to design such a solution is to use virtual interfaces, on 656 the MN and the HA, and a virtual link between them. Addresses 657 generated on the virtual interfaces will only be advertised on the 658 virtual link. For Mobile IPv6, this results to use a virtual Home 659 Network where the MN will never come back. 661 5.2. Secured Proxy ND and Bridge-like proxies 663 In link-extension environments, the role of a proxy is more 664 explicitly separated from that of a router. In SEND, routers may 665 expect to be authorized by the routing infrastructure to advertise, 666 and provide this authority to hosts in order to allow them to change 667 forwarding state. 669 Proxies are not part of the traditional infrastructure of the 670 Internet, and hosts or routers may not have an explicit reason to 671 trust them, except that they can forward packets to regions where 672 otherwise they could not reach. 674 5.2.1. Authorization Delegation 676 If a proxy can convince a device that it should be trusted to perform 677 proxying function, it may require that device to vouch for its 678 operation in dealing with other devices. It may do this by receiving 679 a certificate, signed by the originating device that the proxy is 680 believed capable of proxying under certain circumstances. 682 This allows nodes receiving proxied Neighbor discovery packets to 683 quickly check if the proxy is authorized for the operation. There 684 are several bases for such trust, and requirements in proxied 685 environments, which are discussed below. 687 5.2.2. Unauthorized routers and proxies 689 Routers advertising on networks without routers may have to operate 690 with no explicit authorization, and SEND hosts will configure these 691 if there's no other option [RFC3971]. While proxies may similarly 692 attempt to advertise without authority, this provides no security for 693 the routing infrastructure. Any device can set up to be a SEND 694 proxy/router so long as it signs its own ND messages from its CGA. 696 This may not help in the case that a proxy attempts to update 697 Neighbor cache entries for SEND node which moves between links, since 698 the SEND node's authority to advertise its own CGA address would not 699 be superceded by a proxy with no credentials. 701 5.2.3. Multiple proxy spans 703 Proxies may have multiple levels of nesting, which allow the network 704 to connect between non-adjacent segments. 706 In this case, authority delegated at one point will have to be 707 redelegated (possibly in a diluted form) to proxies further away from 708 the origin of the trust. 710 Trust ProxyA ProxyB Distant 711 Origin - T Node - D 713 +-----+ +-----+ 714 | | | | 715 +-----+ +-----+ +-----+ +-----+ 716 | | | | | | 717 ------------| |------------| |---------- 718 | | | | 719 +-----+ +-----+ 720 ==========> ==============> ==========> 721 Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B, 722 Deleg(A,T)) 724 Figure 7 726 As shown in Figure 7, the Proxy A needs to redelegate authority to 727 proxy for T to B, this allows it to proxy advertisements back to D, 728 which target T. 730 5.2.4. Routing Infrastructure Delegation 732 Where it is possible for the proxy to pre-establish trust with the 733 routing infrastructure, or at least to the local router, it may be 734 possible to authorize proxying as a function of routing within the 735 subnet. The router or CA may then be able to certify proxying for 736 only a subset of the prefixes which is itself certified for. 738 If a router or CA provides certification for a particular prefix, it 739 may be able to indicate that only proxying is supported, so that 740 Neighbor cache entries of routers connected to internet 741 infrastructure are never overridden by the proxy, if the router is 742 present on a segment. 744 Hosts understanding such certificates may allow authorized proxies 745 and routers to override host SEND/CGA when assuming proxy roles, if 746 the host is absent. 748 Proxy certificate signing could be done either dynamically (requiring 749 exchanges of identity and authorization information), or statically 750 when the network is set up. 752 5.2.5. Local Delegation 754 Where no trust tie exists between the authority which provides the 755 routing infrastructure and the provider of bridging and proxying 756 services, it may still be possible for SEND hosts to trust the 757 bridging provider to authorize proxying operations. 759 SEND itself requires that routers be able to show authorization, but 760 doesn't require routers to have a single trusted root. 762 A local bridging/proxying authority trust delegation may be possible. 763 It would be possible for this authority to pass out local use 764 certificates, allowing proxying on a specific subnet or subnets, with 765 a separate authorization chain to that for the routers with Internet 766 access. 768 This would require little modification to SEND, other than addition 769 of router based proxy authority (as in Section 5.2.4), and proxies 770 would in effect be treated as routers by SEND hosts [RFC3971]. 771 Distribution of keying and trust material for the initial bootstrap 772 of proxies would not be provided though (and may be static). 774 Within small domains, key management and distribution may be a 775 tractable problem, so long as these operations are are simple enough 776 to perform. 778 Since these domains may be small, it may be necessary to provide 779 certificate chains for trust anchors which weren't requested in 780 Certificate Path Solicitations, if the proxy doesn't have a trust 781 chain to any requested trust anchor. 783 This is akin to 'suggesting' an appropriate trusted root. It may 784 allow for user action in allowing trust extension when visiting 785 domains without ties to a global keying infrastructure. In this 786 case, the trust chain would have to start with a self-signed 787 certificate from the original CA. 789 5.2.6. Host delegation of trust to proxies 791 Unlike Mobile IPv6, for bridge-like proxied networks, there is no 792 existing security association upon which to transport proxying 793 authorization credentials. 795 Proxies need then to convince Neighbors to delegate proxy authority 796 to them, in order to proxy-advertise to nodes on different segments. 797 It will be difficult without additional information to distinguish 798 between legitimate proxies, and devices which have no need or right 799 to proxy (and may wish two network segments to appear to be 800 connected). 802 When proxy advertising, proxies must not only identify that proxying 803 needs to occur, but provide proof that they are allowed to do so, so 804 that SEND Neighbor Cache entries may be updated. Unless the 805 authorization to update such entries is tied to address ownership 806 proofs from the proxied host or the verifiable routing 807 infrastructure, spoofing may occur. 809 When a host received a proxied Neighbor advertisement, it would be 810 necessary to check authorization in the same way that authorization 811 delegation discovery is performed in SEND. 813 Otherwise, certificate transport will be required to exchange 814 authorization between proxied nodes and proxies. 816 Proxies would have to be able to delegate this authorization to 817 downstream proxies, as described in Section 5.2.3. 819 Movement between segments could be controlled with increasing 820 certificate sequence numbers and timestamps. The timestamp of the 821 root authority (in this case, the CGA address owner) would be most 822 significant. Where ties exist, the shortest chain would supercede, 823 as this would indicate a proxy closer to the proxied node. 825 5.3. Proxying unsecured addresses 827 Where the original Neighbor discovery message is unsecured, there is 828 an argument for not providing secured proxy service for that node. 830 In both the Mobile IPv6 and extended networks cases, the node may 831 arrive back at the network and require other hosts to map their 832 existing Neighbor cache entry to the node's link-layer address. The 833 re-arriving node's overriding of link-layer address mappings will 834 occur without SEND in this case. 836 It is notable that without SEND protection any node may spoof the 837 arrival, and effectively steal service across an extended network. 838 This is the same as in the non-proxy case, and is not made 839 significantly worse by the proxy's presence (although the identity of 840 the attacker may be masked if source addresses are being replaced). 842 If signatures over the proxied messages were to be used, re-arrival 843 and override of the Neighbor cache entries would have to be allowed, 844 so the signatures would indicate that at least the proxy wasn't 845 spoofing (even if the original sender was). 847 For non-SEND/CGA routers, though, it may be possible for secured 848 proxies to send signed router advertisement messages, in order to 849 ensure that routers aren't spoofed, and subsequently switched to 850 being on different parts of the extended network. 852 This has problems in that the origin is again unsecured, and any node 853 on the network could spoof router advertisement for an unsecured 854 address. These spoofed messages may become almost indistinguishable 855 (except for the non-CGA origin address) from unspoofed messages from 856 SEND routers. 858 Given these complexities, the simplest method is to allow unsecured 859 devices to be spoofed from any port on the network, as is the case 860 today. 862 6. Two or more nodes defending a same address 864 The previous part of this document focused on the case where two 865 nodes defend a same address (i.e. the node and the proxy). But, 866 there are scenarios where two or more nodes are defending a same 867 address. This is at least the case for: 869 o Nodes having the same address, as the MAG's ingress link-local 870 address in PMIPv6 [I-D.ietf-netlmm-mn-ar-if]. 872 o Nodes having a common anycast address [RFC4291]. 874 The problem statement, described previously in this document, applies 875 for these cases and the issues are the same from a signalling point 876 of view. 878 Multicast addresses are not mentioned here because Neighbor Discovery 879 Protocol is not used for them. 881 In the first case, [I-D.ietf-netlmm-mn-ar-if] assumes that the 882 security material used by SEND (i.e. public-private key pair) is 883 shared between all the MAGs. For the second case, there is no 884 solution today. But, in a same way, it should be possible to assume 885 that the nodes having a common anycast address could also share the 886 security material. 888 It is important to notice that when many nodes defending a same 889 address are not in the same administrative domain (e.g. MAGs in 890 different administrative domains but in a same PMIPv6 domain 891 [RFC5213]), sharing the security material used by SEND may raise a 892 security issue. 894 7. IANA Considerations 896 No new options or messages are defined in this document. 898 8. Security Considerations 900 8.1. Router Trust Assumption 902 Router based authorization for Secured Proxy ND may occur without the 903 knowledge or consent of a device. It is susceptible to the 'Good 904 Router Goes Bad' attack described in [RFC3756]. 906 8.2. Certificate Transport 908 The certification delegation relies upon transfer of the new 909 credentials to the proxying HA in order to undertake ND proxy on its 910 behalf. Since the Binding cannot come into effect until DAD has 911 taken place, the delegation of the proxying authority necessarily 912 predates the return of the Binding Ack, as described in [RFC3775]. 913 In the above described case, the home tunnel which comes into 914 creation as part of the binding process may be required for 915 Certificate Path Solicitation or Advertisement transport [RFC3971]. 916 This constitutes a potential chicken-and-egg problem. Either 917 modifications to initial home binding semantics or certificate 918 transport are required. This may be trivial if signed, non- 919 repudiable certificates are sent in the clear between the MN's CoA 920 and the HA without being tunneled. 922 8.3. Timekeeping 924 All of the presented methods rely on accurate timekeeping on the 925 receiver nodes of Neighbor Discovery Timestamp Options and 926 certificates. 928 For router-authorized proxy ND, a Neighbor may not know that a 929 particular ND message is replayed from the time when the proxied host 930 was still on-link, since the message's timestamp falls within the 931 valid timing window. Where the router advertises its secured proxy 932 NA, a subsequent replay of the old message will override the NC entry 933 created by the proxy. 935 Creating the Neighbor cache entry in this way, without reference to 936 accurate subsequent timing, may only be done once. Otherwise the 937 receiver will notice that the timestamp of the advertisement is old 938 or doesn't match. 940 One way of creating a sequence of replayable messages which have 941 timestamps likely to be accepted is to pretend to do an unsecured DAD 942 on the address each second while the MN is at home. The attacker 943 saves each DAD defence in a sequence. The granularity of SEND 944 timestamp matching is around 1 second, so the attacker has a set of 945 SEND NA's to advertise, starting at a particular timestamp, and valid 946 for as many seconds as the original NA gathering occurred. 948 This sequence may then be played against any host which doesn't have 949 a timestamp history for that MN, by tracking the number of seconds 950 elapsed since the initial transmission of the replayed NA to that 951 victim, and replaying the appropriate cached NA. 953 Where certificate based authorization of ND proxy is in use, the 954 origination/starting timestamp of the delegated authority may be used 955 to override a replayed (non-proxy) SEND NA, while also ensuring that 956 the Proxy NA's timestamp (provided by the proxy) is fresh. A 957 returning MN would advertise a more recent timestamp than the 958 delegated authority and thus override it. This method is therefore 959 not subject to the above attack, since the proxy advertisement's 960 certificate will have a timestamp greater than any replayed messages, 961 preventing it from being overridden. 963 9. Acknowledgments 965 James Kempf and Dave Thaler particularly contributed to work on this 966 document. Contributions to discussion on this topic helped to 967 develop this document. Thanks go to Jari Arkko, Vijay Devarapalli, 968 and Mohan Parthasarathy. 970 Jean-Michel Combes is partly funded by MobiSEND, a research project 971 supported by the French 'National Research Agency' (ANR). 973 10. References 975 10.1. Normative References 977 [I-D.ietf-netlmm-mn-ar-if] 978 Laganier, J., Narayanan, S., and P. McCann, "Interface 979 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 980 Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), 981 February 2008. 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, March 1997. 986 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 987 in IPv6", RFC 3775, June 2004. 989 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 990 Neighbor Discovery (SEND)", RFC 3971, March 2005. 992 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 993 RFC 3972, March 2005. 995 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 996 Architecture", RFC 4291, February 2006. 998 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 999 RFC 4306, December 2005. 1001 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1002 Proxies (ND Proxy)", RFC 4389, April 2006. 1004 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1005 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1006 September 2007. 1008 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1009 Address Autoconfiguration", RFC 4862, September 2007. 1011 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1012 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1014 10.2. Informative References 1016 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1017 Discovery (ND) Trust Models and Threats", RFC 3756, 1018 May 2004. 1020 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1021 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1022 RFC 3963, January 2005. 1024 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, 1025 June 2008. 1027 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1028 Housley, R., and W. Polk, "Internet X.509 Public Key 1029 Infrastructure Certificate and Certificate Revocation List 1030 (CRL) Profile", RFC 5280, May 2008. 1032 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1033 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1034 Management", RFC 5380, October 2008. 1036 Appendix A. Changes from the previous versions 1038 To be removed prior to publication as an RFC. 1040 Previous version: draft-daley-csi-sndp-prob-00 1042 o Substitution of "Neighbor" for "Neighbour" to be compliant with 1043 RFC 4861 1045 o Addition of text explaining why multicast addresses are out of 1046 scope (section 6) 1048 o Update of the references. 1050 Previous version: draft-daley-send-spnd-prob-02 1052 o Integration of the "Two or more nodes defending a same address" 1053 section in the core document. 1055 o Addition of the "Cryptographic based solutions" section. 1057 o Addition of the "'Point-to-Point' link model based solution" 1058 section. 1060 o Update of the references. 1062 Previous version: draft-daley-send-spnd-prob-01 1064 o Reorganisation of the draft structure. 1066 o Addition of the "Fixed Nodes and Neighbor Discovery Proxy" 1067 section. 1069 o Update of the references. 1071 o Addition of the "Two or more nodes defending a same address" 1072 Appendix 1074 o Addition of the "Changes from the previous version" Appendix. 1076 Authors' Addresses 1078 Greg Daley 1079 55 Pakington St 1080 Kew, Victoria 3101 1081 Australia 1083 Phone: +61 405 494849 1084 Email: hoskuld@hotmail.com 1086 Jean-Michel Combes 1087 Orange Labs 1088 38 rue du General Leclerc 1089 92794 Issy-les-Moulineaux Cedex 9 1090 France 1092 Email: jeanmichel.combes@gmail.com 1094 Suresh Krishnan 1095 Ericsson Research 1096 8400 Decarie Blvd. 1097 Town of Mount Royal 1098 QC Canada 1100 Email: Suresh.Krishnan@ericsson.com 1102 Full Copyright Statement 1104 Copyright (C) The IETF Trust (2008). 1106 This document is subject to the rights, licenses and restrictions 1107 contained in BCP 78, and except as set forth therein, the authors 1108 retain all their rights. 1110 This document and the information contained herein are provided on an 1111 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1112 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1113 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1114 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1115 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1116 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1118 Intellectual Property 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1132 such proprietary rights by implementers or users of this 1133 specification can be obtained from the IETF on-line IPR repository at 1134 http://www.ietf.org/ipr. 1136 The IETF invites any interested party to bring to its attention any 1137 copyrights, patents or patent applications, or other proprietary 1138 rights that may cover technology that may be required to implement 1139 this standard. Please address the information to the IETF at 1140 ietf-ipr@ietf.org.