idnits 2.17.1 draft-daley-send-spnd-prob-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1086. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5897 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 922, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CSI Working Group G. Daley 3 Internet-Draft 4 Intended status: Informational J-M. Combes 5 Expires: August 28, 2008 Orange Labs/France Telecom R&D 6 February 25, 2008 8 Securing Neighbour Discovery Proxy Problem Statement 9 draft-daley-send-spnd-prob-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of 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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Neighbour Discovery Proxy is used to provide an address presence on a 43 link from nodes which are no themselves present. It allows a node to 44 receive packets directed at its address by allowing another device to 45 neighbour advertise on its behalf. 47 Neighbour Discovery Proxy is used in Mobile IPv6 and related 48 protocols to provide reachability from nodes on the home network when 49 a Mobile Node is not at home, by allowing the Home Agent to act as 50 proxy. It is also used as a mechanism to allow a global prefix to 51 span multiple links, where proxies act as relays for neighbour 52 discovery messages. 54 Neighbour Discovery Proxy currently cannot be secured using SEND. 55 Today, SEND assumes that a node advertising an address is the address 56 owner and in possession of appropriate public and private keys for 57 that node. This document describes how existing practice for proxy 58 Neighbour Discovery relates to Secured Neighbour Discovery. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. IPv6 Mobile Nodes and Neighbour Discovery Proxy . . . . . 4 65 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6 66 2.3. Bridge-like ND proxies . . . . . . . . . . . . . . . . . . 6 67 3. Proxy ND and Mobility . . . . . . . . . . . . . . . . . . . . 8 68 4. Proxy Neighbour Discovery and SEND . . . . . . . . . . . . . . 11 69 4.1. CGA signatures and Proxy Neighbour Discovery . . . . . . . 12 70 4.2. Non-CGA signatures and Proxy Neighbour Discovery . . . . . 12 71 4.3. Securing proxy DAD . . . . . . . . . . . . . . . . . . . . 13 72 5. Potential Approaches to Securing Proxy ND . . . . . . . . . . 14 73 5.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 15 74 5.1.1. Mobile IPv6 and Router-based authorization . . . . . . 15 75 5.1.2. Mobile IPv6 and per-address authorization . . . . . . 15 76 5.2. Secured Proxy ND and Bridge-like proxies . . . . . . . . . 16 77 5.2.1. Authorization Delegation . . . . . . . . . . . . . . . 16 78 5.2.2. Unauthorized routers and proxies . . . . . . . . . . . 16 79 5.2.3. Multiple proxy spans . . . . . . . . . . . . . . . . . 16 80 5.2.4. Routing Infrastructure Delegation . . . . . . . . . . 17 81 5.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 17 82 5.2.6. Host delegation of trust to proxies . . . . . . . . . 18 83 5.3. Proxying unsecured addresses . . . . . . . . . . . . . . . 19 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 7.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 20 87 7.2. Certificate Transport . . . . . . . . . . . . . . . . . . 20 88 7.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 20 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 93 Appendix A. Two ore more nodes defending a same address . . . . . 23 94 Appendix B. Changes from the previous versions . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Intellectual Property and Copyright Statements . . . . . . . . . . 25 98 1. Introduction 100 Neighbour Discovery Proxy is defined in IPv6 Neighbour Discovery 101 [RFC4861]. It is used in networks where a prefix has to span 102 multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in 103 Mobile IPv6 based protocols like NEMO [RFC3963], FMIPv6 [RFC4068] or 104 HMIPv6 [RFC4140]) and in IKEv2 [RFC4306]. It allows a device which 105 is not physically present on a link to have another advertise its 106 presence, and forward on packets to the off-link device. 108 Neighbour Discovery Proxy relies upon another device, the proxy, to 109 monitor for Neighbour Solicitations (NS), and answer with Neighbour 110 Advertisements (NA). These proxy Neighbour Advertisements direct 111 data traffic through the proxy. Proxied traffic is then forwarded on 112 to the end destination. 114 2. Scenarios 116 This section describes the different scenarios where the interaction 117 between SEND and ND-Proxy raises issues. 119 2.1. IPv6 Mobile Nodes and Neighbour Discovery Proxy 121 When moving in the Internet, the aim of IPv6 mobility is to allow a 122 device continued packet delivery, whether present on its home network 123 or not. The following text is focused on Mobile IPv6 but the issue 124 is the same with Mobile IPv6 based protocols (e.g. NEMO, HMIPv6). 126 For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing 127 sessions going even when one leaves the home network. If a neighbour 128 is actively delivering packets to a Mobile Node which is at home, 129 this neighbour will have a valid neighbour cache entry pointed at the 130 MN's link-layer address on the Home link. 132 As seen in Figure 1, solicitors send a multicast solicitation to the 133 solicited nodes address of the absent node (based on the unicast 134 address). 136 Absent Mobile Proxy Solicitor 138 NS:SL3=S,DL3=Sol(A),TA=A 139 +-----+ SL2=s,DL2=sol(a),SLL=s 140 | |<================ 141 | | 142 | |================> 143 +-----+ NA:SL3=P,DL3=S,TA=A, 144 SL2=p,DL2=s,TLL=p 146 Legend: 147 SL3: Source IPv6 Address NS: Neighbour Solicitation 148 SL3: Destination IPv6 Address NA: Neighbour Advertisement 149 SL2: Source Link-Layer Address RS: Router Solicitation 150 DL2: Destination Link-Layer Address RA: Router Advertisement 151 TA: Target Address 152 SLL/TLL: Source/Target Link-Layer Address Option 154 Figure 1 156 The Proxy, which listens to this address responds with a Neighbour 157 Advertisement which originates at its own IPv6 address and has the 158 proxy's address as the Target Link-Layer Address, but contains the 159 absent mobile in the Target Address field of the Neighbour 160 Advertisement. In this case, no solicitations are proxied, as the 161 advertisements originate within the proxy itself. 163 If Cryptographically Generated Addressing (CGA) [RFC3972] is 164 available, the MN may be able to secure its neighbour cache bindings 165 while at home using Secured Neighbour Discovery (SEND) [RFC3971]. 166 SEND assumes that the address owner is the advertiser and therefore 167 has access to the keys required to sign advertisements about the 168 address. Movement away from the home link requires that a proxy 169 undertake Neighbour Discovery. 171 In Mobile IPv6, the role of the proxy is undertaken by the Home 172 Agent. While the Home agent has a security association with the MN, 173 it as proxy will not have access to the public-private key pair used 174 to generate the MN's cryptographic address. This prevents Proxy 175 Neighbour Discovery from using SEND as defined [RFC3971]. 177 Where a host moves from the home network to a visited network, the 178 proxy needs to override existing valid neighbour cache entries which 179 may have SEND protection. This is needed in order to redirect 180 traffic to use the proxy's link-layer address, allowing packets to 181 flow onto the tunnel connecting the Home Agent/Proxy and the MN. 182 With current specifications, any solicitation or advertisement sent 183 by the proxy will not be able to update the MN's home address if the 184 existing NC entry is protected by SEND. Such existing neighbour 185 cache entries will time-out after Neighbour Unreachability Detection 186 [RFC4861]. 188 Where secured proxy services are not able to be provided, a proxy's 189 advertisement may be overridden by a bogus proxy without it even 190 knowing the attack has occurred. 192 2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 194 This scenario is a sub-case from the previous one. The IPv6 node 195 will be never on the link where the ND messages are proxied. This is 196 case with IKEv2 [RFC4306] when a node needs an IP address in the 197 network protected by a security gateway and this latest assigns it 198 dynamically in using Configuration Payload during IKEv2 exchanges. 199 The security gateway will have to proxy ND messages to be able to 200 intercept messages, sent to the node, to tunnel them to this latest. 202 2.3. Bridge-like ND proxies 204 Where proxies exist between two segments, messages may be sent by the 205 proxy on the far link, in order to gain or pass on neighbour 206 information. The proxy in this case forwards messages while 207 modifying their source and destination MAC addresses, and rewrites 208 their Link-Layer Address Options solicited and override flags. This 209 is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389]. 211 This rewriting is incompatible with SEND signed messages for a number 212 of reasons: 214 o Rewriting elements within the message will break the digital 215 signature. 217 o The source IP address of the packets is the packet's origin, not 218 the proxy's address. The proxy is unable to generate another 219 signature for this address, as it doesn't have the CGA private key 220 [RFC3971]. 222 Proxy modification of SEND solicitations and advertisements require 223 removal of (at least) CGA and Signature options, and may also need 224 new options with proxy capabilities if non-CGA signatures are added 225 to SEND. 227 While bridge-like ND proxies aim to provide as little interference 228 with ND mechanisms as possible, SEND has been designed to prevent 229 modification or spoofing of advertisements by devices on the link. 231 Of particular note is the fact that ND Proxy performs a different 232 kind of proxy neighbour discovery to Mobile IPv6 [RFC3775] [RFC4389]. 233 The Mobile IPv6 RFC specifies that the Home Agent as proxy sends 234 Neighbour Advertisements from its own address with the Target Address 235 set to the absent Mobile Node's address. The Home Agent's own link- 236 layer address is placed in the Target Link-Layer address option 237 [RFC3775]. 239 ND Proxy resends messages containing their original address, even 240 after modification [RFC4389]. Figure 2 describes packet formats for 241 proxy neighbour solicitation and advertisement as specified by the 242 specification. 244 Advertisor Proxy Solicitor 246 NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A, 247 SL2=p,DL2=sol(A),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s 248 <==================| |<================ 249 | | 250 ==================>| |================> 251 NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A 252 SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p 254 Figure 2 256 In order to use the same security procedures for both ND Proxy and 257 Mobile IPv6, changes may be needed to the proxying procedures in 258 [RFC4389], as well as changes to SEND. 260 An additional (and undocumented) requirement for bridge-like proxying 261 is the operation of router discovery. Router Discovery packets may 262 similarly modify neighbour cache state, and require protection from 263 SEND. 265 In Figure 3, the router discovery messages propagate without 266 modification to the router address, but elements within the message 267 change. This is consistent with the description of Neighbour 268 Discovery above. 270 Advertisor Proxy Solicitor 272 RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllRr, 273 SL2=p,DL2=sol(A),SLL=p +-----+ SL2=s,DL2=allr,SLL=s 274 <==================| |<================ 275 | | 276 ==================>| |================> 277 RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S, 278 SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p 279 Figure 3 281 Once again, these messages may not be signed with a CGA signature by 282 the re-advertisor, because it does not own the source address. 284 Additionally, multicast Authorization Delegation Discovery ICMPv6 285 messages need to be exchanged for bridge-like ND proxies to prove 286 their authority to forward. Unless the proxy receives explicit 287 authority to act as a router, or the router knows of its presence, no 288 authorization may be made. This explicit authorization requirement 289 may be at odds with zero configuration goal of ND proxying [RFC4389]. 291 An alternative (alluded to in an appendix of ND Proxy) suggests that 292 the proxy send Router Advertisements (RA) from its own address. As 293 described by ND Proxy, this is insufficient for providing proxied 294 Neighbour Advertisement service, but may be matched with neighbour 295 solicitation and advertisement services using the proxy's source 296 address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This 297 means that all router and neighbour advertisements would come from 298 the proxied address, but may contain a target address which allows 299 proxied neighbour presence to be established with peers on other 300 segments. Router Discovery in this case has the identity of the 301 original (non-proxy) router completely obscured in router discovery 302 messages. 304 The resultant proxy messages would have no identifying information 305 indicating their origin, which means that proxying between multiple 306 links would require state to be stored on outstanding solicitations 307 (effectively a ND only NAT). This level of state storage may be 308 undesirable. 310 Mobile IPv6 does not experience this issue when supplying its own 311 address, since ND messages are never forwarded on to the absent node 312 (the Home Agent having sufficient information to respond itself). 314 Authorization from a router may still be required for Router 315 Advertisement, and will be discussed in Section 5.2. 317 3. Proxy ND and Mobility 319 Whenever a mobile device moves off a link and requires another device 320 to forward packets from that address to the MN's new location, proxy 321 Neighbour Discovery is required. 323 In the Mobile IPv6 case, where the Mobile Node moves away from home, 324 a Home Agent needs to be able to override existing neighbour cache 325 entries in order to redirect packet flow over a tunnel to the Mobile 326 Node's Care-of-Address (CoA) [RFC3775]. 328 In Fast Handovers for Mobile IPv6, local neighbours or routers with 329 existing valid neighbour cache states need to be told the PAR's link- 330 layer address when the MN is departing for a new link, or after 331 arrival on the new link when tunnel forwarding begins [RFC4068]. 332 This allows the MN to maintain reachability to the hosts on that link 333 until it is able to send Mobile IPv6 Binding signalling subsequent to 334 address configuration on the new network. 336 As shown in Figure 4, after the mobile node departs, the Home Agent 337 or Proxy sends an overriding Neighbour advertisement, in order to 338 update existing neighbour cache entries. 340 Absent Mobile Proxy Solicitor 342 +-----+ 343 Binding Update | | 344 ---------------->| | 345 or Fast BU | |================> 346 +-----+ NA:SL3=P,DL3=AllN,TA=A, 347 SL2=p,DL2=alln,TLL=p 349 Figure 4 351 Where the proxy forwards between segments of a network, nodes may 352 move between segments [RFC4389]. For this scenario, the proxy is 353 responsible for updating neighbour cache entries as incorrect state 354 is left in them after the move. 356 Devices which were on the same segment as the moving node, 357 subsequently have incorrect neighbour cache state, as they now need 358 to traverse the proxy to get to the other node. Devices which were 359 previously being proxied may now be on the same segment as the mobile 360 node, and may go direct. 362 As illustrated in Figure 5, the nodes may have incorrect neighbour 363 cache state, even if the proxy knows of the departure to another 364 segment. 366 Mobile Node Proxy Mobile Node - M 367 (Departed) P (New Location) 369 + - - + +-----+ NC: 370 ' ' NC: NC: | | N -> n 371 + - - + N -> n+-----+M -> m +-----+ 372 | | | | 373 ------------------| |-------------------- 374 | | | 375 +-----+NC: +-----+ 376 | |M -> m 377 +-----+ 379 Existing 380 Neighbour - N 382 Figure 5 384 While neighbour cache state times out, and causes devices to probe 385 for the location of a peer, long delays may occur before timeouts of 386 neighbour cache state [RFC4861]. In cases where these delays are too 387 long, the proxy may have to override the neighbour cache entries of 388 hosts which were previously on the same segment as the moving node. 390 Those devices now resident on the same segment as the mobile node 391 will have the proxy's link-layer address in its neighbour cache. In 392 ND Proxy, it is indicated that packets are never forwarded back to 393 the same segment upon which they arrived (potentially to prevent 394 forwarding loops) [RFC4389]. 396 Similarly, if the mobile node is unaware of its movement, it too may 397 have incorrect neighbour cache entries for devices which it is now on 398 the same segment as. This is shown below in Figure 6. 400 Mobile Node Proxy Mobile Node - M 401 (Departed) P (New Location) 403 + - - + +-----+ NC: 404 ' ' NC: NC: | | N -> p2 405 + - - + +-----+M -> m +-----+ 406 | | |N -> n | 407 ------------------| |-------------------- 408 | | | 409 P2+-----+P1 +-----+ NC: 410 | | M -> p1 411 +-----+ 413 Existing 414 Neighbour - N 416 Figure 6 418 For the remaining duration of their incorrect neighbour cache entry 419 (up to around 35 seconds), all packets will be dropped. Therefore, 420 these devices may need to be updated with the present node's link- 421 layer address. 423 Procedures regarding updating caches rely upon Section 7.2.6 of IPv6 424 Neighbour Discovery [RFC4861], which allows proxies to neighbour 425 advertise to all-nodes with the override flag set when becoming a 426 proxy or addresses change. 428 For either environment, updates are required to neighbour cache 429 entries which may be for SEND nodes. These advertisements must 430 therefore have enough authority to override neighbour cache entries 431 even though they are secured. 433 4. Proxy Neighbour Discovery and SEND 435 There are currently no existing secured Neighbour Discovery 436 procedures for proxied addresses, and all Neighbour Advertisements 437 from SEND nodes are required to have equal source and target 438 addresses, and be signed by the transmitter (section 7.4 of 439 [RFC3971]). 441 Signatures over SEND messages are required to be applied on the CGA 442 source address of the message, and there is no way of indicating that 443 a message is proxied. 445 Even if the message is able to be transmitted from the original 446 owner, differences in link-layer addressing and options require 447 modification by a proxy. If a message is signed with a CGA-based 448 signature, the proxy is unable to regenerate a signature over the 449 changed message as it lacks the keying material. 451 Therefore, a router wishing to provide proxy Neighbour Advertisement 452 service can not use existing SEND procedures on those messages. 454 A host may wish to establish a session with a device which is not on- 455 link but is proxied. As a SEND host, it prefers to create neighbour 456 cache entries using secured procedures. Since SEND signatures cannot 457 be applied to an existing proxy Neighbour Advertisement, it must 458 accept non-SEND advertisements in order to receive proxy Neighbour 459 Advertisements. 461 Neighbour Cache spoofing of another node therefore becomes trivial, 462 as any address may be proxy advertised to the SEND node, and 463 overridden only if the node is there to protect itself. When a node 464 is present to defend itself, it may also be difficult for the 465 solicitor determine the difference between a proxy-spoofing attack, 466 and a situation where a proxied device returns to a link and 467 overrides other proxy advertisers [RFC4861]. 469 4.1. CGA signatures and Proxy Neighbour Discovery 471 SEND defines one public-key and signature format for use with 472 Cryptographically Generated Addresses (CGAs) [RFC3971]. CGAs are 473 intended to tie address ownership to a particular Public/Private key 474 pair. 476 In SEND as defined today, Neighbour Discovery Messages (including the 477 IP Addresses from the IPv6 header) are signed with the same key used 478 to generate the CGA. This means that message recipients have proof 479 that the signer of the message owned the address. 481 Where a proxy replaces the message source with its own CGA, the 482 existing CGA option and RSA signature option need to be replaced with 483 the proxy's. Such a message will validate using SEND, except that 484 the Target Address field will not match the IPv6 Source Address in 485 Neighbour Advertisements [RFC3971]. 487 Additional authorization information may be needed to prove that the 488 proxy is indeed allowed to advertise for the target address, as is 489 described in Section 5. 491 4.2. Non-CGA signatures and Proxy Neighbour Discovery 493 Where a proxy retains the original source address in a proxied 494 message, existing SEND-CGA checks will fail, since fields within the 495 message will be changed. In order to achieve secured proxy neighbour 496 discovery in this case, new signature authentication mechanisms may 497 be needed for SEND. 499 SEND provides interfaces for extension of SEND to non-CGA based 500 authorization. Messages are available for Authorization Delegation 501 Discovery, which is able to carry arbitrary PKIX/X.509 certificates 502 [RFC3280]. 504 There is no specification though of keying information option formats 505 analogous to the SEND CGA Option [RFC3971]. The existing option 506 allows a host to verify message integrity by specifying a key and 507 algorithm for digital signature, without providing authorization for 508 functions other than CGA ownership. 510 The digital signature in SEND is transported in the RSA Signature 511 Option. As currently specified, the signature operation is performed 512 over a CGA Message type, and infers support for CGA verification. 513 Clarification or changing of this issue for non-CGA operations may be 514 necessary. 516 Within SEND, more advanced functions such as routing may be 517 authorized by certificate path verification using Authorization 518 Delegation Discovery. 520 With non-CGA signatures and authentication, certificate contents for 521 authorization may need to be determined, as outlined in Section 5. 523 While SEND provides for extensions to new non-CGA methods, existing 524 SEND hosts may silently discard messages with unverifiable RSA 525 signature options (Section 5.2.2 of [RFC3971]), if configured only to 526 accept SEND messages. In cases where unsecured neighbour cache 527 entries are still accepted, messages from new algorithms will be 528 treated as unsecured. 530 4.3. Securing proxy DAD 532 Initiation of Proxy Neighbour Discovery also requires Duplicate 533 Address Detection (DAD) checks of the address [RFC4862]. These DAD 534 checks need to be performed by sending Neighbour Solicitations, from 535 the unspecified source address, with the target being the proxied 536 address. 538 In existing SEND procedures, the address which is used for CGA tests 539 on DAD NS is the target address. A Proxy which originates this 540 message while the proxied address owner is absent is unable to 541 generate a CGA-based signature for this address and must undertake 542 DAD with an unsecured NS. It may be possible that the proxy can 543 ensure that responding NA's are secured though. 545 Where bridge-like ND proxy operations are being performed, DAD NS's 546 may be copied from the original source, without modification 547 (considering they have an unspecified source address and contain no 548 link-layer address options) [RFC4389] 550 If non-CGA based signatures are available, then the signature over 551 the DAD NS doesn't need to have a CGA relationship to the Target 552 Address, but authorization for address configuration needs to be 553 shown using certificates. Where SEND-only nodes do not understand 554 the signature format. 556 5. Potential Approaches to Securing Proxy ND 558 SEND nodes already have the concept of delegated authority through 559 requiring external authorization of routers to perform their routing 560 and advertisement roles. The authorization of these routers takes 561 the form of delegation certificates. 563 Proxy Neighbour Discovery requires a delegation of authority on 564 behalf of the absent address owner, to the proxier. Without this 565 authority, other devices on the link have no reason to trust an 566 advertiser. 568 For bridge-like proxies, it is assumed that there is no preexisting 569 trust between the host owning the address and the proxy. Therefore, 570 authority may necessarily be dynamic or based on topological roles 571 within the network [RFC4389]. 573 Existing trust relationships lend themselves to providing authority 574 for proxying in two alternative ways. 576 First, the SEND router authorization mechanisms described above 577 provide delegation from the organization responsible for routing in 578 an address domain, to the certified routers. It may be argued that 579 routers so certified may be trusted to provide service for nodes 580 which form part of a link's address range, but are themselves absent. 581 Devices which are proxies could either be granted the right to proxy 582 by the network's router, or be implicitly allowed to proxy by virtue 583 of being an authorized router. 585 Second, where the proxied address is itself a CGA, the holder of the 586 public and private keys is seen to be authoritative about the 587 address' use. If this address owner was able to sign the proxier's 588 address and public key information, it would be possible to identify 589 that the proxy is known and trusted by the CGA address owner for 590 proxy service. This method requires that the proxied address know or 591 learn the proxy's address and public key, and that the certificate 592 signed by the proxied node's is passed to the proxy, either while 593 they share the same link, or at a later stage. 595 In both methods, the original address owner's advertisements need to 596 override the proxy if it suddenly returns, and therefore timing and 597 replay protection from such messages need to be carefully considered. 599 5.1. Secured Proxy ND and Mobile IPv6 601 Mobile IPv6 has a security association between the Mobile Node and 602 Home Agent. The Mobile Node sends a Binding Update to the Home 603 Agent, to indicate that it is not at home. This implies that the 604 Mobile Node wishes the Home Agent to begin proxy Neighbour Discovery 605 operations for its home address(es). 607 5.1.1. Mobile IPv6 and Router-based authorization 609 A secured Proxy Neighbour Advertisements proposal based on existing 610 router trust would require no explicit authorization signalling 611 between HA and MN to allow proxying. Hosts on the home link will 612 believe proxied advertisements solely because they come from a 613 trusted router. 615 Where the home agent operates as a router without explicit trust to 616 route from the advertising routing infrastructure (such as in a home, 617 with a router managed by an ISP), more explicit proxying 618 authorization may be required, as described in Section 5.2. 620 5.1.2. Mobile IPv6 and per-address authorization 622 Where proxy Neighbour Discovery is delegated by the MN to the home 623 agent, the MN needs to learn the public key for the Home Agent, so 624 that it can generate a certificate authorizing the public-private 625 key-pair to be used in proxying. It may conceivably either do this 626 using Certificate Path Solicitations over a home tunnel, over the 627 Internet, or Router Discovery while still at home [RFC3971] 628 [RFC3775]. 630 When sending its Binding Update to the HA, the MN would need to 631 provide a certificate containing the subject(proxy-HA)'s public key 632 and address, the issuer(MN)'s CGA and public key, and timestamps 633 indicating when the authority began and when it ends. This 634 certificate would need to be passed near to binding time, possibly in 635 a Certificate Path Advertisement [RFC3971]. Messaging or such an 636 exchange mechanism would have to be developed. 638 5.2. Secured Proxy ND and Bridge-like proxies 640 In link-extension environments, the role of a proxy is more 641 explicitly separated from that of a router. In SEND, routers may 642 expect to be authorized by the routing infrastructure to advertise, 643 and provide this authority to hosts in order to allow them to change 644 forwarding state. 646 Proxies are not part of the traditional infrastructure of the 647 Internet, and hosts or routers may not have an explicit reason to 648 trust them, except that they can forward packets to regions where 649 otherwise they could not reach. 651 5.2.1. Authorization Delegation 653 If a proxy can convince a device that it should be trusted to perform 654 proxying function, it may require that device to vouch for its 655 operation in dealing with other devices. It may do this by receiving 656 a certificate, signed by the originating device that the proxy is 657 believed capable of proxying under certain circumstances. 659 This allows nodes receiving proxied neighbour discovery packets to 660 quickly check if the proxy is authorized for the operation. There 661 are several bases for such trust, and requirements in proxied 662 environments, which are discussed below. 664 5.2.2. Unauthorized routers and proxies 666 Routers advertising on networks without routers may have to operate 667 with no explicit authorization, and SEND hosts will configure these 668 if there's no other option [RFC3971]. While proxies may similarly 669 attempt to advertise without authority, this provides no security for 670 the routing infrastructure. Any device can set up to be a SEND 671 proxy/router so long as it signs its own ND messages from its CGA. 673 This may not help in the case that a proxy attempts to update 674 neighbour cache entries for SEND node which moves between links, 675 since the SEND node's authority to advertise its own CGA address 676 would not be superceded by a proxy with no credentials. 678 5.2.3. Multiple proxy spans 680 Proxies may have multiple levels of nesting, which allow the network 681 to connect between non-adjacent segments. 683 In this case, authority delegated at one point will have to be 684 redelegated (possibly in a diluted form) to proxies further away from 685 the origin of the trust. 687 Trust ProxyA ProxyB Distant 688 Origin - T Node - D 690 +-----+ +-----+ 691 | | | | 692 +-----+ +-----+ +-----+ +-----+ 693 | | | | | | 694 ------------| |------------| |---------- 695 | | | | 696 +-----+ +-----+ 697 ==========> ==============> ==========> 698 Deleg(A,T) Deleg(B,Deleg(T,A)) Advertise(D, Deleg(B, 699 Deleg(A,T)) 701 Figure 7 703 As shown in Figure 7, the Proxy A needs to redelegate authority to 704 proxy for T to B, this allows it to proxy advertisements back to D, 705 which target T. 707 5.2.4. Routing Infrastructure Delegation 709 Where it is possible for the proxy to pre-establish trust with the 710 routing infrastructure, or at least to the local router, it may be 711 possible to authorize proxying as a function of routing within the 712 subnet. The router or CA may then be able to certify proxying for 713 only a subset of the prefixes which is itself certified for. 715 If a router or CA provides certification for a particular prefix, it 716 may be able to indicate that only proxying is supported, so that 717 neighbour cache entries of routers connected to internet 718 infrastructure are never overridden by the proxy, if the router is 719 present on a segment. 721 Hosts understanding such certificates may allow authorized proxies 722 and routers to override host SEND/CGA when assuming proxy roles, if 723 the host is absent. 725 Proxy certificate signing could be done either dynamically (requiring 726 exchanges of identity and authorization information), or statically 727 when the network is set up. 729 5.2.5. Local Delegation 731 Where no trust tie exists between the authority which provides the 732 routing infrastructure and the provider of bridging and proxying 733 services, it may still be possible for SEND hosts to trust the 734 bridging provider to authorize proxying operations. 736 SEND itself requires that routers be able to show authorization, but 737 doesn't require routers to have a single trusted root. 739 A local bridging/proxying authority trust delegation may be possible. 740 It would be possible for this authority to pass out local use 741 certificates, allowing proxying on a specific subnet or subnets, with 742 a separate authorization chain to that for the routers with Internet 743 access. 745 This would require little modification to SEND, other than addition 746 of router based proxy authority (as in Section 5.2.4), and proxies 747 would in effect be treated as routers by SEND hosts [RFC3971]. 748 Distribution of keying and trust material for the initial bootstrap 749 of proxies would not be provided though (and may be static). 751 Within small domains, key management and distribution may be a 752 tractable problem, so long as these operations are are simple enough 753 to perform. 755 Since these domains may be small, it may be necessary to provide 756 certificate chains for trust anchors which weren't requested in 757 Certificate Path Solicitations, if the proxy doesn't have a trust 758 chain to any requested trust anchor. 760 This is akin to 'suggesting' an appropriate trusted root. It may 761 allow for user action in allowing trust extension when visiting 762 domains without ties to a global keying infrastructure. In this 763 case, the trust chain would have to start with a self-signed 764 certificate from the original CA. 766 5.2.6. Host delegation of trust to proxies 768 Unlike Mobile IPv6, for bridge-like proxied networks, there is no 769 existing security association upon which to transport proxying 770 authorization credentials. 772 Proxies need then to convince neighbours to delegate proxy authority 773 to them, in order to proxy-advertise to nodes on different segments. 774 It will be difficult without additional information to distinguish 775 between legitimate proxies, and devices which have no need or right 776 to proxy (and may wish two network segments to appear to be 777 connected). 779 When proxy advertising, proxies must not only identify that proxying 780 needs to occur, but provide proof that they are allowed to do so, so 781 that SEND Neighbour Cache entries may be updated. Unless the 782 authorization to update such entries is tied to address ownership 783 proofs from the proxied host or the verifiable routing 784 infrastructure, spoofing may occur. 786 When a host received a proxied neighbour advertisement, it would be 787 necessary to check authorization in the same way that authorization 788 delegation discovery is performed in SEND. 790 Otherwise, certificate transport will be required to exchange 791 authorization between proxied nodes and proxies. 793 Proxies would have to be able to delegate this authorization to 794 downstream proxies, as described in Section 5.2.3. 796 Movement between segments could be controlled with increasing 797 certificate sequence numbers and timestamps. The timestamp of the 798 root authority (in this case, the CGA address owner) would be most 799 significant. Where ties exist, the shortest chain would supercede, 800 as this would indicate a proxy closer to the proxied node. 802 5.3. Proxying unsecured addresses 804 Where the original neighbour discovery message is unsecured, there is 805 an argument for not providing secured proxy service for that node. 807 In both the Mobile IPv6 and extended networks cases, the node may 808 arrive back at the network and require other hosts to map their 809 existing neighbour cache entry to the node's link-layer address. The 810 re-arriving node's overriding of link-layer address mappings will 811 occur without SEND in this case. 813 It is notable that without SEND protection any node may spoof the 814 arrival, and effectively steal service across an extended network. 815 This is the same as in the non-proxy case, and is not made 816 significantly worse by the proxy's presence (although the identity of 817 the attacker may be masked if source addresses are being replaced). 819 If signatures over the proxied messages were to be used, re-arrival 820 and override of the neighbour cache entries would have to be allowed, 821 so the signatures would indicate that at least the proxy wasn't 822 spoofing (even if the original sender was). 824 For non-SEND/CGA routers, though, it may be possible for secured 825 proxies to send signed router advertisement messages, in order to 826 ensure that routers aren't spoofed, and subsequently switched to 827 being on different parts of the extended network. 829 This has problems in that the origin is again unsecured, and any node 830 on the network could spoof router advertisement for an unsecured 831 address. These spoofed messages may become almost indistinguishable 832 (except for the non-CGA origin address) from unspoofed messages from 833 SEND routers. 835 Given these complexities, the simplest method is to allow unsecured 836 devices to be spoofed from any port on the network, as is the case 837 today. 839 6. IANA Considerations 841 No new options or messages are defined in this document. 843 7. Security Considerations 845 7.1. Router Trust Assumption 847 Router based authorization for Secured Proxy ND may occur without the 848 knowledge or consent of a device. It is susceptible to the 'Good 849 Router Goes Bad' attack described in [RFC3756]. 851 7.2. Certificate Transport 853 The certification delegation relies upon transfer of the new 854 credentials to the proxying HA in order to undertake ND proxy on its 855 behalf. Since the Binding cannot come into effect until DAD has 856 taken place, the delegation of the proxying authority necessarily 857 predates the return of the Binding Ack, as described in [RFC3775]. 858 In the above described case, the home tunnel which comes into 859 creation as part of the binding process may be required for 860 Certificate Path Solicitation or Advertisement transport [RFC3971]. 861 This constitutes a potential chicken-and-egg problem. Either 862 modifications to initial home binding semantics or certificate 863 transport are required. This may be trivial if signed, non- 864 repudiable certificates are sent in the clear between the MN's CoA 865 and the HA without being tunneled. 867 7.3. Timekeeping 869 All of the presented methods rely on accurate timekeeping on the 870 receiver nodes of Neighbour Discovery Timestamp Options and 871 certificates. 873 For router-authorized proxy ND, a neighbour may not know that a 874 particular ND message is replayed from the time when the proxied host 875 was still on-link, since the message's timestamp falls within the 876 valid timing window. Where the router advertises its secured proxy 877 NA, a subsequent replay of the old message will override the NC entry 878 created by the proxy. 880 Creating the neighbour cache entry in this way, without reference to 881 accurate subsequent timing, may only be done once. Otherwise the 882 receiver will notice that the timestamp of the advertisement is old 883 or doesn't match. 885 One way of creating a sequence of replayable messages which have 886 timestamps likely to be accepted is to pretend to do an unsecured DAD 887 on the address each second while the MN is at home. The attacker 888 saves each DAD defence in a sequence. The granularity of SEND 889 timestamp matching is around 1 second, so the attacker has a set of 890 SEND NA's to advertise, starting at a particular timestamp, and valid 891 for as many seconds as the original NA gathering occurred. 893 This sequence may then be played against any host which doesn't have 894 a timestamp history for that MN, by tracking the number of seconds 895 elapsed since the initial transmission of the replayed NA to that 896 victim, and replaying the appropriate cached NA. 898 Where certificate based authorization of ND proxy is in use, the 899 origination/starting timestamp of the delegated authority may be used 900 to override a replayed (non-proxy) SEND NA, while also ensuring that 901 the Proxy NA's timestamp (provided by the proxy) is fresh. A 902 returning MN would advertise a more recent timestamp than the 903 delegated authority and thus override it. This method is therefore 904 not subject to the above attack, since the proxy advertisement's 905 certificate will have a timestamp greater than any replayed messages, 906 preventing it from being overridden. 908 8. Acknowledgments 910 James Kempf and Dave Thaler particularly contributed to work on this 911 document. Contributions to discussion on this topic helped to 912 develop this document. Thanks go to Jari Arkko, Vijay Devarapalli, 913 and Mohan Parthasarathy. 915 Jean-Michel Combes is partly funded by MobiSEND, a research project 916 supported by the French 'National Research Agency' (ANR). 918 9. References 920 9.1. Normative References 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 926 in IPv6", RFC 3775, June 2004. 928 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 929 Neighbor Discovery (SEND)", RFC 3971, March 2005. 931 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 932 RFC 3972, March 2005. 934 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 935 July 2005. 937 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 938 RFC 4306, December 2005. 940 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 941 Proxies (ND Proxy)", RFC 4389, April 2006. 943 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 944 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 945 September 2007. 947 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 948 Address Autoconfiguration", RFC 4862, September 2007. 950 9.2. Informative References 952 [I-D.ietf-netlmm-mn-ar-if] 953 Laganier, J., Narayanan, S., and P. McCann, "Interface 954 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 955 Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), 956 February 2008. 958 [I-D.ietf-netlmm-proxymip6] 959 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 960 and B. Patil, "Proxy Mobile IPv6", 961 draft-ietf-netlmm-proxymip6-10 (work in progress), 962 February 2008. 964 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 965 X.509 Public Key Infrastructure Certificate and 966 Certificate Revocation List (CRL) Profile", RFC 3280, 967 April 2002. 969 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 970 Discovery (ND) Trust Models and Threats", RFC 3756, 971 May 2004. 973 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 974 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 975 RFC 3963, January 2005. 977 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 978 Bellier, "Hierarchical Mobile IPv6 Mobility Management 979 (HMIPv6)", RFC 4140, August 2005. 981 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 982 Architecture", RFC 4291, February 2006. 984 Appendix A. Two ore more nodes defending a same address 986 The main part of this document focuses on the case where two nodes 987 defend a same address (i.e. the node and the proxy). But, there are 988 scenarios where two or more nodes are defending a same address. This 989 is at least the case for: 991 o Nodes having the same address, as the MAG's ingress link-local 992 address in PMIPv6 [I-D.ietf-netlmm-mn-ar-if]. 994 o Nodes having a common anycast address [RFC4291]. 996 The problem statement, described previously in this document, applies 997 for these cases and the issues are the same from a signalling point 998 of view. 1000 In the first case, [I-D.ietf-netlmm-mn-ar-if] assumes that the 1001 security material used by SEND (i.e. public-private key pair) is 1002 shared between all the MAGs. For the second case, there is no 1003 solution today. But, in a same way, it should be possible to assume 1004 that the nodes having a common anycast address could also share the 1005 security material. 1007 It is important to notice that when many nodes defending a same 1008 address are not in the same administrative domain (e.g. MAGs in 1009 different administrative domains but in a same PMIPv6 domain 1010 [I-D.ietf-netlmm-proxymip6]), sharing the security material used by 1011 SEND may raise a security issue. 1013 Appendix B. Changes from the previous versions 1015 To be removed prior to publication as an RFC. 1017 Previous version: draft-daley-send-spnd-prob-01 1018 o Reorganisation of the draft structure. 1020 o Addition of the section "Fixed Nodes and Neighbor Discovery 1021 Proxy". 1023 o Update of the references. 1025 o Addition of the Appendix "Two ore more nodes defending a same 1026 address" 1028 o Addition of the Appendix "Changes from the previous version". 1030 Authors' Addresses 1032 Greg Daley 1033 55 Pakington St 1034 Kew, Victoria 3101 1035 Australia 1037 Phone: +61 405 494849 1038 Email: hoskuld@hotmail.com 1040 Jean-Michel Combes 1041 Orange Labs/France Telecom R&D 1042 38 rue du General Leclerc 1043 92794 Issy-les-Moulineaux Cedex 9 1044 France 1046 Email: jeanmichel.combes@gmail.com 1048 Full Copyright Statement 1050 Copyright (C) The IETF Trust (2008). 1052 This document is subject to the rights, licenses and restrictions 1053 contained in BCP 78, and except as set forth therein, the authors 1054 retain all their rights. 1056 This document and the information contained herein are provided on an 1057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1059 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1060 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1061 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Intellectual Property 1066 The IETF takes no position regarding the validity or scope of any 1067 Intellectual Property Rights or other rights that might be claimed to 1068 pertain to the implementation or use of the technology described in 1069 this document or the extent to which any license under such rights 1070 might or might not be available; nor does it represent that it has 1071 made any independent effort to identify any such rights. Information 1072 on the procedures with respect to rights in RFC documents can be 1073 found in BCP 78 and BCP 79. 1075 Copies of IPR disclosures made to the IETF Secretariat and any 1076 assurances of licenses to be made available, or the result of an 1077 attempt made to obtain a general license or permission for the use of 1078 such proprietary rights by implementers or users of this 1079 specification can be obtained from the IETF on-line IPR repository at 1080 http://www.ietf.org/ipr. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights that may cover technology that may be required to implement 1085 this standard. Please address the information to the IETF at 1086 ietf-ipr@ietf.org. 1088 Acknowledgment 1090 Funding for the RFC Editor function is provided by the IETF 1091 Administrative Support Activity (IASA).