idnits 2.17.1 draft-ietf-csi-sndp-prob-03.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 (October 18, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 csi Working Group J-M. Combes 3 Internet-Draft Orange Labs 4 Intended status: Informational S. Krishnan 5 Expires: April 21, 2010 Ericsson 6 G. Daley 7 NetStar Australia 8 October 18, 2009 10 Securing Neighbor Discovery Proxy Problem Statement 11 draft-ietf-csi-sndp-prob-03 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 April 21, 2010. 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 3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9 74 3.1. CGA signatures and Proxy Neighbor Discovery . . . . . . . 9 75 3.2. Non-CGA signatures and Proxy Neighbor Discovery . . . . . 10 76 3.3. Securing proxy DAD . . . . . . . . . . . . . . . . . . . . 11 77 3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11 78 4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12 79 4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 13 80 4.1.1. Mobile IPv6 and Router-based authorization . . . . . . 13 81 4.1.2. Mobile IPv6 and per-address authorization . . . . . . 13 82 4.1.3. Cryptographic based solutions . . . . . . . . . . . . 13 83 4.1.4. 'Point-to-Point' link model based solution . . . . . . 14 84 4.2. Secured Proxy ND and Bridge-like proxies . . . . . . . . . 14 85 4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14 86 4.2.2. Unauthorized routers and proxies . . . . . . . . . . . 14 87 4.2.3. Multiple proxy spans . . . . . . . . . . . . . . . . . 15 88 4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15 89 4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16 90 4.2.6. Host delegation of trust to proxies . . . . . . . . . 17 91 4.3. Proxying unsecured addresses . . . . . . . . . . . . . . . 17 92 5. Two or more nodes defending the same address . . . . . . . . . 18 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 7.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19 96 7.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19 97 7.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19 98 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery 107 [RFC4861]. It is used in networks where a prefix has to span 108 multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in 109 Mobile IPv6 based protocols like NEMO [RFC3963], FMIPv6 [RFC5568] or 110 HMIPv6 [RFC5380]) and in IKEv2 [RFC4306]. It allows a device which 111 is not physically present on a link to have another advertise its 112 presence, and forward on packets to the off-link device. 114 Neighbor Discovery Proxy relies upon another device, the proxy, to 115 monitor for Neighbor Solicitations (NS), and answer with Neighbor 116 Advertisements (NA). These proxy Neighbor Advertisements direct data 117 traffic through the proxy. Proxied traffic is then forwarded on to 118 the end destination. 120 2. Scenarios 122 This section describes the different scenarios where the interaction 123 between SEND and ND-Proxy raises issues. 125 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy 127 When moving in the Internet, the aim of IPv6 mobility is to allow a 128 device continued packet delivery, whether present on its home network 129 or not. The following text is focused on Mobile IPv6 but the issue 130 raised by the interaction between SEND and ND-Proxy is the same with 131 Mobile IPv6 based protocols (e.g. NEMO, HMIPv6). 133 For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing 134 sessions going or to allow new sessions even when one leaves the home 135 network. 137 In order to continue existing sessions, the Proxy (i.e. the Home 138 Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes 139 multicast address on the home link as specified [RFC3775]. 141 For new sessions, the Proxy, which listens to the MN's address 142 responds with a Neighbor Advertisement which originates at its own 143 IPv6 address and has the proxy's address as the Target Link-Layer 144 Address, but contains the absent mobile in the Target Address field 145 of the Neighbor Advertisement. In this case, no solicitations are 146 proxied, as the advertisements originate within the proxy itself. 148 As seen in Figure 1, solicitors send a multicast solicitation to the 149 solicited nodes multicast address (based on the unicast address) of 150 the absent node (mobile node that is away from the home link). 152 Absent Mobile Proxy Solicitor 154 NS:SL3=S,DL3=Sol(A),TA=A 155 +-----+ SL2=s,DL2=sol(a),SLL=s 156 | |<================ 157 | | 158 | |================> 159 +-----+ NA:SL3=P,DL3=S,TA=A, 160 SL2=p,DL2=s,TLL=p 162 Legend: 163 SL3: Source IPv6 Address NS: Neighbor Solicitation 164 DL3: Destination IPv6 Address NA: Neighbor Advertisement 165 SL2: Source Link-Layer Address RS: Router Solicitation 166 DL2: Destination Link-Layer Address RA: Router Advertisement 167 TA: Target Address 168 SLL/TLL: Source/Target Link-Layer Address Option 170 Figure 1 172 While at home, if the MN has configured Cryptographically Generated 173 Addresses (CGAs) [RFC3972], it can secure establishment by its on- 174 link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using 175 Secure Neighbor Discovery (SEND) [RFC3971]. SEND security requires a 176 node sending Neighbor Advertisments for a given address to be in 177 possession of the public-private key pair that generated the address. 179 When a MN moves away from the home link, a proxy has to undertake 180 Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, 181 the role of the proxy is undertaken by the Home Agent. While the 182 Home agent has a security association with the MN, it does not have 183 access to the public-private key pair used to generate the MN's CGA. 184 Thus the Home Agent acting as an ND proxy cannot use SEND for the 185 address it is proxying [RFC3971]. 187 When a MN moves from the home network to a visited network, the proxy 188 will have to override the MN's existing Neighbor Cache Entries which 189 are flagged as secure [RFC3971]. This is needed for the Home Agent 190 to intercept traffic sent on-link to the MN that would otherwise be 191 sent to the MN's link layer address. 193 With the current SEND specification, any solicitation or 194 advertisement sent by the proxy will be unsecure and thus will not be 195 able to update the MN's NCE for the home address because it is 196 flagged as secured. These existing Neighbor Cache Entries will only 197 time-out after Neighbor Unreachability Detection [RFC4861] concludes 198 the Home Address is unreachable at the link layer recorded in the 199 NCE. 201 Where secured proxy services are not able to be provided, a proxy's 202 advertisement may be overridden by a rogue proxy without the 203 receiving host realizing that an attack has occurred. This is 204 identical to what happens in a network where SEND is not deployed. 206 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 208 This scenario is a sub-case from the previous one. The IPv6 node 209 will never be on the link where the ND messages are proxied. This is 210 the case with IKEv2 [RFC4306]. When a node needs an IP address in 211 the network protected by a security gateway, the security gateway 212 assigns an address dynamically using Configuration Payload during 213 IKEv2 exchanges. The security gateway will have to proxy ND messages 214 in order to be able to intercept messages sent to the node and to 215 tunnel them to the node. 217 2.3. Bridge-like ND proxies 219 The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 220 method by which multiple link layer segments are bridged into a 221 single segment and specifies the IP-layer support that enables 222 bridging under these circumstances. The proxy in this case forwards 223 messages while modifying their source and destination MAC addresses, 224 and rewrites their Link-Layer Address Options, solicited, and 225 override flags. 227 This rewriting is incompatible with SEND signed messages for a number 228 of reasons: 230 o Rewriting elements within the message will break the digital 231 signature. 233 o The source IP address of the packets is the packet's origin, not 234 the proxy's address. The proxy is unable to generate another 235 signature for this address, as it doesn't have the CGA private key 236 [RFC3971]. 238 Thus, proxy modification of SEND solicitations may require sharing of 239 credentials between the proxied node and the proxying node or 240 creation of new options with proxying capabilities. 242 While bridge-like ND proxies aim to provide as little interference 243 with ND mechanisms as possible, SEND has been designed to prevent 244 modification or spoofing of advertisements by devices on the link. 246 Of particular note is the fact that ND Proxy performs a different 247 kind of proxy Neighbor discovery to Mobile IPv6 [RFC3775] [RFC4389]. 248 The Mobile IPv6 RFC specifies that the Home Agent as proxy sends 249 Neighbor Advertisements from its own address with the Target Address 250 set to the absent Mobile Node's address. The Home Agent's own link- 251 layer address is placed in the Target Link-Layer address option 252 [RFC3775]. On the other hand, ND Proxy resends messages containing 253 their original address, even after modification (i.e. the IP source 254 address remains the same)[RFC4389]. Figure 2 describes packet 255 formats for proxy Neighbor solicitation and advertisement as 256 specified by the specification. 258 Advertisor Proxy Solicitor 260 NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A, 261 SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s 262 <==================| |<================ 263 | | 264 ==================>| |================> 265 NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A 266 SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p 268 Legend: 269 SL3: Source IPv6 Address NS: Neighbor Solicitation 270 DL3: Destination IPv6 Address NA: Neighbor Advertisement 271 SL2: Source Link-Layer Address 272 DL2: Destination Link-Layer Address 273 TA: Target Address 274 SLL/TLL: Source/Target Link-Layer Address Option 276 Figure 2 278 In order to use the same security procedures for both ND Proxy and 279 Mobile IPv6, changes may be needed to the proxying procedures in 280 [RFC4389], as well as changes to SEND. 282 An additional (and undocumented) requirement for bridge-like proxying 283 is the operation of router discovery. Router Discovery packets may 284 similarly modify Neighbor cache state, and require protection from 285 SEND. 287 In Figure 3, the router discovery messages propagate without 288 modification to the router address, but elements within the message 289 change. This is consistent with the description of Neighbor 290 Discovery above. 292 Advertisor Proxy Solicitor 294 RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR, 295 SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s 296 <==================| |<================ 297 | | 298 ==================>| |================> 299 RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S, 300 SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p 302 Legend: 303 SL3: Source IPv6 Address RS: Router Solicitation 304 DL3: Destination IPv6 Address RA: Router Advertisement 305 SL2: Source Link-Layer Address 306 DL2: Destination Link-Layer Address 307 TA: Target Address 308 SLL/TLL: Source/Target Link-Layer Address Option 310 Figure 3 312 Once again, these messages may not be signed with a CGA signature by 313 the proxy, because it does not own the source address. 315 Additionally, Authorization Delegation Discovery messages need to be 316 exchanged for bridge-like ND proxies to prove their authority to 317 forward. Unless the proxy receives explicit authority to act as a 318 router, or the router knows of its presence, no authorization may be 319 made. This explicit authorization requirement may be at odds with 320 the zero configuration goal of ND proxying [RFC4389]. 322 An alternative (alluded to in an appendix of ND Proxy) suggests that 323 the proxy send Router Advertisements (RA) from its own address. As 324 described by ND Proxy, this is insufficient for providing proxied 325 Neighbor Advertisement service, but may be matched with Neighbor 326 solicitation and advertisement services using the proxy's source 327 address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This 328 means that all router and Neighbor advertisements would come from the 329 proxied address, but may contain a target address which allows 330 proxied Neighbor presence to be established with peers on other 331 segments. Router Discovery in this case has the identity of the 332 original (non-proxy) router completely obscured in router discovery 333 messages. 335 The resultant proxy messages would have no identifying information 336 indicating their origin, which means that proxying between multiple 337 links would require state to be stored on outstanding solicitations 338 (effectively a ND only NAT). This level of state storage may be 339 undesirable. 341 Mobile IPv6 does not experience this issue when supplying its own 342 address, since ND messages are never forwarded on to the absent node 343 (the Home Agent having sufficient information to respond itself). 345 Authorization from a router may still be required for Router 346 Advertisement, and will be discussed in Section 4.2. 348 3. Proxy Neighbor Discovery and SEND 350 There are currently no existing secured Neighbor Discovery procedures 351 for proxied addresses, and all Neighbor Advertisements from SEND 352 nodes are required to have equal source and target addresses, and be 353 signed by the transmitter (section 7.4 of [RFC3971]). 355 Signatures over SEND messages are required to be applied on the CGA 356 source address of the message, and there is no way of indicating that 357 a message is proxied. 359 Even if the message is able to be transmitted from the original 360 owner, differences in link-layer addressing and options require 361 modification by a proxy. If a message is signed with a CGA-based 362 signature, the proxy is unable to regenerate a signature over the 363 changed message as it lacks the keying material. 365 Therefore, a router wishing to provide proxy Neighbor Advertisement 366 service can not use existing SEND procedures on those messages. 368 A host may wish to establish a session with a device which is not on- 369 link but is proxied. As a SEND host, it prefers to create Neighbor 370 cache entries using secured procedures. Since SEND signatures cannot 371 be applied to an existing proxy Neighbor Advertisement, it must 372 accept non-SEND advertisements in order to receive proxy Neighbor 373 Advertisements. 375 Neighbor Cache spoofing of another node therefore becomes trivial, as 376 any address may be proxy advertised to the SEND node, and overridden 377 only if the node is there to protect itself. When a node is present 378 to defend itself, it may also be difficult for the solicitor 379 determine the difference between a proxy-spoofing attack, and a 380 situation where a proxied device returns to a link and overrides 381 other proxy advertisers [RFC4861]. 383 3.1. CGA signatures and Proxy Neighbor Discovery 385 SEND defines one public-key and signature format for use with 386 Cryptographically Generated Addresses (CGAs) [RFC3972]. CGAs are 387 intended to tie address ownership to a particular Public/Private key 388 pair. 390 In SEND as defined today, Neighbor Discovery Messages (including the 391 IP Addresses from the IPv6 header) are signed with the same key used 392 to generate the CGA. This means that message recipients have proof 393 that the signer of the message owned the address. 395 When a proxy replaces the message source IPv6 address with its own 396 CGA, as per SEND specification the existing CGA option and RSA 397 signature option would need to be replaced with the proxy ones. Such 398 a message would be valid according to the SEND specification, weren't 399 the Target Address and the source IPv6 address of the Neighbor 400 Advertisement different [RFC3971]. 402 Additional authorization information may be needed to prove that the 403 proxy is indeed allowed to advertise for the target address, as is 404 described in Section 4. 406 3.2. Non-CGA signatures and Proxy Neighbor Discovery 408 Where a proxy retains the original source address in a proxied 409 message, existing SEND-CGA checks will fail, since fields within the 410 message will be changed. In order to achieve secured proxy Neighbor 411 discovery in this case, extended authorization mechanisms may be 412 needed for SEND. 414 SEND provides mechanisms for extension of SEND to non-CGA based 415 authorization. Messages are available for Authorization Delegation 416 Discovery, which is able to carry arbitrary PKIX/X.509 certificates 417 [RFC5280]. 419 There is, however, no specification of keying information option 420 formats analogous to the SEND CGA Option [RFC3971]. The existing 421 option allows a host to verify message integrity by specifying a key 422 and algorithm for digital signature, without providing authorization 423 via other mechanisms than CGA ownership. 425 The digital signature in SEND is transported in the RSA Signature 426 Option. As currently specified, the signature operation is performed 427 over a CGA Message type, and allows for CGA verification. Updating 428 the signature function to support non-CGA operations may be 429 necessary. 431 Within SEND, more advanced functions such as routing may be 432 authorized by certificate path verification using Authorization 433 Delegation Discovery. 435 With non-CGA signatures and authentication, certificate contents for 436 authorization may need to be determined, as outlined in Section 4. 438 While SEND provides for extensions to new non-CGA methods, existing 439 SEND hosts may silently discard messages with unverifiable RSA 440 signature options (Section 5.2.2 of [RFC3971]), if configured only to 441 accept SEND messages. In cases where unsecured Neighbor cache 442 entries are still accepted, messages from new algorithms will be 443 treated as unsecured. 445 3.3. Securing proxy DAD 447 Initiation of Proxy Neighbor Discovery also requires Duplicate 448 Address Detection (DAD) checks of the address [RFC4862]. These DAD 449 checks need to be performed by sending Neighbor Solicitations, from 450 the unspecified source address, with the target being the proxied 451 address. 453 In existing SEND procedures, the address which is used for CGA tests 454 on DAD NS is the target address. A Proxy which originates this 455 message while the proxied address owner is absent is unable to 456 generate a CGA-based signature for this address and must undertake 457 DAD with an unsecured NS. It may be possible that the proxy can 458 ensure that responding NA's are secured though. 460 Where bridge-like ND proxy operations are being performed, DAD NS's 461 may be copied from the original source, without modification 462 (considering they have an unspecified source address and contain no 463 link-layer address options) [RFC4389] 465 If non-CGA based signatures are available, then the signature over 466 the DAD NS doesn't need to have a CGA relationship to the Target 467 Address, but authorization for address configuration needs to be 468 shown using certificates. 470 In case there is a DAD collision between two SEND nodes on different 471 interfaces of the proxy, it is possible that the proxy may not have 472 the authority to modify the NA defending the address. In this case 473 the proxy needs to still modify the NA and pass it onto the other 474 interfaces even if it will fail SEND verification on the receiving 475 node. 477 3.4. Securing Router Advertisements 479 While Router Solicitations are protected in the same manner as 480 Neighbor Solicitations, the security for Router Advertisements is 481 mainly based on the use of certificates. Even though the mechanism 482 for securing RAs is different, the problems that arise due to the 483 modification of the L2 addresses are exactly the same: the proxy 484 needs to have the right security material (e.g. certificate) to sign 485 the RA messages after modification. 487 4. Potential Approaches to Securing Proxy ND 489 SEND nodes already have the concept of delegated authority through 490 requiring external authorization of routers to perform their routing 491 and advertisement roles. The authorization of these routers takes 492 the form of delegation certificates. 494 Proxy Neighbor Discovery requires a delegation of authority on behalf 495 of the absent address owner, to the proxier. Without this authority, 496 other devices on the link have no reason to trust an advertiser. 498 For bridge-like proxies, it is assumed that there is no preexisting 499 trust between the host owning the address and the proxy. Therefore, 500 authority may necessarily be dynamic or based on topological roles 501 within the network [RFC4389]. 503 Existing trust relationships lend themselves to providing authority 504 for proxying in two alternative ways. 506 First, the SEND router authorization mechanisms described above 507 provide delegation from the organization responsible for routing in 508 an address domain, to the certified routers. It may be argued that 509 routers so certified may be trusted to provide service for nodes 510 which form part of a link's address range, but are themselves absent. 511 Devices which are proxies could either be granted the right to proxy 512 by the network's router, or be implicitly allowed to proxy by virtue 513 of being an authorized router. 515 Second, where the proxied address is itself a CGA, the holder of the 516 public and private keys is seen to be authoritative about the 517 address' use. If this address owner was able to sign the proxier's 518 address and public key information, it would be possible to identify 519 that the proxy is known and trusted by the CGA address owner for 520 proxy service. This method requires that the proxied address know or 521 learn the proxy's address and public key, and that the certificate 522 signed by the proxied node's is passed to the proxy, either while 523 they share the same link, or at a later stage. 525 In both methods, the original address owner's advertisements need to 526 override the proxy if it suddenly returns, and therefore timing and 527 replay protection from such messages need to be carefully considered. 529 4.1. Secured Proxy ND and Mobile IPv6 531 Mobile IPv6 has a security association between the Mobile Node and 532 Home Agent. The Mobile Node sends a Binding Update to the Home 533 Agent, to indicate that it is not at home. This implies that the 534 Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery 535 operations for its home address(es). 537 4.1.1. Mobile IPv6 and Router-based authorization 539 A secured Proxy Neighbor Advertisements proposal based on existing 540 router trust would require no explicit authorization signalling 541 between HA and MN to allow proxying. Hosts on the home link will 542 believe proxied advertisements solely because they come from a 543 trusted router. 545 Where the home agent operates as a router without explicit trust to 546 route from the advertising routing infrastructure (such as in a home, 547 with a router managed by an ISP), more explicit proxying 548 authorization may be required, as described in Section 4.2. 550 4.1.2. Mobile IPv6 and per-address authorization 552 Where proxy Neighbor Discovery is delegated by the MN to the home 553 agent, the MN needs to learn the public key for the Home Agent, so 554 that it can generate a certificate authorizing the public-private 555 key-pair to be used in proxying. It may conceivably either do this 556 using Certificate Path Solicitations over a home tunnel, over the 557 Internet, or Router Discovery while still at home [RFC3971] 558 [RFC3775]. 560 When sending its Binding Update to the HA, the MN would need to 561 provide a certificate containing the subject(proxy-HA)'s public key 562 and address, the issuer(MN)'s CGA and public key, and timestamps 563 indicating when the authority began and when it ends. This 564 certificate would need to be transmitted at binding time, possibly in 565 a Certificate Path Advertisement [RFC3971]. Messaging or such an 566 exchange mechanism would have to be developed. 568 4.1.3. Cryptographic based solutions 570 Specific cryptographic algorithms may help to allow trust between 571 entities of a same group. 573 This is the case, for example, with ring signature algorithms. These 574 algorithms generate a signature using the private key of any member 575 from the same group, but to verify the signature the public keys of 576 all group members are required. Applied to SEND, the addresses are 577 cryptographically generated using multiple public keys and the 578 Neighbor Discovery messages are signed with an RSA ring signature. 580 4.1.4. 'Point-to-Point' link model based solution 582 Another approach is to use the 'Point-to-Point' link model. 584 In this model, one prefix is provided per MN and only a MN and the HA 585 are on a same link. The consequence is the HA no longer needs to act 586 as ND Proxy. 588 One way to design such a solution is to use virtual interfaces, on 589 the MN and the HA, and a virtual link between them. Addresses 590 generated on the virtual interfaces will only be advertised on the 591 virtual link. For Mobile IPv6, this results in a virtual Home 592 Network where the MN will never come back. 594 4.2. Secured Proxy ND and Bridge-like proxies 596 In link-extension environments, the role of a proxy is more 597 explicitly separated from that of a router. In SEND, routers may 598 expect to be authorized by the routing infrastructure to advertise, 599 and provide this authority to hosts in order to allow them to change 600 forwarding state. 602 Proxies are not part of the traditional infrastructure of the 603 Internet, and hosts or routers may not have an explicit reason to 604 trust them, except that they can forward packets to regions where 605 otherwise they could not reach. 607 4.2.1. Authorization Delegation 609 If a proxy can convince a device that it should be trusted to perform 610 proxying function, it may require that device to vouch for its 611 operation in dealing with other devices. It may do this by receiving 612 a certificate, signed by the originating device that the proxy is 613 believed capable of proxying under certain circumstances. 615 This allows nodes receiving proxied Neighbor discovery packets to 616 quickly check if the proxy is authorized for the operation. There 617 are several bases for such trust, and requirements in proxied 618 environments, which are discussed below. 620 4.2.2. Unauthorized routers and proxies 622 Routers may be advertising on networks without any explicit 623 authorization, and SEND hosts will configure these if there are no 624 other options [RFC3971]. While proxies may similarly attempt to 625 advertise without authority, this provides no security for the 626 routing infrastructure. Any device can be setup as a SEND proxy/ 627 router so long as it signs its own ND messages from its CGA. 629 This may not help in the case that a proxy attempts to update 630 Neighbor cache entries for SEND node which moves between links, since 631 the SEND node's authority to advertise its own CGA address would not 632 be superseded by a proxy with no credentials. 634 4.2.3. Multiple proxy spans 636 Proxies may have multiple levels of nesting, which allow the network 637 to connect between non-adjacent segments. 639 In this case, authority delegated at one point will have to be 640 redelegated (possibly in a diluted form) to proxies further away from 641 the origin of the trust. 643 Trust ProxyA ProxyB Distant 644 Origin - T Node - D 646 +-----+ +-----+ 647 | | | | 648 +-----+ +-----+ +-----+ +-----+ 649 | | | | | | 650 ------------| |------------| |---------- 651 | | | | 652 +-----+ +-----+ 653 ==========> ==============> ==========> 654 Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B, 655 Deleg(A,T)) 657 Figure 4 659 As shown in Figure 4, the Proxy A needs to redelegate authority to 660 proxy for T to B, this allows it to proxy advertisements back to D, 661 which target T. 663 4.2.4. Routing Infrastructure Delegation 665 Where it is possible for the proxy to pre-establish trust with the 666 routing infrastructure, or at least to the local router, it may be 667 possible to authorize proxying as a function of routing within the 668 subnet. The router or CA may then be able to certify proxying for 669 only a subset of the prefixes which is itself certified for. 671 If a router or CA provides certification for a particular prefix, it 672 may be able to indicate that only proxying is supported, so that 673 Neighbor cache entries of routers connected to internet 674 infrastructure are never overridden by the proxy, if the router is 675 present on a segment. 677 Hosts understanding such certificates may allow authorized proxies 678 and routers to override host SEND/CGA when assuming proxy roles, if 679 the host is absent. 681 Proxy certificate signing could be done either dynamically (requiring 682 exchanges of identity and authorization information), or statically 683 when the network is set up. 685 4.2.5. Local Delegation 687 Where no trust tie exists between the authority which provides the 688 routing infrastructure and the provider of bridging and proxying 689 services, it may still be possible for SEND hosts to trust the 690 bridging provider to authorize proxying operations. 692 SEND itself requires that routers be able to show authorization, but 693 doesn't require routers to have a single trusted root. 695 A local bridging/proxying authority trust delegation may be possible. 696 It would be possible for this authority to pass out local use 697 certificates, allowing proxying on a specific subnet or subnets, with 698 a separate authorization chain to that for the routers with Internet 699 access. 701 This would require little modification to SEND, other than addition 702 of router based proxy authority (as in Section 4.2.4), and proxies 703 would in effect be treated as routers by SEND hosts [RFC3971]. 704 Distribution of keying and trust material for the initial bootstrap 705 of proxies would not be provided though (and may be static). 707 Within small domains, key management and distribution may be a 708 tractable problem, so long as these operations are simple enough to 709 perform. 711 Since these domains may be small, it may be necessary to provide 712 certificate chains for trust anchors which weren't requested in 713 Certificate Path Solicitations, if the proxy doesn't have a trust 714 chain to any requested trust anchor. 716 This is akin to 'suggesting' an appropriate trusted root. It may 717 allow for user action in allowing trust extension when visiting 718 domains without ties to a global keying infrastructure. In this 719 case, the trust chain would have to start with a self-signed 720 certificate from the original CA. 722 4.2.6. Host delegation of trust to proxies 724 Unlike Mobile IPv6, for bridge-like proxied networks, there is no 725 existing security association upon which to transport proxying 726 authorization credentials. 728 Proxies need then to convince Neighbors to delegate proxy authority 729 to them, in order to proxy-advertise to nodes on different segments. 730 It will be difficult without additional information to distinguish 731 between legitimate proxies, and devices which have no need or right 732 to proxy (and may want to make two network segments to appear to be 733 connected). 735 When proxy advertising, proxies must not only identify that proxying 736 needs to occur, but provide proof that they are allowed to do so, so 737 that SEND Neighbor Cache entries may be updated. Unless the 738 authorization to update such entries is tied to address ownership 739 proofs from the proxied host or the verifiable routing 740 infrastructure, spoofing may occur. 742 When a host received a proxied Neighbor advertisement, it would be 743 necessary to check authorization in the same way that authorization 744 delegation discovery is performed in SEND. 746 Otherwise, certificate transport will be required to exchange 747 authorization between proxied nodes and proxies. 749 Proxies would have to be able to delegate this authorization to 750 downstream proxies, as described in Section 4.2.3. 752 Movement between segments could be controlled with increasing 753 certificate serial numbers and timestamps. The timestamp of the root 754 authority (in this case, the CGA address owner) would be most 755 significant. Where ties exist, the shortest chain would supercede, 756 as this would indicate a proxy closer to the proxied node. 758 4.3. Proxying unsecured addresses 760 Where the original Neighbor discovery message is unsecured, there is 761 an argument for not providing secured proxy service for that node. 763 In both the Mobile IPv6 and extended networks cases, the node may 764 arrive back at the network and require other hosts to map their 765 existing Neighbor cache entry to the node's link-layer address. The 766 re-arriving node's overriding of link-layer address mappings will 767 occur without SEND in this case. 769 It is notable that without SEND protection any node may spoof the 770 arrival, and effectively steal service across an extended network. 771 This is the same as in the non-proxy case, and is not made 772 significantly worse by the proxy's presence (although the identity of 773 the attacker may be masked if source addresses are being replaced). 775 If signatures over the proxied messages were to be used, re-arrival 776 and override of the Neighbor cache entries would have to be allowed, 777 so the signatures would indicate that at least the proxy wasn't 778 spoofing (even if the original sender was). 780 For non-SEND/CGA routers, though, it may be possible for secured 781 proxies to send signed router advertisement messages, in order to 782 ensure that routers aren't spoofed, and subsequently switched to 783 being on different parts of the extended network. 785 This has problems in that the origin is again unsecured, and any node 786 on the network could spoof router advertisement for an unsecured 787 address. These spoofed messages may become almost indistinguishable 788 (except for the non-CGA origin address) from unspoofed messages from 789 SEND routers. 791 Given these complexities, the simplest method is to allow unsecured 792 devices to be spoofed from any port on the network, as is the case 793 today. 795 5. Two or more nodes defending the same address 797 The previous part of this document focused on the case where two 798 nodes defend the same address (i.e. the node and the proxy). But, 799 there are scenarios where two or more nodes are defending the same 800 address. This is at least the case for: 802 o Nodes having the same address, as the MAG's ingress link-local 803 address in PMIPv6 [RFC5213]. 805 o Nodes having a common anycast address [RFC4291]. 807 The problem statement, described previously in this document, applies 808 for these cases and the issues are the same from a signalling point 809 of view. 811 Multicast addresses are not mentioned here because Neighbor Discovery 812 Protocol is not used for them. 814 In the first case, [RFC5213] assumes that the security material used 815 by SEND (i.e. public-private key pair) is shared between all the 816 MAGs. For the second case, there is no solution today. But, in the 817 same way, it should be possible to assume that the nodes having a 818 common anycast address could also share the security material. 820 It is important to notice that when many nodes defending the same 821 address are not in the same administrative domain (e.g. MAGs in 822 different administrative domains but in the same PMIPv6 domain 823 [RFC5213]), sharing the security material used by SEND may raise a 824 security issue. 826 6. IANA Considerations 828 No new options or messages are defined in this document. 830 7. Security Considerations 832 7.1. Router Trust Assumption 834 Router based authorization for Secured Proxy ND may occur without the 835 knowledge or consent of a device. It is susceptible to the 'Good 836 Router Goes Bad' attack described in [RFC3756]. 838 7.2. Certificate Transport 840 The certification delegation relies upon transfer of the new 841 credentials to the proxying HA in order to undertake ND proxy on its 842 behalf. Since the Binding cannot come into effect until DAD has 843 taken place, the delegation of the proxying authority necessarily 844 predates the return of the Binding Ack, as described in [RFC3775]. 845 In the above described case, the home tunnel which comes into 846 creation as part of the binding process may be required for 847 Certificate Path Solicitation or Advertisement transport [RFC3971]. 848 This constitutes a potential chicken-and-egg problem. Either 849 modifications to initial home binding semantics or certificate 850 transport are required. This may be trivial if signed, non- 851 repudiable certificates are sent in the clear between the MN's CoA 852 and the HA without being tunneled. 854 7.3. Timekeeping 856 All of the presented methods rely on accurate timekeeping on the 857 receiver nodes of Neighbor Discovery Timestamp Options. 859 For router-authorized proxy ND, a Neighbor may not know that a 860 particular ND message is replayed from the time when the proxied host 861 was still on-link, since the message's timestamp falls within the 862 valid timing window. Where the router advertises its secured proxy 863 NA, a subsequent replay of the old message will override the NC entry 864 created by the proxy. 866 Creating the Neighbor cache entry in this way, without reference to 867 accurate subsequent timing, may only be done once. Otherwise the 868 receiver will notice that the timestamp of the advertisement is old 869 or doesn't match. 871 One way of creating a sequence of replayable messages which have 872 timestamps likely to be accepted is to pretend to do an unsecured DAD 873 on the address each second while the MN is at home. The attacker 874 saves each DAD defence in a sequence. The granularity of SEND 875 timestamp matching is around 1 second, so the attacker has a set of 876 SEND NA's to advertise, starting at a particular timestamp, and valid 877 for as many seconds as the original NA gathering occurred. 879 This sequence may then be played against any host which doesn't have 880 a timestamp history for that MN, by tracking the number of seconds 881 elapsed since the initial transmission of the replayed NA to that 882 victim, and replaying the appropriate cached NA. 884 Where certificate based authorization of ND proxy is in use, the 885 origination/starting timestamp of the delegated authority may be used 886 to override a replayed (non-proxy) SEND NA, while also ensuring that 887 the Proxy NA's timestamp (provided by the proxy) is fresh. A 888 returning MN would advertise a more recent timestamp than the 889 delegated authority and thus override it. This method is therefore 890 not subject to the above attack, since the proxy advertisement's 891 certificate will have a timestamp greater than any replayed messages, 892 preventing it from being overridden. 894 8. Acknowledgments 896 James Kempf and Dave Thaler particularly contributed to work on this 897 document. Contributions to discussion on this topic helped to 898 develop this document. The authors would also like to thank Jari 899 Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, 900 Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen and 901 Sheng Jiang for their comments and suggestions. 903 Jean-Michel Combes is partly funded by MobiSEND, a research project 904 supported by the French 'National Research Agency' (ANR). 906 9. References 907 9.1. Normative References 909 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 910 in IPv6", RFC 3775, June 2004. 912 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 913 Neighbor Discovery (SEND)", RFC 3971, March 2005. 915 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 916 RFC 3972, March 2005. 918 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 919 Architecture", RFC 4291, February 2006. 921 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 922 RFC 4306, December 2005. 924 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 925 Proxies (ND Proxy)", RFC 4389, April 2006. 927 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 928 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 929 September 2007. 931 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 932 Address Autoconfiguration", RFC 4862, September 2007. 934 9.2. Informative References 936 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 937 Discovery (ND) Trust Models and Threats", RFC 3756, 938 May 2004. 940 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 941 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 942 RFC 3963, January 2005. 944 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 945 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 947 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 948 Housley, R., and W. Polk, "Internet X.509 Public Key 949 Infrastructure Certificate and Certificate Revocation List 950 (CRL) Profile", RFC 5280, May 2008. 952 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 953 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 954 Management", RFC 5380, October 2008. 956 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 957 July 2009. 959 Authors' Addresses 961 Jean-Michel Combes 962 Orange Labs 963 38 rue du General Leclerc 964 92794 Issy-les-Moulineaux Cedex 9 965 France 967 Email: jeanmichel.combes@gmail.com 969 Suresh Krishnan 970 Ericsson 971 8400 Decarie Blvd. 972 Town of Mount Royal 973 QC Canada 975 Email: Suresh.Krishnan@ericsson.com 977 Greg Daley 978 NetStar Australia 979 Level 9/636 St Kilda Road 980 Melbourne, Victoria 3004 981 Australia 983 Phone: +61 401 772 770 984 Email: hoskuld@hotmail.com