idnits 2.17.1 draft-ietf-csi-sndp-prob-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 9, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1022, 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 (==), 3 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: September 10, 2009 Orange Labs 6 S. Krishnan 7 Ericsson 8 March 9, 2009 10 Securing Neighbor Discovery Proxy Problem Statement 11 draft-ietf-csi-sndp-prob-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 10, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Neighbor Discovery Proxies are used to provide an address presence on 50 a link for nodes that are no longer present on the link. They allow 51 a node to receive packets directed at its address by allowing another 52 device to perform neighbor discovery operations on its behalf. 54 Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols 55 to provide reachability from nodes on the home network when a Mobile 56 Node is not at home, by allowing the Home Agent to act as proxy. It 57 is also used as a mechanism to allow a global prefix to span multiple 58 links, where proxies act as relays for Neighbor discovery messages. 60 Neighbor Discovery Proxy currently cannot be secured using SEND. 61 Today, SEND assumes that a node advertising an address is the address 62 owner and in possession of appropriate public and private keys for 63 that node. This document describes how existing practice for proxy 64 Neighbor Discovery relates to Secured Neighbor Discovery. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4 71 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6 72 2.3. Bridge-like ND proxies . . . . . . . . . . . . . . . . . . 6 73 2.4. Proxy ND and Mobility . . . . . . . . . . . . . . . . . . 9 74 3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 11 75 3.1. CGA signatures and Proxy Neighbor Discovery . . . . . . . 12 76 3.2. Non-CGA signatures and Proxy Neighbor Discovery . . . . . 12 77 3.3. Securing proxy DAD . . . . . . . . . . . . . . . . . . . . 13 78 3.4. Securing Router Advertisements . . . . . . . . . . . . . . 14 79 4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 14 80 4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 15 81 4.1.1. Mobile IPv6 and Router-based authorization . . . . . . 15 82 4.1.2. Mobile IPv6 and per-address authorization . . . . . . 15 83 4.1.3. Cryptographic based solutions . . . . . . . . . . . . 16 84 4.1.4. 'Point-to-Point' link model based solution . . . . . . 16 85 4.2. Secured Proxy ND and Bridge-like proxies . . . . . . . . . 16 86 4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 17 87 4.2.2. Unauthorized routers and proxies . . . . . . . . . . . 17 88 4.2.3. Multiple proxy spans . . . . . . . . . . . . . . . . . 17 89 4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 18 90 4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 18 91 4.2.6. Host delegation of trust to proxies . . . . . . . . . 19 92 4.3. Proxying unsecured addresses . . . . . . . . . . . . . . . 20 93 5. Two or more nodes defending the same address . . . . . . . . . 21 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 7.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 22 97 7.2. Certificate Transport . . . . . . . . . . . . . . . . . . 22 98 7.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 22 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery 108 [RFC4861]. It is used in networks where a prefix has to span 109 multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in 110 Mobile IPv6 based protocols like NEMO [RFC3963], FMIPv6 [RFC5268] or 111 HMIPv6 [RFC5380]) and in IKEv2 [RFC4306]. It allows a device which 112 is not physically present on a link to have another advertise its 113 presence, and forward on packets to the off-link device. 115 Neighbor Discovery Proxy relies upon another device, the proxy, to 116 monitor for Neighbor Solicitations (NS), and answer with Neighbor 117 Advertisements (NA). These proxy Neighbor Advertisements direct data 118 traffic through the proxy. Proxied traffic is then forwarded on to 119 the end destination. 121 2. Scenarios 123 This section describes the different scenarios where the interaction 124 between SEND and ND-Proxy raises issues. 126 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy 128 When moving in the Internet, the aim of IPv6 mobility is to allow a 129 device continued packet delivery, whether present on its home network 130 or not. The following text is focused on Mobile IPv6 but the issue 131 raised by the interaction between SEND and ND-Proxy is the same with 132 Mobile IPv6 based protocols (e.g. NEMO, HMIPv6). 134 For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing 135 sessions going or to allow new sessions even when one leaves the home 136 network. 138 In order to continue existing sessions, the Proxy (i.e. the Home 139 Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes 140 multicast address on the home link as specified [RFC3775]. 142 For new sessions, the Proxy, which listens to the MN's address 143 responds with a Neighbor Advertisement which originates at its own 144 IPv6 address and has the proxy's address as the Target Link-Layer 145 Address, but contains the absent mobile in the Target Address field 146 of the Neighbor Advertisement. In this case, no solicitations are 147 proxied, as the advertisements originate within the proxy itself. 149 As seen in Figure 1, solicitors send a multicast solicitation to the 150 solicited nodes multicast address (based on the unicast address) of 151 the absent node (mobile node that is away from the home link). 153 Absent Mobile Proxy Solicitor 155 NS:SL3=S,DL3=Sol(A),TA=A 156 +-----+ SL2=s,DL2=sol(a),SLL=s 157 | |<================ 158 | | 159 | |================> 160 +-----+ NA:SL3=P,DL3=S,TA=A, 161 SL2=p,DL2=s,TLL=p 163 Legend: 164 SL3: Source IPv6 Address NS: Neighbor Solicitation 165 DL3: Destination IPv6 Address NA: Neighbor Advertisement 166 SL2: Source Link-Layer Address RS: Router Solicitation 167 DL2: Destination Link-Layer Address RA: Router Advertisement 168 TA: Target Address 169 SLL/TLL: Source/Target Link-Layer Address Option 171 Figure 1 173 While at home, if the MN has configured Cryptographically Generated 174 Addresses (CGAs) [RFC3972], it can secure establishment by its on- 175 link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using 176 Secure Neighbor Discovery (SEND) [RFC3971]. SEND security requires a 177 node sending Neighbor Advertisments for a given address to be in 178 possession of the public-private key pair that generated the address. 180 When a MN moves away from the home link, a proxy has to undertake 181 Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, 182 the role of the proxy is undertaken by the Home Agent. While the 183 Home agent has a security association with the MN, it does not have 184 access to the public-private key pair used to generate the MN's CGA. 185 Thus the Home Agent acting as an ND proxy cannot use SEND for the 186 address it is proxying [RFC3971]. 188 When a MN moves from the home network to a visited network, the proxy 189 will have to override the MN's existing Neighbor Cache Entries which 190 are flagged as secure [RFC3971]. This is needed for the Home Agent 191 to intercept traffic sent on-link to the MN that would otherwise be 192 sent to the MN's link layer address. 194 With the current SEND specification, any solicitation or 195 advertisement sent by the proxy will be unsecure and thus will not be 196 able to update the MN's NCE for the home address because it is 197 flagged as secured. These existing Neighbor Cache Entries will only 198 time-out after Neighbor Unreachability Detection [RFC4861] concludes 199 the Home Address is unreachable at the link layer recorded in the 200 NCE. 202 Where secured proxy services are not able to be provided, a proxy's 203 advertisement may be overridden by a rogue proxy without the 204 receiving host realizing that an attack has occurred. This is 205 identical to what happens in a network where SEND is not deployed. 207 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 209 This scenario is a sub-case from the previous one. The IPv6 node 210 will never be on the link where the ND messages are proxied. This is 211 the case with IKEv2 [RFC4306]. When a node needs an IP address in 212 the network protected by a security gateway, the security gateway 213 assigns an address dynamically using Configuration Payload during 214 IKEv2 exchanges. The security gateway will have to proxy ND messages 215 in order to be able to intercept messages sent to the node and to 216 tunnel them to the node. 218 2.3. Bridge-like ND proxies 220 The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 221 method by which multiple link layer segments are bridged into a 222 single segment and specifies the IP-layer support that enables 223 bridging under these circumstances. The proxy in this case forwards 224 messages while modifying their source and destination MAC addresses, 225 and rewrites their Link-Layer Address Options, solicited, and 226 override flags. 228 This rewriting is incompatible with SEND signed messages for a number 229 of reasons: 231 o Rewriting elements within the message will break the digital 232 signature. 234 o The source IP address of the packets is the packet's origin, not 235 the proxy's address. The proxy is unable to generate another 236 signature for this address, as it doesn't have the CGA private key 237 [RFC3971]. 239 Thus, proxy modification of SEND solicitations may require sharing of 240 credentials between the proxied node and the proxying node or 241 creation of new options with proxying capabilities. 243 While bridge-like ND proxies aim to provide as little interference 244 with ND mechanisms as possible, SEND has been designed to prevent 245 modification or spoofing of advertisements by devices on the link. 247 Of particular note is the fact that ND Proxy performs a different 248 kind of proxy Neighbor discovery to Mobile IPv6 [RFC3775] [RFC4389]. 249 The Mobile IPv6 RFC specifies that the Home Agent as proxy sends 250 Neighbor Advertisements from its own address with the Target Address 251 set to the absent Mobile Node's address. The Home Agent's own link- 252 layer address is placed in the Target Link-Layer address option 253 [RFC3775]. 255 ND Proxy resends messages containing their original address, even 256 after modification [RFC4389]. Figure 2 describes packet formats for 257 proxy Neighbor solicitation and advertisement as specified by the 258 specification. 260 Advertisor Proxy Solicitor 262 NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A, 263 SL2=p,DL2=sol(A),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s 264 <==================| |<================ 265 | | 266 ==================>| |================> 267 NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A 268 SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p 270 Legend: 271 SL3: Source IPv6 Address NS: Neighbor Solicitation 272 DL3: Destination IPv6 Address NA: Neighbor Advertisement 273 SL2: Source Link-Layer Address 274 DL2: Destination Link-Layer Address 275 TA: Target Address 276 SLL/TLL: Source/Target Link-Layer Address Option 278 Figure 2 280 In order to use the same security procedures for both ND Proxy and 281 Mobile IPv6, changes may be needed to the proxying procedures in 282 [RFC4389], as well as changes to SEND. 284 An additional (and undocumented) requirement for bridge-like proxying 285 is the operation of router discovery. Router Discovery packets may 286 similarly modify Neighbor cache state, and require protection from 287 SEND. 289 In Figure 3, the router discovery messages propagate without 290 modification to the router address, but elements within the message 291 change. This is consistent with the description of Neighbor 292 Discovery above. 294 Advertisor Proxy Solicitor 296 RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR, 297 SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s 298 <==================| |<================ 299 | | 300 ==================>| |================> 301 RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S, 302 SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p 304 Legend: 305 SL3: Source IPv6 Address RS: Router Solicitation 306 DL3: Destination IPv6 Address RA: Router Advertisement 307 SL2: Source Link-Layer Address 308 DL2: Destination Link-Layer Address 309 TA: Target Address 310 SLL/TLL: Source/Target Link-Layer Address Option 312 Figure 3 314 Once again, these messages may not be signed with a CGA signature by 315 the proxy, because it does not own the source address. 317 Additionally, Authorization Delegation Discovery messages need to be 318 exchanged for bridge-like ND proxies to prove their authority to 319 forward. Unless the proxy receives explicit authority to act as a 320 router, or the router knows of its presence, no authorization may be 321 made. This explicit authorization requirement may be at odds with 322 the zero configuration goal of ND proxying [RFC4389]. 324 An alternative (alluded to in an appendix of ND Proxy) suggests that 325 the proxy send Router Advertisements (RA) from its own address. As 326 described by ND Proxy, this is insufficient for providing proxied 327 Neighbor Advertisement service, but may be matched with Neighbor 328 solicitation and advertisement services using the proxy's source 329 address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This 330 means that all router and Neighbor advertisements would come from the 331 proxied address, but may contain a target address which allows 332 proxied Neighbor presence to be established with peers on other 333 segments. Router Discovery in this case has the identity of the 334 original (non-proxy) router completely obscured in router discovery 335 messages. 337 The resultant proxy messages would have no identifying information 338 indicating their origin, which means that proxying between multiple 339 links would require state to be stored on outstanding solicitations 340 (effectively a ND only NAT). This level of state storage may be 341 undesirable. 343 Mobile IPv6 does not experience this issue when supplying its own 344 address, since ND messages are never forwarded on to the absent node 345 (the Home Agent having sufficient information to respond itself). 347 Authorization from a router may still be required for Router 348 Advertisement, and will be discussed in Section 4.2. 350 2.4. Proxy ND and Mobility 352 Whenever a mobile device moves off a link and requires another device 353 to forward packets from that address to the MN's new location, proxy 354 Neighbor Discovery is required. 356 In the Mobile IPv6 case, where the Mobile Node moves away from home, 357 a Home Agent needs to be able to override existing Neighbor cache 358 entries in order to redirect packet flow over a tunnel to the Mobile 359 Node's Care-of-Address (CoA) [RFC3775]. 361 In Fast Handovers for Mobile IPv6, local Neighbors or routers with 362 existing valid Neighbor cache states need to be told the PAR's link- 363 layer address when the MN is departing for a new link, or after 364 arrival on the new link when tunnel forwarding begins [RFC5268]. 365 This allows the MN to maintain reachability to the hosts on that link 366 until it is able to send Mobile IPv6 Binding signalling subsequent to 367 address configuration on the new network. 369 As shown in Figure 4, after the mobile node departs, the Home Agent 370 or Proxy sends an overriding Neighbor advertisement, in order to 371 update existing Neighbor cache entries. 373 Absent Mobile Proxy Solicitor 375 +-----+ 376 Binding Update | | 377 ---------------->| | 378 or Fast BU | |================> 379 +-----+ NA:SL3=P,DL3=AllN,TA=A, 380 SL2=p,DL2=alln,TLL=p 382 Figure 4 384 Devices which were on the same segment as the moving node, 385 subsequently have incorrect Neighbor cache state, as they now need to 386 traverse the proxy to get to the other node. Devices which were 387 previously being proxied may now be on the same segment as the mobile 388 node, and may go direct. 390 As illustrated in Figure 5, the nodes may have incorrect Neighbor 391 cache state, even if the proxy knows of the departure to another 392 segment. 394 Mobile Node Proxy Mobile Node - M 395 (Departed) P (New Location) 397 + - - + +-----+ NC: 398 ' ' NC: NC: | | N -> n 399 + - - + N -> n+-----+M -> m +-----+ 400 | | | | 401 ------------------| |-------------------- 402 | | | 403 +-----+NC: +-----+ 404 | |M -> m 405 +-----+ 407 Existing 408 Neighbor - N 410 Figure 5 412 While Neighbor cache state times out, and causes devices to probe for 413 the location of a peer, long delays may occur before timeouts of 414 Neighbor cache state [RFC4861]. In cases where these delays are too 415 long, the proxy may have to override the Neighbor cache entries of 416 hosts which were previously on the same segment as the moving node. 418 Those devices now resident on the same segment as the mobile node 419 will have the proxy's link-layer address in its Neighbor cache. In 420 ND Proxy, it is indicated that packets are never forwarded back to 421 the same segment upon which they arrived (potentially to prevent 422 forwarding loops) [RFC4389]. 424 Similarly, if the mobile node is unaware of its movement, it too may 425 have incorrect Neighbor cache entries for devices which it is now on 426 the same segment as. This is shown below in Figure 6. 428 Mobile Node Proxy Mobile Node - M 429 (Departed) P (New Location) 431 + - - + +-----+ NC: 432 ' ' NC: NC: | | N -> p2 433 + - - + +-----+M -> m +-----+ 434 | | |N -> n | 435 ------------------| |-------------------- 436 | | | 437 P2+-----+P1 +-----+ NC: 438 | | M -> p1 439 +-----+ 441 Existing 442 Neighbor - N 444 Figure 6 446 For the remaining duration of their incorrect Neighbor cache entry 447 (up to around 35 seconds), all packets will be dropped. Therefore, 448 these devices may need to be updated with the present node's link- 449 layer address. 451 Procedures regarding updating caches rely upon Section 7.2.6 of IPv6 452 Neighbor Discovery [RFC4861], which allows proxies to Neighbor 453 advertise to all-nodes with the override flag set when becoming a 454 proxy or addresses change. 456 For either environment, updates are required to Neighbor cache 457 entries which may be for SEND nodes. These advertisements must 458 therefore have enough authority to override Neighbor cache entries 459 even though the neighbor cache entries are secured. 461 3. Proxy Neighbor Discovery and SEND 463 There are currently no existing secured Neighbor Discovery procedures 464 for proxied addresses, and all Neighbor Advertisements from SEND 465 nodes are required to have equal source and target addresses, and be 466 signed by the transmitter (section 7.4 of [RFC3971]). 468 Signatures over SEND messages are required to be applied on the CGA 469 source address of the message, and there is no way of indicating that 470 a message is proxied. 472 Even if the message is able to be transmitted from the original 473 owner, differences in link-layer addressing and options require 474 modification by a proxy. If a message is signed with a CGA-based 475 signature, the proxy is unable to regenerate a signature over the 476 changed message as it lacks the keying material. 478 Therefore, a router wishing to provide proxy Neighbor Advertisement 479 service can not use existing SEND procedures on those messages. 481 A host may wish to establish a session with a device which is not on- 482 link but is proxied. As a SEND host, it prefers to create Neighbor 483 cache entries using secured procedures. Since SEND signatures cannot 484 be applied to an existing proxy Neighbor Advertisement, it must 485 accept non-SEND advertisements in order to receive proxy Neighbor 486 Advertisements. 488 Neighbor Cache spoofing of another node therefore becomes trivial, as 489 any address may be proxy advertised to the SEND node, and overridden 490 only if the node is there to protect itself. When a node is present 491 to defend itself, it may also be difficult for the solicitor 492 determine the difference between a proxy-spoofing attack, and a 493 situation where a proxied device returns to a link and overrides 494 other proxy advertisers [RFC4861]. 496 3.1. CGA signatures and Proxy Neighbor Discovery 498 SEND defines one public-key and signature format for use with 499 Cryptographically Generated Addresses (CGAs) [RFC3972]. CGAs are 500 intended to tie address ownership to a particular Public/Private key 501 pair. 503 In SEND as defined today, Neighbor Discovery Messages (including the 504 IP Addresses from the IPv6 header) are signed with the same key used 505 to generate the CGA. This means that message recipients have proof 506 that the signer of the message owned the address. 508 When a proxy replaces the message source IPv6 address with its own 509 CGA, as per SEND specification the existing CGA option and RSA 510 signature option would need to be replaced with the proxy ones. Such 511 a message would be valid according to the SEND specification, weren't 512 the Target Address and the source IPv6 address of the Neighbor 513 Advertisement different [RFC3971]. 515 Additional authorization information may be needed to prove that the 516 proxy is indeed allowed to advertise for the target address, as is 517 described in Section 4. 519 3.2. Non-CGA signatures and Proxy Neighbor Discovery 521 Where a proxy retains the original source address in a proxied 522 message, existing SEND-CGA checks will fail, since fields within the 523 message will be changed. In order to achieve secured proxy Neighbor 524 discovery in this case, extended authorization mechanisms may be 525 needed for SEND. 527 SEND provides mechanisms for extension of SEND to non-CGA based 528 authorization. Messages are available for Authorization Delegation 529 Discovery, which is able to carry arbitrary PKIX/X.509 certificates 530 [RFC5280]. 532 There is, however, no specification of keying information option 533 formats analogous to the SEND CGA Option [RFC3971]. The existing 534 option allows a host to verify message integrity by specifying a key 535 and algorithm for digital signature, without providing authorization 536 via other mechanisms than CGA ownership. 538 The digital signature in SEND is transported in the RSA Signature 539 Option. As currently specified, the signature operation is performed 540 over a CGA Message type, and allows for CGA verification. Updating 541 the signature function to support non-CGA operations may be 542 necessary. 544 Within SEND, more advanced functions such as routing may be 545 authorized by certificate path verification using Authorization 546 Delegation Discovery. 548 With non-CGA signatures and authentication, certificate contents for 549 authorization may need to be determined, as outlined in Section 4. 551 While SEND provides for extensions to new non-CGA methods, existing 552 SEND hosts may silently discard messages with unverifiable RSA 553 signature options (Section 5.2.2 of [RFC3971]), if configured only to 554 accept SEND messages. In cases where unsecured Neighbor cache 555 entries are still accepted, messages from new algorithms will be 556 treated as unsecured. 558 3.3. Securing proxy DAD 560 Initiation of Proxy Neighbor Discovery also requires Duplicate 561 Address Detection (DAD) checks of the address [RFC4862]. These DAD 562 checks need to be performed by sending Neighbor Solicitations, from 563 the unspecified source address, with the target being the proxied 564 address. 566 In existing SEND procedures, the address which is used for CGA tests 567 on DAD NS is the target address. A Proxy which originates this 568 message while the proxied address owner is absent is unable to 569 generate a CGA-based signature for this address and must undertake 570 DAD with an unsecured NS. It may be possible that the proxy can 571 ensure that responding NA's are secured though. 573 Where bridge-like ND proxy operations are being performed, DAD NS's 574 may be copied from the original source, without modification 575 (considering they have an unspecified source address and contain no 576 link-layer address options) [RFC4389] 578 If non-CGA based signatures are available, then the signature over 579 the DAD NS doesn't need to have a CGA relationship to the Target 580 Address, but authorization for address configuration needs to be 581 shown using certificates. Where SEND-only nodes do not understand 582 the signature format. 584 3.4. Securing Router Advertisements 586 While Router Solicitations are protected in the same manner as 587 Neighbor Solicitations, Router Advertisements are typically secured 588 using certificates instead. Even though the mechanism for securing 589 RAs is different, the problems that arise due to the modification of 590 the L2 addresses are exactly the same. 592 4. Potential Approaches to Securing Proxy ND 594 SEND nodes already have the concept of delegated authority through 595 requiring external authorization of routers to perform their routing 596 and advertisement roles. The authorization of these routers takes 597 the form of delegation certificates. 599 Proxy Neighbor Discovery requires a delegation of authority on behalf 600 of the absent address owner, to the proxier. Without this authority, 601 other devices on the link have no reason to trust an advertiser. 603 For bridge-like proxies, it is assumed that there is no preexisting 604 trust between the host owning the address and the proxy. Therefore, 605 authority may necessarily be dynamic or based on topological roles 606 within the network [RFC4389]. 608 Existing trust relationships lend themselves to providing authority 609 for proxying in two alternative ways. 611 First, the SEND router authorization mechanisms described above 612 provide delegation from the organization responsible for routing in 613 an address domain, to the certified routers. It may be argued that 614 routers so certified may be trusted to provide service for nodes 615 which form part of a link's address range, but are themselves absent. 616 Devices which are proxies could either be granted the right to proxy 617 by the network's router, or be implicitly allowed to proxy by virtue 618 of being an authorized router. 620 Second, where the proxied address is itself a CGA, the holder of the 621 public and private keys is seen to be authoritative about the 622 address' use. If this address owner was able to sign the proxier's 623 address and public key information, it would be possible to identify 624 that the proxy is known and trusted by the CGA address owner for 625 proxy service. This method requires that the proxied address know or 626 learn the proxy's address and public key, and that the certificate 627 signed by the proxied node's is passed to the proxy, either while 628 they share the same link, or at a later stage. 630 In both methods, the original address owner's advertisements need to 631 override the proxy if it suddenly returns, and therefore timing and 632 replay protection from such messages need to be carefully considered. 634 4.1. Secured Proxy ND and Mobile IPv6 636 Mobile IPv6 has a security association between the Mobile Node and 637 Home Agent. The Mobile Node sends a Binding Update to the Home 638 Agent, to indicate that it is not at home. This implies that the 639 Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery 640 operations for its home address(es). 642 4.1.1. Mobile IPv6 and Router-based authorization 644 A secured Proxy Neighbor Advertisements proposal based on existing 645 router trust would require no explicit authorization signalling 646 between HA and MN to allow proxying. Hosts on the home link will 647 believe proxied advertisements solely because they come from a 648 trusted router. 650 Where the home agent operates as a router without explicit trust to 651 route from the advertising routing infrastructure (such as in a home, 652 with a router managed by an ISP), more explicit proxying 653 authorization may be required, as described in Section 4.2. 655 4.1.2. Mobile IPv6 and per-address authorization 657 Where proxy Neighbor Discovery is delegated by the MN to the home 658 agent, the MN needs to learn the public key for the Home Agent, so 659 that it can generate a certificate authorizing the public-private 660 key-pair to be used in proxying. It may conceivably either do this 661 using Certificate Path Solicitations over a home tunnel, over the 662 Internet, or Router Discovery while still at home [RFC3971] 663 [RFC3775]. 665 When sending its Binding Update to the HA, the MN would need to 666 provide a certificate containing the subject(proxy-HA)'s public key 667 and address, the issuer(MN)'s CGA and public key, and timestamps 668 indicating when the authority began and when it ends. This 669 certificate would need to be transmitted at binding time, possibly in 670 a Certificate Path Advertisement [RFC3971]. Messaging or such an 671 exchange mechanism would have to be developed. 673 4.1.3. Cryptographic based solutions 675 Specific cryptographic algorithms may help to allow trust between 676 entities of a same group. 678 This is the case, for example, with ring signature algorithms. These 679 algorithms generate a signature using the private key of any member 680 from the same group, but to verify the signature the public keys of 681 all group members are required. Applied to SEND, the addresses are 682 cryptographically generated using multiple public keys and the 683 Neighbor Discovery messages are signed with an RSA ring signature. 685 4.1.4. 'Point-to-Point' link model based solution 687 Another approach is to use the 'Point-to-Point' link model. 689 In this model, one prefix is provided per MN and only a MN and the HA 690 are on a same link. The consequence is the HA no longer needs to act 691 as ND Proxy. 693 One way to design such a solution is to use virtual interfaces, on 694 the MN and the HA, and a virtual link between them. Addresses 695 generated on the virtual interfaces will only be advertised on the 696 virtual link. For Mobile IPv6, this results in a virtual Home 697 Network where the MN will never come back. 699 4.2. Secured Proxy ND and Bridge-like proxies 701 In link-extension environments, the role of a proxy is more 702 explicitly separated from that of a router. In SEND, routers may 703 expect to be authorized by the routing infrastructure to advertise, 704 and provide this authority to hosts in order to allow them to change 705 forwarding state. 707 Proxies are not part of the traditional infrastructure of the 708 Internet, and hosts or routers may not have an explicit reason to 709 trust them, except that they can forward packets to regions where 710 otherwise they could not reach. 712 4.2.1. Authorization Delegation 714 If a proxy can convince a device that it should be trusted to perform 715 proxying function, it may require that device to vouch for its 716 operation in dealing with other devices. It may do this by receiving 717 a certificate, signed by the originating device that the proxy is 718 believed capable of proxying under certain circumstances. 720 This allows nodes receiving proxied Neighbor discovery packets to 721 quickly check if the proxy is authorized for the operation. There 722 are several bases for such trust, and requirements in proxied 723 environments, which are discussed below. 725 4.2.2. Unauthorized routers and proxies 727 Routers may be advertising on networks without any explicit 728 authorization, and SEND hosts will configure these if there are no 729 other options [RFC3971]. While proxies may similarly attempt to 730 advertise without authority, this provides no security for the 731 routing infrastructure. Any device can be setup as a SEND proxy/ 732 router so long as it signs its own ND messages from its CGA. 734 This may not help in the case that a proxy attempts to update 735 Neighbor cache entries for SEND node which moves between links, since 736 the SEND node's authority to advertise its own CGA address would not 737 be superseded by a proxy with no credentials. 739 4.2.3. Multiple proxy spans 741 Proxies may have multiple levels of nesting, which allow the network 742 to connect between non-adjacent segments. 744 In this case, authority delegated at one point will have to be 745 redelegated (possibly in a diluted form) to proxies further away from 746 the origin of the trust. 748 Trust ProxyA ProxyB Distant 749 Origin - T Node - D 751 +-----+ +-----+ 752 | | | | 753 +-----+ +-----+ +-----+ +-----+ 754 | | | | | | 755 ------------| |------------| |---------- 756 | | | | 757 +-----+ +-----+ 758 ==========> ==============> ==========> 759 Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B, 760 Deleg(A,T)) 762 Figure 7 764 As shown in Figure 7, the Proxy A needs to redelegate authority to 765 proxy for T to B, this allows it to proxy advertisements back to D, 766 which target T. 768 4.2.4. Routing Infrastructure Delegation 770 Where it is possible for the proxy to pre-establish trust with the 771 routing infrastructure, or at least to the local router, it may be 772 possible to authorize proxying as a function of routing within the 773 subnet. The router or CA may then be able to certify proxying for 774 only a subset of the prefixes which is itself certified for. 776 If a router or CA provides certification for a particular prefix, it 777 may be able to indicate that only proxying is supported, so that 778 Neighbor cache entries of routers connected to internet 779 infrastructure are never overridden by the proxy, if the router is 780 present on a segment. 782 Hosts understanding such certificates may allow authorized proxies 783 and routers to override host SEND/CGA when assuming proxy roles, if 784 the host is absent. 786 Proxy certificate signing could be done either dynamically (requiring 787 exchanges of identity and authorization information), or statically 788 when the network is set up. 790 4.2.5. Local Delegation 792 Where no trust tie exists between the authority which provides the 793 routing infrastructure and the provider of bridging and proxying 794 services, it may still be possible for SEND hosts to trust the 795 bridging provider to authorize proxying operations. 797 SEND itself requires that routers be able to show authorization, but 798 doesn't require routers to have a single trusted root. 800 A local bridging/proxying authority trust delegation may be possible. 801 It would be possible for this authority to pass out local use 802 certificates, allowing proxying on a specific subnet or subnets, with 803 a separate authorization chain to that for the routers with Internet 804 access. 806 This would require little modification to SEND, other than addition 807 of router based proxy authority (as in Section 4.2.4), and proxies 808 would in effect be treated as routers by SEND hosts [RFC3971]. 809 Distribution of keying and trust material for the initial bootstrap 810 of proxies would not be provided though (and may be static). 812 Within small domains, key management and distribution may be a 813 tractable problem, so long as these operations are are simple enough 814 to perform. 816 Since these domains may be small, it may be necessary to provide 817 certificate chains for trust anchors which weren't requested in 818 Certificate Path Solicitations, if the proxy doesn't have a trust 819 chain to any requested trust anchor. 821 This is akin to 'suggesting' an appropriate trusted root. It may 822 allow for user action in allowing trust extension when visiting 823 domains without ties to a global keying infrastructure. In this 824 case, the trust chain would have to start with a self-signed 825 certificate from the original CA. 827 4.2.6. Host delegation of trust to proxies 829 Unlike Mobile IPv6, for bridge-like proxied networks, there is no 830 existing security association upon which to transport proxying 831 authorization credentials. 833 Proxies need then to convince Neighbors to delegate proxy authority 834 to them, in order to proxy-advertise to nodes on different segments. 835 It will be difficult without additional information to distinguish 836 between legitimate proxies, and devices which have no need or right 837 to proxy (and may want to make two network segments to appear to be 838 connected). 840 When proxy advertising, proxies must not only identify that proxying 841 needs to occur, but provide proof that they are allowed to do so, so 842 that SEND Neighbor Cache entries may be updated. Unless the 843 authorization to update such entries is tied to address ownership 844 proofs from the proxied host or the verifiable routing 845 infrastructure, spoofing may occur. 847 When a host received a proxied Neighbor advertisement, it would be 848 necessary to check authorization in the same way that authorization 849 delegation discovery is performed in SEND. 851 Otherwise, certificate transport will be required to exchange 852 authorization between proxied nodes and proxies. 854 Proxies would have to be able to delegate this authorization to 855 downstream proxies, as described in Section 4.2.3. 857 Movement between segments could be controlled with increasing 858 certificate sequence numbers and timestamps. The timestamp of the 859 root authority (in this case, the CGA address owner) would be most 860 significant. Where ties exist, the shortest chain would supercede, 861 as this would indicate a proxy closer to the proxied node. 863 4.3. Proxying unsecured addresses 865 Where the original Neighbor discovery message is unsecured, there is 866 an argument for not providing secured proxy service for that node. 868 In both the Mobile IPv6 and extended networks cases, the node may 869 arrive back at the network and require other hosts to map their 870 existing Neighbor cache entry to the node's link-layer address. The 871 re-arriving node's overriding of link-layer address mappings will 872 occur without SEND in this case. 874 It is notable that without SEND protection any node may spoof the 875 arrival, and effectively steal service across an extended network. 876 This is the same as in the non-proxy case, and is not made 877 significantly worse by the proxy's presence (although the identity of 878 the attacker may be masked if source addresses are being replaced). 880 If signatures over the proxied messages were to be used, re-arrival 881 and override of the Neighbor cache entries would have to be allowed, 882 so the signatures would indicate that at least the proxy wasn't 883 spoofing (even if the original sender was). 885 For non-SEND/CGA routers, though, it may be possible for secured 886 proxies to send signed router advertisement messages, in order to 887 ensure that routers aren't spoofed, and subsequently switched to 888 being on different parts of the extended network. 890 This has problems in that the origin is again unsecured, and any node 891 on the network could spoof router advertisement for an unsecured 892 address. These spoofed messages may become almost indistinguishable 893 (except for the non-CGA origin address) from unspoofed messages from 894 SEND routers. 896 Given these complexities, the simplest method is to allow unsecured 897 devices to be spoofed from any port on the network, as is the case 898 today. 900 5. Two or more nodes defending the same address 902 The previous part of this document focused on the case where two 903 nodes defend the same address (i.e. the node and the proxy). But, 904 there are scenarios where two or more nodes are defending the same 905 address. This is at least the case for: 907 o Nodes having the same address, as the MAG's ingress link-local 908 address in PMIPv6 [I-D.ietf-netlmm-mn-ar-if]. 910 o Nodes having a common anycast address [RFC4291]. 912 The problem statement, described previously in this document, applies 913 for these cases and the issues are the same from a signalling point 914 of view. 916 Multicast addresses are not mentioned here because Neighbor Discovery 917 Protocol is not used for them. 919 In the first case, [I-D.ietf-netlmm-mn-ar-if] assumes that the 920 security material used by SEND (i.e. public-private key pair) is 921 shared between all the MAGs. For the second case, there is no 922 solution today. But, in the same way, it should be possible to 923 assume that the nodes having a common anycast address could also 924 share the security material. 926 It is important to notice that when many nodes defending the same 927 address are not in the same administrative domain (e.g. MAGs in 928 different administrative domains but in the same PMIPv6 domain 929 [RFC5213]), sharing the security material used by SEND may raise a 930 security issue. 932 6. IANA Considerations 934 No new options or messages are defined in this document. 936 7. Security Considerations 938 7.1. Router Trust Assumption 940 Router based authorization for Secured Proxy ND may occur without the 941 knowledge or consent of a device. It is susceptible to the 'Good 942 Router Goes Bad' attack described in [RFC3756]. 944 7.2. Certificate Transport 946 The certification delegation relies upon transfer of the new 947 credentials to the proxying HA in order to undertake ND proxy on its 948 behalf. Since the Binding cannot come into effect until DAD has 949 taken place, the delegation of the proxying authority necessarily 950 predates the return of the Binding Ack, as described in [RFC3775]. 951 In the above described case, the home tunnel which comes into 952 creation as part of the binding process may be required for 953 Certificate Path Solicitation or Advertisement transport [RFC3971]. 954 This constitutes a potential chicken-and-egg problem. Either 955 modifications to initial home binding semantics or certificate 956 transport are required. This may be trivial if signed, non- 957 repudiable certificates are sent in the clear between the MN's CoA 958 and the HA without being tunneled. 960 7.3. Timekeeping 962 All of the presented methods rely on accurate timekeeping on the 963 receiver nodes of Neighbor Discovery Timestamp Options. 965 For router-authorized proxy ND, a Neighbor may not know that a 966 particular ND message is replayed from the time when the proxied host 967 was still on-link, since the message's timestamp falls within the 968 valid timing window. Where the router advertises its secured proxy 969 NA, a subsequent replay of the old message will override the NC entry 970 created by the proxy. 972 Creating the Neighbor cache entry in this way, without reference to 973 accurate subsequent timing, may only be done once. Otherwise the 974 receiver will notice that the timestamp of the advertisement is old 975 or doesn't match. 977 One way of creating a sequence of replayable messages which have 978 timestamps likely to be accepted is to pretend to do an unsecured DAD 979 on the address each second while the MN is at home. The attacker 980 saves each DAD defence in a sequence. The granularity of SEND 981 timestamp matching is around 1 second, so the attacker has a set of 982 SEND NA's to advertise, starting at a particular timestamp, and valid 983 for as many seconds as the original NA gathering occurred. 985 This sequence may then be played against any host which doesn't have 986 a timestamp history for that MN, by tracking the number of seconds 987 elapsed since the initial transmission of the replayed NA to that 988 victim, and replaying the appropriate cached NA. 990 Where certificate based authorization of ND proxy is in use, the 991 origination/starting timestamp of the delegated authority may be used 992 to override a replayed (non-proxy) SEND NA, while also ensuring that 993 the Proxy NA's timestamp (provided by the proxy) is fresh. A 994 returning MN would advertise a more recent timestamp than the 995 delegated authority and thus override it. This method is therefore 996 not subject to the above attack, since the proxy advertisement's 997 certificate will have a timestamp greater than any replayed messages, 998 preventing it from being overridden. 1000 8. Acknowledgments 1002 James Kempf and Dave Thaler particularly contributed to work on this 1003 document. Contributions to discussion on this topic helped to 1004 develop this document. The authors would also like to thank Jari 1005 Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, 1006 Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen and 1007 Sheng Jiang for their comments and suggestions. 1009 Jean-Michel Combes is partly funded by MobiSEND, a research project 1010 supported by the French 'National Research Agency' (ANR). 1012 9. References 1014 9.1. Normative References 1016 [I-D.ietf-netlmm-mn-ar-if] 1017 Laganier, J., Narayanan, S., and P. McCann, "Interface 1018 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 1019 Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), 1020 February 2008. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1026 in IPv6", RFC 3775, June 2004. 1028 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1029 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1031 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1032 RFC 3972, March 2005. 1034 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1035 Architecture", RFC 4291, February 2006. 1037 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1038 RFC 4306, December 2005. 1040 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1041 Proxies (ND Proxy)", RFC 4389, April 2006. 1043 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1044 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1045 September 2007. 1047 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1048 Address Autoconfiguration", RFC 4862, September 2007. 1050 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1051 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1053 9.2. Informative References 1055 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1056 Discovery (ND) Trust Models and Threats", RFC 3756, 1057 May 2004. 1059 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1060 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1061 RFC 3963, January 2005. 1063 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, 1064 June 2008. 1066 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1067 Housley, R., and W. Polk, "Internet X.509 Public Key 1068 Infrastructure Certificate and Certificate Revocation List 1069 (CRL) Profile", RFC 5280, May 2008. 1071 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1072 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1073 Management", RFC 5380, October 2008. 1075 Authors' Addresses 1077 Greg Daley 1078 55 Pakington St 1079 Kew, Victoria 3101 1080 Australia 1082 Phone: +61 405 494849 1083 Email: hoskuld@hotmail.com 1085 Jean-Michel Combes 1086 Orange Labs 1087 38 rue du General Leclerc 1088 92794 Issy-les-Moulineaux Cedex 9 1089 France 1091 Email: jeanmichel.combes@gmail.com 1093 Suresh Krishnan 1094 Ericsson 1095 8400 Decarie Blvd. 1096 Town of Mount Royal 1097 QC Canada 1099 Email: Suresh.Krishnan@ericsson.com