idnits 2.17.1 draft-ietf-csi-sndp-prob-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (January 22, 2010) is 5207 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: July 26, 2010 Ericsson 6 G. Daley 7 NetStar Australia 8 January 22, 2010 10 Securing Neighbor Discovery Proxy: Problem Statement 11 draft-ietf-csi-sndp-prob-04 13 Abstract 15 Neighbor Discovery Proxies are used to provide an address presence on 16 a link for nodes that are no longer present on the link. They allow 17 a node to receive packets directed at its address by allowing another 18 device to perform neighbor discovery operations on its behalf. 20 Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols 21 to provide reachability from nodes on the home network when a Mobile 22 Node is not at home, by allowing the Home Agent to act as proxy. It 23 is also used as a mechanism to allow a global prefix to span multiple 24 links, where proxies act as relays for Neighbor discovery messages. 26 Neighbor Discovery Proxy currently cannot be secured using SEND. 27 Today, SEND assumes that a node advertising an address is the address 28 owner and in possession of appropriate public and private keys for 29 that node. This document describes how existing practice for proxy 30 Neighbor Discovery relates to Secured Neighbor Discovery. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on July 26, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4 75 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6 76 2.3. Bridge-like ND proxies . . . . . . . . . . . . . . . . . . 6 77 3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9 78 3.1. CGA signatures and Proxy Neighbor Discovery . . . . . . . 9 79 3.2. Non-CGA signatures and Proxy Neighbor Discovery . . . . . 10 80 3.3. Securing proxy DAD . . . . . . . . . . . . . . . . . . . . 11 81 3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11 82 4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12 83 4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 13 84 4.1.1. Mobile IPv6 and Router-based authorization . . . . . . 13 85 4.1.2. Mobile IPv6 and per-address authorization . . . . . . 13 86 4.1.3. Cryptographic based solutions . . . . . . . . . . . . 13 87 4.1.4. 'Point-to-Point' link model based solution . . . . . . 14 88 4.2. Secured Proxy ND and Bridge-like proxies . . . . . . . . . 14 89 4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14 90 4.2.2. Unauthorized routers and proxies . . . . . . . . . . . 14 91 4.2.3. Multiple proxy spans . . . . . . . . . . . . . . . . . 15 92 4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15 93 4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16 94 4.2.6. Host delegation of trust to proxies . . . . . . . . . 17 95 4.3. Proxying unsecured addresses . . . . . . . . . . . . . . . 17 96 5. Two or more nodes defending the same address . . . . . . . . . 18 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 7.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19 100 7.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19 101 7.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19 102 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery 111 [RFC4861]. It is used in networks where a prefix has to span 112 multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in 113 Mobile IPv6 based protocols like NEMO [RFC3963], FMIPv6 [RFC5568] or 114 HMIPv6 [RFC5380]) and in IKEv2 [RFC4306]. It allows a device which 115 is not physically present on a link to have another advertise its 116 presence, and forward on packets to the off-link device. 118 Neighbor Discovery Proxy relies upon another device, the proxy, to 119 monitor for Neighbor Solicitations (NS), and answer with Neighbor 120 Advertisements (NA). These proxy Neighbor Advertisements direct data 121 traffic through the proxy. Proxied traffic is then forwarded on to 122 the end destination. 124 2. Scenarios 126 This section describes the different scenarios where the interaction 127 between Secure Neighbor Discovery (SEND) and ND-Proxy raises issues. 129 2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy 131 When moving in the Internet, the aim of IPv6 mobility is to allow a 132 device continued packet delivery, whether present on its home network 133 or not. The following text is focused on Mobile IPv6 but the issue 134 raised by the interaction between SEND and ND-Proxy may be the same 135 with Mobile IPv6 based protocols (e.g. NEMO, HMIPv6). 137 For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing 138 sessions going or to allow new sessions even when one leaves the home 139 network. 141 In order to continue existing sessions, when nodes are present on the 142 home link, the Proxy (i.e. the Home Agent in Mobile IPv6) sends an 143 unsolicited NA to the all-nodes multicast address on the home link as 144 specified [RFC3775]. 146 For new sessions, the Proxy, which listens to the MN's address 147 responds with a Neighbor Advertisement which originates at its own 148 IPv6 address and has the proxy's address as the Target Link-Layer 149 Address, but contains the absent mobile in the Target Address field 150 of the Neighbor Advertisement. In this case, SEND cannot be applied 151 because the address in the Target Address field is not the same as 152 the one in the Source Address field of the IP header. 154 As seen in Figure 1, solicitors send a multicast solicitation to the 155 solicited nodes multicast address (based on the unicast address) of 156 the absent node (mobile node that is away from the home link). 158 Absent Mobile Proxy Solicitor 160 NS:SL3=S,DL3=Sol(A),TA=A 161 +-----+ SL2=s,DL2=sol(a),SLL=s 162 | |<================ 163 | | 164 | |================> 165 +-----+ NA:SL3=P,DL3=S,TA=A, 166 SL2=p,DL2=s,TLL=p 168 Legend: 169 SL3: Source IPv6 Address NS: Neighbor Solicitation 170 DL3: Destination IPv6 Address NA: Neighbor Advertisement 171 SL2: Source Link-Layer Address RS: Router Solicitation 172 DL2: Destination Link-Layer Address RA: Router Advertisement 173 TA: Target Address 174 SLL/TLL: Source/Target Link-Layer Address Option 176 Figure 1 178 While at home, if the MN has configured Cryptographically Generated 179 Addresses (CGAs) [RFC3972], it can secure establishment by its on- 180 link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using 181 Secure Neighbor Discovery (SEND) [RFC3971]. SEND security requires a 182 node sending Neighbor Advertisments for a given address to be in 183 possession of the public-private key pair that generated the address. 185 When a MN moves away from the home link, a proxy has to undertake 186 Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, 187 the role of the proxy is undertaken by the Home Agent. While the 188 Home agent has a security association with the MN, it does not have 189 access to the public-private key pair used to generate the MN's CGA. 190 Thus the Home Agent acting as an ND proxy cannot use SEND for the 191 address it is proxying [RFC3971]. 193 When a MN moves from the home network to a visited network, the proxy 194 will have to override the MN's existing Neighbor Cache Entries which 195 are flagged as secure [RFC3971]. This is needed for the Home Agent 196 to intercept traffic sent on-link to the MN that would otherwise be 197 sent to the MN's link layer address. 199 With the current SEND specification, any solicitation or 200 advertisement sent by the proxy will be unsecure and thus will not be 201 able to update the MN's NCE for the home address because it is 202 flagged as secured. These existing Neighbor Cache Entries will only 203 time-out after Neighbor Unreachability Detection [RFC4861] concludes 204 the Home Address is unreachable at the link layer recorded in the 205 NCE. 207 Where secured proxy services are not able to be provided, a proxy's 208 advertisement may be overridden by a rogue proxy without the 209 receiving host realizing that an attack has occurred. This is 210 identical to what happens in a network where SEND is not deployed. 212 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 214 This scenario is a sub-case from the previous one. The IPv6 node 215 will never be on the link where the ND messages are proxied. It may 216 be the case with IKEv2 [RFC4306]. When a node needs an IP address in 217 the network protected by a security gateway, the security gateway 218 assigns an address dynamically using Configuration Payload during 219 IKEv2 exchanges. The security gateway then needs to receive packets 220 sent to this address; one way to do so would be to proxy ND messages. 222 2.3. Bridge-like ND proxies 224 The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an 225 alternative method to classic bridging. Just as with classic 226 bridging, multiple link layer segments are bridged into a single 227 segment, but with the help of proxying at IP layer rather than link 228 layer bridging. The proxy in this case forwards messages while 229 modifying their source and destination MAC addresses, and rewrites 230 their Link-Layer Address Options, solicited, and override flags. 232 This rewriting is incompatible with SEND signed messages for a number 233 of reasons: 235 o Rewriting elements within the message will break the digital 236 signature. 238 o The source IP address of the packets is the packet's origin, not 239 the proxy's address. The proxy is unable to generate another 240 signature for this address, as it doesn't have the CGA private key 241 [RFC3971]. 243 Thus, proxy modification of SEND solicitations may require sharing of 244 credentials between the proxied node and the proxying node or 245 creation of new options with proxying capabilities. 247 While bridge-like ND proxies aim to provide as little interference 248 with ND mechanisms as possible, SEND has been designed to prevent 249 modification or spoofing of advertisements by devices on the link. 251 Of particular note is the fact that ND Proxy performs a different 252 kind of proxy Neighbor discovery to Mobile IPv6 [RFC3775] [RFC4389]. 253 The Mobile IPv6 RFC specifies that the Home Agent as proxy sends 254 Neighbor Advertisements from its own address with the Target Address 255 set to the absent Mobile Node's address. The Home Agent's own link- 256 layer address is placed in the Target Link-Layer address option 257 [RFC3775]. On the other hand, ND Proxy resends messages containing 258 their original address, even after modification (i.e. the IP source 259 address remains the same)[RFC4389]. Figure 2 describes packet 260 formats for proxy Neighbor solicitation and advertisement as 261 specified by the specification. 263 Advertisor Proxy Solicitor 265 NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A, 266 SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s 267 <==================| |<================ 268 | | 269 ==================>| |================> 270 NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A 271 SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p 273 Legend: 274 SL3: Source IPv6 Address NS: Neighbor Solicitation 275 DL3: Destination IPv6 Address NA: Neighbor Advertisement 276 SL2: Source Link-Layer Address 277 DL2: Destination Link-Layer Address 278 TA: Target Address 279 SLL/TLL: Source/Target Link-Layer Address Option 281 Figure 2 283 In order to use the same security procedures for both ND Proxy and 284 Mobile IPv6, changes may be needed to the proxying procedures in 285 [RFC4389], as well as changes to SEND. 287 An additional (and undocumented) requirement for bridge-like proxying 288 is the operation of router discovery. Router Discovery packets may 289 similarly modify Neighbor cache state, and require protection from 290 SEND. 292 In Figure 3, the router discovery messages propagate without 293 modification to the router address, but elements within the message 294 change. This is consistent with the description of Neighbor 295 Discovery above. 297 Advertisor Proxy Solicitor 299 RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR, 300 SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s 301 <==================| |<================ 302 | | 303 ==================>| |================> 304 RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S, 305 SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p 307 Legend: 308 SL3: Source IPv6 Address RS: Router Solicitation 309 DL3: Destination IPv6 Address RA: Router Advertisement 310 SL2: Source Link-Layer Address 311 DL2: Destination Link-Layer Address 312 TA: Target Address 313 SLL/TLL: Source/Target Link-Layer Address Option 315 Figure 3 317 Once again, these messages may not be signed with a CGA signature by 318 the proxy, because it does not own the source address. 320 Additionally, Authorization Delegation Discovery messages need to be 321 exchanged for bridge-like ND proxies to prove their authority to 322 forward. Unless the proxy receives explicit authority to act as a 323 router, or the router knows of its presence, no authorization may be 324 made. This explicit authorization requirement may be at odds with 325 the zero configuration goal of ND proxying [RFC4389]. 327 An alternative (alluded to in an appendix of ND Proxy [RFC4389]) 328 suggests that the proxy send Router Advertisements (RA) from its own 329 address. As described by ND Proxy, this is insufficient for 330 providing proxied Neighbor Advertisement service, but may be matched 331 with Neighbor solicitation and advertisement services using the 332 proxy's source address in the same way as Mobile IPv6 [RFC4389] 333 [RFC3775]. This means that all router and Neighbor advertisements 334 would come from the proxied address, but may contain a target address 335 which allows proxied Neighbor presence to be established with peers 336 on other segments. Router Discovery in this case has the identity of 337 the original (non-proxy) router completely obscured in router 338 discovery messages. 340 The resultant proxy messages would have no identifying information 341 indicating their origin, which means that proxying between multiple 342 links would require state to be stored on outstanding solicitations 343 (effectively a ND only NAT). This level of state storage may be 344 undesirable. 346 Mobile IPv6 does not experience this issue when supplying its own 347 address, since ND messages are never forwarded on to the absent node 348 (the Home Agent having sufficient information to respond itself). 350 Authorization from a router may still be required for Router 351 Advertisement, and will be discussed in Section 4.2. 353 3. Proxy Neighbor Discovery and SEND 355 There are currently no existing secured Neighbor Discovery procedures 356 for proxied addresses, and all Neighbor Advertisements from SEND 357 nodes are required to have equal source and target addresses, and be 358 signed by the transmitter (section 7.4 of [RFC3971]). 360 Signatures over SEND messages are required to be applied on the CGA 361 source address of the message, and there is no way of indicating that 362 a message is proxied. 364 Even if the message is able to be transmitted from the original 365 owner, differences in link-layer addressing and options require 366 modification by a proxy. If a message is signed with a CGA-based 367 signature, the proxy is unable to regenerate a signature over the 368 changed message as it lacks the keying material. 370 Therefore, a router wishing to provide proxy Neighbor Advertisement 371 service can not use existing SEND procedures on those messages. 373 A host may wish to establish a session with a device which is not on- 374 link but is proxied. As a SEND host, it prefers to create Neighbor 375 cache entries using secured procedures. Since SEND signatures cannot 376 be applied to an existing proxy Neighbor Advertisement, it must 377 accept non-SEND advertisements in order to receive proxy Neighbor 378 Advertisements. 380 Neighbor Cache spoofing of another node therefore becomes trivial, as 381 any address may be proxy advertised to the SEND node, and overridden 382 only if the node is there to protect itself. When a node is present 383 to defend itself, it may also be difficult for the solicitor 384 determine the difference between a proxy-spoofing attack, and a 385 situation where a proxied device returns to a link and overrides 386 other proxy advertisers [RFC4861]. 388 3.1. CGA signatures and Proxy Neighbor Discovery 390 SEND defines one public-key and signature format for use with 391 Cryptographically Generated Addresses (CGAs) [RFC3972]. CGAs are 392 intended to tie address ownership to a particular Public/Private key 393 pair. 395 In SEND as defined today, Neighbor Discovery Messages (including the 396 IP Addresses from the IPv6 header) are signed with the same key used 397 to generate the CGA. This means that message recipients have proof 398 that the signer of the message owned the address. 400 When a proxy replaces the message source IPv6 address with its own 401 CGA, as per SEND specification the existing CGA option and RSA 402 signature option would need to be replaced with the proxy ones. To 403 be valid according to the SEND specification, the Target Address of 404 the Neighbor Advertisement message would need to be replaced also to 405 be equal to the Source Address [RFC3971]. 407 Additional authorization information may be needed to prove that the 408 proxy is indeed allowed to advertise for the target address, as is 409 described in Section 4. 411 3.2. Non-CGA signatures and Proxy Neighbor Discovery 413 Where a proxy retains the original source address in a proxied 414 message, existing SEND-CGA checks will fail, since fields within the 415 message will be changed. In order to achieve secured proxy Neighbor 416 discovery in this case, extended authorization mechanisms may be 417 needed for SEND. 419 SEND provides mechanisms for extension of SEND to non-CGA based 420 authorization. Messages are available for Authorization Delegation 421 Discovery, which is able to carry arbitrary PKIX/X.509 certificates 422 [RFC5280]. 424 There is, however, no specification of keying information option 425 formats analogous to the SEND CGA Option [RFC3971]. The existing 426 option allows a host to verify message integrity by specifying a key 427 and algorithm for digital signature, without providing authorization 428 via other mechanisms than CGA ownership. 430 The digital signature in SEND is transported in the RSA Signature 431 Option. As currently specified, the signature operation is performed 432 over a CGA Message type, and allows for CGA verification. Updating 433 the signature function to support non-CGA operations may be 434 necessary. 436 Within SEND, more advanced functions such as routing may be 437 authorized by certificate path verification using Authorization 438 Delegation Discovery. 440 With non-CGA signatures and authentication, certificate contents for 441 authorization may need to be determined, as outlined in Section 4. 443 While SEND provides for extensions to new non-CGA methods, existing 444 SEND hosts may silently discard messages with unverifiable RSA 445 signature options (Section 5.2.2 of [RFC3971]), if configured only to 446 accept SEND messages. In cases where unsecured Neighbor cache 447 entries are still accepted, messages from new algorithms will be 448 treated as unsecured. 450 3.3. Securing proxy DAD 452 Initiation of Proxy Neighbor Discovery also requires Duplicate 453 Address Detection (DAD) checks of the address [RFC4862]. These DAD 454 checks need to be performed by sending Neighbor Solicitations, from 455 the unspecified source address, with the target being the proxied 456 address. 458 In existing SEND procedures, the address which is used for CGA tests 459 on DAD NS is the target address. A Proxy which originates this 460 message while the proxied address owner is absent is unable to 461 generate a CGA-based signature for this address and must undertake 462 DAD with an unsecured NS. It may be possible that the proxy can 463 ensure that responding NA's are secured though. 465 Where bridge-like ND proxy operations are being performed, DAD NS's 466 may be copied from the original source, without modification 467 (considering they have an unspecified source address and contain no 468 link-layer address options) [RFC4389]. 470 If non-CGA based signatures are available, then the signature over 471 the DAD NS doesn't need to have a CGA relationship to the Target 472 Address, but authorization for address configuration needs to be 473 shown using certificates. 475 In case there is a DAD collision between two SEND nodes on different 476 interfaces of the proxy, it is possible that the proxy may not have 477 the authority to modify the NA defending the address. In this case 478 the proxy needs to still modify the NA and pass it onto the other 479 interfaces even if it will fail SEND verification on the receiving 480 node. 482 3.4. Securing Router Advertisements 484 While Router Solicitations are protected in the same manner as 485 Neighbor Solicitations, the security for Router Advertisements is 486 mainly based on the use of certificates. Even though the mechanism 487 for securing RAs is different, the problems that arise due to the 488 modification of the L2 addresses are exactly the same: the proxy 489 needs to have the right security material (e.g. certificate) to sign 490 the RA messages after modification. 492 4. Potential Approaches to Securing Proxy ND 494 SEND nodes already have the concept of delegated authority through 495 requiring external authorization of routers to perform their routing 496 and advertisement roles. The authorization of these routers takes 497 the form of delegation certificates. 499 Proxy Neighbor Discovery requires a delegation of authority on behalf 500 of the absent address owner, to the proxier. Without this authority, 501 other devices on the link have no reason to trust an advertiser. 503 For bridge-like proxies, it is assumed that there is no preexisting 504 trust between the host owning the address and the proxy. Therefore, 505 authority may necessarily be dynamic or based on topological roles 506 within the network [RFC4389]. 508 Existing trust relationships lend themselves to providing authority 509 for proxying in two alternative ways. 511 First, the SEND router authorization mechanisms described above 512 provide delegation from the organization responsible for routing in 513 an address domain, to the certified routers. It may be argued that 514 routers so certified may be trusted to provide service for nodes 515 which form part of a link's address range, but are themselves absent. 516 Devices which are proxies could either be granted the right to proxy 517 by the network's router, or be implicitly allowed to proxy by virtue 518 of being an authorized router. 520 Second, where the proxied address is itself a CGA, the holder of the 521 public and private keys is seen to be authoritative about the 522 address' use. If this address owner was able to sign the proxier's 523 address and public key information, it would be possible to identify 524 that the proxy is known and trusted by the CGA address owner for 525 proxy service. This method requires that the proxied address know or 526 learn the proxy's address and public key, and that the certificate 527 signed by the proxied node's is passed to the proxy, either while 528 they share the same link, or at a later stage. 530 In both methods, the original address owner's advertisements need to 531 override the proxy if it suddenly returns, and therefore timing and 532 replay protection from such messages need to be carefully considered. 534 4.1. Secured Proxy ND and Mobile IPv6 536 Mobile IPv6 has a security association between the Mobile Node and 537 Home Agent. The Mobile Node sends a Binding Update to the Home 538 Agent, to indicate that it is not at home. This implies that the 539 Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery 540 operations for its home address(es). 542 4.1.1. Mobile IPv6 and Router-based authorization 544 A secured Proxy Neighbor Advertisements proposal based on existing 545 router trust would require no explicit authorization signalling 546 between HA and MN to allow proxying. Hosts on the home link will 547 believe proxied advertisements solely because they come from a 548 trusted router. 550 Where the home agent operates as a router without explicit trust to 551 route from the advertising routing infrastructure (such as in a home, 552 with a router managed by an ISP), more explicit proxying 553 authorization may be required, as described in Section 4.2. 555 4.1.2. Mobile IPv6 and per-address authorization 557 Where proxy Neighbor Discovery is delegated by the MN to the home 558 agent, the MN needs to learn the public key for the Home Agent, so 559 that it can generate a certificate authorizing the public-private 560 key-pair to be used in proxying. It may conceivably either do this 561 using Certificate Path Solicitations over a home tunnel, over the 562 Internet, or Router Discovery while still at home [RFC3971] 563 [RFC3775]. 565 When sending its Binding Update to the HA, the MN would need to 566 provide a certificate containing the subject(proxy-HA)'s public key 567 and address, the issuer(MN)'s CGA and public key, and timestamps 568 indicating when the authority began and when it ends. This 569 certificate would need to be transmitted at binding time. Messaging 570 or such an exchange mechanism would have to be developed. 572 4.1.3. Cryptographic based solutions 574 Specific cryptographic algorithms may help to allow trust between 575 entities of a same group. 577 This is the case, for example, with ring signature algorithms. These 578 algorithms generate a signature using the private key of any member 579 from the same group, but to verify the signature the public keys of 580 all group members are required. Applied to SEND, the addresses are 581 cryptographically generated using multiple public keys and the 582 Neighbor Discovery messages are signed with an RSA ring signature. 584 4.1.4. 'Point-to-Point' link model based solution 586 Another approach is to use the 'Point-to-Point' link model. 588 In this model, one prefix is provided per MN and only a MN and the HA 589 are on a same link. The consequence is the HA no longer needs to act 590 as ND Proxy. 592 One way to design such a solution is to use virtual interfaces, on 593 the MN and the HA, and a virtual link between them. Addresses 594 generated on the virtual interfaces will only be advertised on the 595 virtual link. For Mobile IPv6, this results in a virtual Home 596 Network where the MN will never come back. 598 4.2. Secured Proxy ND and Bridge-like proxies 600 In link-extension environments, the role of a proxy is more 601 explicitly separated from that of a router. In SEND, routers may 602 expect to be authorized by the routing infrastructure to advertise, 603 and provide this authority to hosts in order to allow them to change 604 forwarding state. 606 Proxies are not part of the traditional infrastructure of the 607 Internet, and hosts or routers may not have an explicit reason to 608 trust them, except that they can forward packets to regions where 609 otherwise they could not reach. 611 4.2.1. Authorization Delegation 613 If a proxy can convince a device that it should be trusted to perform 614 proxying function, it may require that device to vouch for its 615 operation in dealing with other devices. It may do this by receiving 616 a certificate, signed by the originating device that the proxy is 617 believed capable of proxying under certain circumstances. 619 This allows nodes receiving proxied Neighbor discovery packets to 620 quickly check if the proxy is authorized for the operation. There 621 are several bases for such trust, and requirements in proxied 622 environments, which are discussed below. 624 4.2.2. Unauthorized routers and proxies 626 Routers may be advertising on networks without any explicit 627 authorization, and SEND hosts will configure these if there are no 628 other options [RFC3971]. While proxies may similarly attempt to 629 advertise without authority, this provides no security for the 630 routing infrastructure. Any device can be setup as a SEND proxy/ 631 router so long as it signs its own ND messages from its CGA. 633 This may not help in the case that a proxy attempts to update 634 Neighbor cache entries for SEND node which moves between links, since 635 the SEND node's authority to advertise its own CGA address would not 636 be superseded by a proxy with no credentials. 638 4.2.3. Multiple proxy spans 640 Proxies may have multiple levels of nesting, which allow the network 641 to connect between non-adjacent segments. 643 In this case, authority delegated at one point will have to be 644 redelegated (possibly in a diluted form) to proxies further away from 645 the origin of the trust. 647 Trust ProxyA ProxyB Distant 648 Origin - T Node - D 650 +-----+ +-----+ 651 | | | | 652 +-----+ +-----+ +-----+ +-----+ 653 | | | | | | 654 ------------| |------------| |---------- 655 | | | | 656 +-----+ +-----+ 657 ==========> ==============> ==========> 658 Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B, 659 Deleg(A,T)) 661 Figure 4 663 As shown in Figure 4, the Proxy A needs to redelegate authority to 664 proxy for T to B, this allows it to proxy advertisements back to D, 665 which target T. 667 4.2.4. Routing Infrastructure Delegation 669 Where it is possible for the proxy to pre-establish trust with the 670 routing infrastructure, or at least to the local router, it may be 671 possible to authorize proxying as a function of routing within the 672 subnet. The router or CA may then be able to certify proxying for 673 only a subset of the prefixes for which is itself certified. 675 If a router or CA provides certification for a particular prefix, it 676 may be able to indicate that only proxying is supported, so that 677 Neighbor cache entries of routers connected to internet 678 infrastructure are never overridden by the proxy, if the router is 679 present on a segment. 681 Hosts understanding such certificates may allow authorized proxies 682 and routers to override host SEND/CGA when assuming proxy roles, if 683 the host is absent. 685 Proxy certificate signing could be done either dynamically (requiring 686 exchanges of identity and authorization information), or statically 687 when the network is set up. 689 4.2.5. Local Delegation 691 Where no trust tie exists between the authority which provides the 692 routing infrastructure and the provider of bridging and proxying 693 services, it may still be possible for SEND hosts to trust the 694 bridging provider to authorize proxying operations. 696 SEND itself requires that routers be able to show authorization, but 697 doesn't require routers to have a single trusted root. 699 A local bridging/proxying authority trust delegation may be possible. 700 It would be possible for this authority to pass out local use 701 certificates, allowing proxying on a specific subnet or subnets, with 702 a separate authorization chain to that for the routers with Internet 703 access. 705 This would require little modification to SEND, other than addition 706 of router based proxy authority (as in Section 4.2.4), and proxies 707 would in effect be treated as routers by SEND hosts [RFC3971]. 708 Distribution of keying and trust material for the initial bootstrap 709 of proxies would not be provided though (and may be static). 711 Within small domains, key management and distribution may be a 712 tractable problem, so long as these operations are simple enough to 713 perform. 715 Since these domains may be small, it may be necessary to provide 716 certificate chains for trust anchors which weren't requested in 717 Certificate Path Solicitations, if the proxy doesn't have a trust 718 chain to any requested trust anchor. 720 This is akin to 'suggesting' an appropriate trusted root. It may 721 allow for user action in allowing trust extension when visiting 722 domains without ties to a global keying infrastructure. In this 723 case, the trust chain would have to start with a self-signed 724 certificate from the original CA. 726 4.2.6. Host delegation of trust to proxies 728 Unlike Mobile IPv6, for bridge-like proxied networks, there is no 729 existing security association upon which to transport proxying 730 authorization credentials. 732 Proxies need then to convince Neighbors to delegate proxy authority 733 to them, in order to proxy-advertise to nodes on different segments. 734 It will be difficult without additional information to distinguish 735 between legitimate proxies, and devices which have no need or right 736 to proxy (and may want to make two network segments to appear to be 737 connected). 739 When proxy advertising, proxies must not only identify that proxying 740 needs to occur, but provide proof that they are allowed to do so, so 741 that SEND Neighbor Cache entries may be updated. Unless the 742 authorization to update such entries is tied to address ownership 743 proofs from the proxied host or the verifiable routing 744 infrastructure, spoofing may occur. 746 When a host received a proxied Neighbor advertisement, it would be 747 necessary to check authorization in the same way that authorization 748 delegation discovery is performed in SEND. 750 Otherwise, certificate transport will be required to exchange 751 authorization between proxied nodes and proxies. 753 Proxies would have to be able to delegate this authorization to 754 downstream proxies, as described in Section 4.2.3. 756 4.3. Proxying unsecured addresses 758 Where the original Neighbor discovery message is unsecured, there is 759 an argument for not providing secured proxy service for that node. 761 In both the Mobile IPv6 and extended networks cases, the node may 762 arrive back at the network and require other hosts to map their 763 existing Neighbor cache entry to the node's link-layer address. The 764 re-arriving node's overriding of link-layer address mappings will 765 occur without SEND in this case. 767 It is notable that without SEND protection any node may spoof the 768 arrival, and effectively steal service across an extended network. 769 This is the same as in the non-proxy case, and is not made 770 significantly worse by the proxy's presence (although the identity of 771 the attacker may be masked if source addresses are being replaced). 773 If signatures over the proxied messages were to be used, re-arrival 774 and override of the Neighbor cache entries would have to be allowed, 775 so the signatures would indicate that at least the proxy wasn't 776 spoofing (even if the original sender was). 778 For non-SEND/CGA routers, though, it may be possible for secured 779 proxies to send signed router advertisement messages, in order to 780 ensure that routers aren't spoofed, and subsequently switched to 781 being on different parts of the extended network. 783 This has problems in that the origin is again unsecured, and any node 784 on the network could spoof router advertisement for an unsecured 785 address. These spoofed messages may become almost indistinguishable 786 (except for the non-CGA origin address) from unspoofed messages from 787 SEND routers. 789 Given these complexities, the simplest method is to allow unsecured 790 devices to be spoofed from any port on the network, as is the case 791 today. 793 5. Two or more nodes defending the same address 795 All the previous sections of this document focused on the case where 796 two nodes defend the same address (i.e. the node and the proxy). 797 However, there are also cases where two or more nodes are defending 798 the same address. This is at least the case for: 800 o Nodes having the same address, as the MAG's ingress link-local 801 address in PMIPv6 [RFC5213]. 803 o Nodes having a common anycast address [RFC4291]. 805 The problem statement, described previously in this document, applies 806 for these cases and the issues are the same from a signalling point 807 of view. 809 Multicast addresses are not mentioned here because Neighbor Discovery 810 Protocol is not used for them. 812 In the first case, [RFC5213] assumes that the security material used 813 by SEND (i.e. public-private key pair) is shared between all the 814 MAGs. For the second case, there is no solution today. But, in the 815 same way, it should be possible to assume that the nodes having a 816 common anycast address could also share the security material. 818 It is important to notice that when many nodes defending the same 819 address are not in the same administrative domain (e.g. MAGs in 820 different administrative domains but in the same PMIPv6 domain 822 [RFC5213]), sharing the security material used by SEND may raise a 823 security issue. 825 6. IANA Considerations 827 No new options or messages are defined in this document. 829 7. Security Considerations 831 7.1. Router Trust Assumption 833 Router based authorization for Secured Proxy ND may occur without the 834 knowledge or consent of a device. It is susceptible to the 'Good 835 Router Goes Bad' attack described in [RFC3756]. 837 7.2. Certificate Transport 839 Certificate delegation relies upon transfer of the new credentials to 840 the proxying HA in order to undertake ND proxy on its behalf. Since 841 the Binding cannot come into effect until DAD has taken place, the 842 delegation of the proxying authority necessarily predates the return 843 of the Binding Ack, as described in [RFC3775]. In the above 844 described case, the home tunnel which comes into creation as part of 845 the binding process may be required for Certificate Path Solicitation 846 or Advertisement transport [RFC3971]. This constitutes a potential 847 chicken-and-egg problem. Either modifications to initial home 848 binding semantics or certificate transport are required. This may be 849 trivial if certificates are sent in the clear between the MN's CoA 850 and the HA without being tunneled. 852 7.3. Timekeeping 854 All of the presented methods rely on accurate timekeeping on the 855 receiver nodes of Neighbor Discovery Timestamp Options. 857 For router-authorized proxy ND, a Neighbor may not know that a 858 particular ND message is replayed from the time when the proxied host 859 was still on-link, since the message's timestamp falls within the 860 valid timing window. Where the router advertises its secured proxy 861 NA, a subsequent replay of the old message will override the NC entry 862 created by the proxy. 864 Creating the Neighbor cache entry in this way, without reference to 865 accurate subsequent timing, may only be done once. Otherwise the 866 receiver will notice that the timestamp of the advertisement is old 867 or doesn't match. 869 One way of creating a sequence of replayable messages which have 870 timestamps likely to be accepted is to pretend to do an unsecured DAD 871 on the address each second while the MN is at home. The attacker 872 saves each DAD defence in a sequence. The granularity of SEND 873 timestamp matching is around 1 second, so the attacker has a set of 874 SEND NA's to advertise, starting at a particular timestamp, and valid 875 for as many seconds as the original NA gathering occurred. 877 This sequence may then be played against any host which doesn't have 878 a timestamp history for that MN, by tracking the number of seconds 879 elapsed since the initial transmission of the replayed NA to that 880 victim, and replaying the appropriate cached NA. 882 Where certificate based authorization of ND proxy is in use, the 883 origination/starting timestamp of the delegated authority may be used 884 to override a replayed (non-proxy) SEND NA, while also ensuring that 885 the Proxy NA's timestamp (provided by the proxy) is fresh. A 886 returning MN would advertise a more recent timestamp than the 887 delegated authority and thus override it. This method is therefore 888 not subject to the above attack, since the proxy advertisement's 889 certificate will have a timestamp greater than any replayed messages, 890 preventing it from being overridden. 892 8. Acknowledgments 894 James Kempf and Dave Thaler particularly contributed to work on this 895 document. Contributions to discussion on this topic helped to 896 develop this document. The authors would also like to thank Jari 897 Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, 898 Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen and 899 Sheng Jiang for their comments and suggestions. 901 Jean-Michel Combes is partly funded by MobiSEND, a research project 902 supported by the French 'National Research Agency' (ANR). 904 9. References 906 9.1. Normative References 908 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 909 in IPv6", RFC 3775, June 2004. 911 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 912 Neighbor Discovery (SEND)", RFC 3971, March 2005. 914 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 915 RFC 3972, March 2005. 917 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 918 Architecture", RFC 4291, February 2006. 920 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 921 RFC 4306, December 2005. 923 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 924 Proxies (ND Proxy)", RFC 4389, April 2006. 926 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 927 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 928 September 2007. 930 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 931 Address Autoconfiguration", RFC 4862, September 2007. 933 9.2. Informative References 935 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 936 Discovery (ND) Trust Models and Threats", RFC 3756, 937 May 2004. 939 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 940 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 941 RFC 3963, January 2005. 943 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 944 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 946 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 947 Housley, R., and W. Polk, "Internet X.509 Public Key 948 Infrastructure Certificate and Certificate Revocation List 949 (CRL) Profile", RFC 5280, May 2008. 951 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 952 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 953 Management", RFC 5380, October 2008. 955 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 956 July 2009. 958 Authors' Addresses 960 Jean-Michel Combes 961 Orange Labs 962 38 rue du General Leclerc 963 92794 Issy-les-Moulineaux Cedex 9 964 France 966 Email: jeanmichel.combes@gmail.com 968 Suresh Krishnan 969 Ericsson 970 8400 Decarie Blvd. 971 Town of Mount Royal 972 QC Canada 974 Email: Suresh.Krishnan@ericsson.com 976 Greg Daley 977 NetStar Australia 978 Level 9/636 St Kilda Road 979 Melbourne, Victoria 3004 980 Australia 982 Phone: +61 401 772 770 983 Email: hoskuld@hotmail.com