idnits 2.17.1 draft-ietf-csi-proxy-send-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (September 28, 2010) is 4952 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CGA' is mentioned on line 595, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-csi-send-cert-07 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CGA & SEND maintenance Working S. Krishnan 3 Group Ericsson 4 Internet-Draft J. Laganier 5 Intended status: Experimental QUALCOMM Inc. 6 Expires: April 1, 2011 M. Bonola 7 Rome Tor Vergata University 8 A. Garcia-Martinez 9 UC3M 10 September 28, 2010 12 Secure Proxy ND Support for SEND 13 draft-ietf-csi-proxy-send-05 15 Abstract 17 Secure Neighbor Discovery (SEND) specifies a method for securing 18 Neighbor Discovery (ND) signaling against specific threats. As 19 defined today, SEND assumes that the node sending a ND message is the 20 owner of the address from which the message is sent and/or posses a 21 key which authorizes the node to act as a router, so that it is in 22 possession of the private key or keys used to generate the digital 23 signature on each message. This means that the Proxy ND signaling 24 performed by nodes that do not possess knowledge of the address 25 owner's private key and/or knowledge of a router's key cannot be 26 secured using SEND. This document extends the current SEND 27 specification in order to secure Proxy ND operation. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 1, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6 67 5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8 68 5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8 69 5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10 70 5.2.1. Processing rules for senders . . . . . . . . . . . . . 10 71 5.2.2. Processing rules for receivers . . . . . . . . . . . . 11 72 5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 13 73 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 14 75 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15 76 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 18 77 7. Backward Compatibility with RFC3971 nodes and non-SEND 78 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20 80 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for 98 securing Neighbor Discovery (ND) signaling [RFC4861] against specific 99 threats [RFC3756]. As defined today, SEND assumes that the node 100 sending a ND message is the owner of the address from which the 101 message is sent and/or posses a key which authorizes the node to act 102 as a router, so that it is in possession of the private key or keys 103 used to generate the digital signature on each message. This means 104 that the Proxy ND signaling performed by nodes that do not possess 105 knowledge of the address owner's private key and/or knowledge of a 106 router's key cannot be secured using SEND. 108 This document extends the current SEND specification with support for 109 Proxy ND. From this point on we refer to such extension as "Secure 110 Proxy ND Support for SEND". 112 3. Terminology 114 Secure ND Proxy 116 A node authorized to secure a Neighbor Discovery Protocol (NDP) 117 message without knowing the private key related to the source 118 address of the node, or the key related to the router 119 authorization, for which the node acts on behalf. 121 Proxied IPv6 address 123 An IPv6 address that does not belong to the Secure ND Proxy and 124 for which the Secure ND Proxy is performing advertisements. 126 Non-SEND node 128 An IPv6 node that does not implement the SEND [RFC3971] 129 specification but uses the ND protocol defined in [RFC4861] and 130 [RFC4862], without additional security. 132 RFC3971 node 134 An IPv6 node that does not implement the specification defined in 135 this document for Secure Proxy ND support, but uses the SEND 136 specification as defined in [RFC3971]. 138 SPND node 140 An IPv6 node that receives and validates messages according to the 141 specification defined in this document for Secure Proxy ND 142 support. 144 Translated NDP message 146 A NDP message issued by a Secure ND Proxy as a result of a 147 received NDP message originated by the owner of the address or 148 originated by another node acting on behalf of the owner of the 149 address. 151 Synthetic NDP message 153 A NDP message issued by a Secure ND Proxy that is not the result 154 of a received NDP message. 156 4. Secure Proxy ND Overview 158 The original SEND specification [RFC3971] has implicitly assumed that 159 only the node sending a ND message is the owner of the address from 160 which the message is sent. This assumption does not allow proxying 161 of ND messages since the advertiser is required to generate a valid 162 RSA Signature option, which in turns requires possession of the 163 public-private key pair that was used to generate a CGA, or that was 164 associated to a router certificate. 166 To be able to separate the roles of ownership and advertiser the 167 following extensions to the SEND protocol are defined: 169 o A Secure Proxy ND certificate, which is a certificate authorizing 170 an entity to act as an ND proxy. It is a X509v3 certificate in 171 which the purpose for which the certificate is issued has been 172 specified explicitly as described in a companion document 173 [I-D.ietf-csi-send-cert]. Briefly, Secure Proxy ND certificates 174 include one or more KeyPurposeId values which can be used for 175 authorizing proxies to sign RA and Redirect messages, or to sign 176 NA, NS or RS messages on behalf or other nodes. The inclusion of 177 this value allows the certificate owner to perform proxying of 178 SEND messages for a range of addresses indicated in the same 179 certificate. This certificate can be exchanged through the 180 Authorization Delegation Discovery process defined in [RFC3971]. 182 o A new Neighbor Discovery option called Proxy Signature (PS) 183 option. This option contains the hash value of the public key of 184 the proxy, and the digital signature of the SEND message computed 185 with the private key of the proxy. The hash of the public key of 186 the proxy is computed over the public key contained in the Secure 187 Proxy ND's certificate. When a ND message contains a PS option, 188 it MUST NOT contain CGA or RSA Signature options. This option 189 MUST be appended to any NDP message (NA, NS, RS, RA and Redirect) 190 to secure it. 192 o A modification of the SEND processing rules for all ND messages: 193 NA, NS, RS, RA, and Redirect. When any of these messages 194 containing a Proxy Signature option is validated, it is considered 195 as secure. 197 These extensions are applied in the following way: 199 o A Secure ND Proxy which proxies ND messages on behalf of a node 200 can use the PS option to protect the proxied messages. This 201 Secure ND Proxy becomes part of the trusted infrastructure just 202 like a SEND router. 204 o In order to allow nodes to successfully validate secured proxied 205 messages, the nodes MUST be aware of the Secure Proxy ND 206 certificate (in the format described in [I-D.ietf-csi-send-cert]) 207 and MUST apply the modified processing rules specified in this 208 document. We call these nodes 'SPND nodes'. Note that the rules 209 for generating ND messages in SPND nodes do not change, so these 210 nodes behave as defined in [RFC3971] when they send ND messages. 212 o To allow SPND nodes to know the certificate path required to 213 validate the public key of the proxy, devices responding to CPS 214 (Certification Path Solicitation) messages with CPA (Certification 215 Path Advertisements) as defined in Section 6 of SEND specification 216 [RFC3971] are extended to support the certificate format specified 217 in [I-D.ietf-csi-send-cert], and are configured with the 218 appropriate certification path. 220 5. Secure Proxy ND Specification 222 A Secure ND Proxy performs all the operations described in the SEND 223 specification [RFC3971] with the addition of new processing rules to 224 ensure that the receiving node can identify an authorized proxy 225 generating a translated or synthetic SEND message for a proxied 226 address. 228 This is accomplished by signing the message with a private key of the 229 authorized Secure ND Proxy. The signature of the ND Proxy is 230 included in a new option called Proxy Signature (PS) option. The 231 signature is performed over all the Neighbor Discovery Protocol (NDP) 232 options present in the message and the PS option is appended as the 233 last option in the message. 235 5.1. Proxy Signature Option 237 The Proxy Signature option allows public key-based signatures to be 238 attached to NDP messages. The format of the PS option is described 239 in the following diagram: 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 | Key Hash | 248 | | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 . . 253 . Digital Signature . 254 . . 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 . . 259 . Padding . 260 . . 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 1: PS option layout 266 Type 268 TBA 270 Length 272 The length of the option (including the Type, Length, Reserved, 273 Key Hash, Digital Signature, and Padding fields) in units of 8 274 octets. 276 Reserved 278 A 16-bit field reserved for future use. The value MUST be 279 initialized to zero by the sender, and MUST be ignored by the 280 receiver. 282 Key Hash 284 A 128-bit field containing the most significant (leftmost) 128 285 bits of a SHA-1 [SHA1] hash of the public key used for 286 constructing the signature. Its purpose is to associate the 287 signature to a particular key known by the receiver. Such a key 288 MUST be the same one within the corresponding Secure Proxy ND's 289 certificate. 291 Digital Signature 293 A variable-length field containing a PKCS#1 v1.5 signature, 294 constructed by using the sender's private key over the following 295 sequence of octets: 297 1. The 128-bit CGA Message Type tag [RFC3972] value for Secure 298 Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag 299 value has been generated randomly by the editor of this 300 specification). 302 2. The 128-bit Source Address field from the IP header. 304 3. The 128-bit Destination Address field from the IP header. 306 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 307 the ICMP header. 309 5. The NDP message header, starting from the octet after the ICMP 310 Checksum field and continuing up to but not including NDP 311 options. 313 6. All NDP options preceding the Proxy Signature option. 315 The signature value is computed with the RSASSA-PKCS1-v1_5 316 algorithm and SHA-1 hash, as defined in [RSA]. 318 This field starts after the Key Hash field. The length of the 319 Digital Signature field is determined by the ASN.1 BER coding of 320 the PKCS#1 v1.5 signature. 322 Padding 324 This variable-length field contains padding. The length of the 325 padding field is determined by the length of the Proxy Signature 326 Option minus the length of the other fields. 328 5.2. Modified SEND processing rules 330 This specification modifies the sender and receiver processing rules 331 defined in the SEND specification [RFC3971]. 333 5.2.1. Processing rules for senders 335 A Secure ND Proxy MUST NOT use a key to sign NDP message types which 336 do not correspond to the authorization granted to the considered key. 337 NA, NS and RS messages MUST be signed with a key corresponding to a 338 Secure Proxy ND certificate with a KeyPurposeId value 339 [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source 340 addresses of the messages MUST be encompassed in the prefix 341 associated to the certificate. RA and Redirect messages MUST be 342 signed with a key corresponding to a Secure Proxy ND certificate with 343 a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included 344 in the RA message for on-link determination and/or stateless address 345 autoconfiguration, and the Target Address of the Redirect message, 346 MUST be encompassed in the prefix associated to that certificate. 348 A secured NDP message sent by a Secure ND Proxy for a proxied address 349 MUST contain a PS option and MUST NOT contain either CGA or RSA 350 Signature options. Section 7 discusses in which cases a NDP message 351 has to be secured in an scenario including non-SEND nodes. 353 A Secure ND Proxy sending a secured message on behalf of other node 354 MUST construct the message as follows: 356 1. The SEND message is constructed without the PS option as follows: 358 A. If the Secure ND Proxy is generating a synthetic SEND message 359 for a proxied address, the message MUST be constructed as 360 described in Neighbor Discovery for IP version 6 361 specification [RFC4861]. 363 B. If the Secure ND Proxy is generating a translated SEND 364 message, first the authenticity of the intercepted message 365 MUST be verified as specified in SEND specification 366 [RFC3971], Section 5. If the SEND message is valid, any CGA 367 or RSA option MUST be removed from the message. The 368 intercepted message is finally modified as described in 369 Section 4 of the ND Proxy specification [RFC4389]. 371 C. If the Secure ND Proxy is translating a SEND message already 372 containing a PS option, first the authenticity of the 373 intercepted message is verified as specified in Section 5.2.2 374 of this specification. If the SEND message is valid, the 375 original PS option MUST be removed from the message. The 376 intercepted message is finally modified as described in 377 Section 4 of the ND Proxy specification [RFC4389]. 379 2. Timestamp and Nonce options MUST be included according to the 380 rules specified in SEND [RFC3971]. The value in the Timestamp 381 option MUST be generated by the proxy. If the proxy is 382 translating a message which includes a Nonce, the Nonce value in 383 the proxied message MUST be the same as in the intercepted 384 message. If the proxy is synthesizing a solicitation message, 385 the Nonce value MUST be generated by the proxy. If the proxy is 386 synthesizing an advertisement message, the Nonce value MUST 387 correspond to the solicitation message to which the proxy is 388 responding. 390 3. The Proxy Signature option MUST be added as the last option in 391 the message. 393 4. The data MUST be signed as explained in Section 5.1. 395 5.2.2. Processing rules for receivers 397 Any SEND message without a Proxy Signature option MUST be treated as 398 specified in the SEND specification [RFC3971]. 400 A SEND message including a Proxy Signature option MUST be processed 401 as specified below: 403 1. The receiver MUST ignore any RSA and CGA options, as well as any 404 options that might come after the first PS option. The options 405 are ignored for both signature verification and NDP processing 406 purposes. 408 2. The Key Hash field MUST indicate the use of a known public key. 409 A valid certification path (see [I-D.ietf-csi-send-cert] Section 410 9) between the receiver's trust anchor and the sender's public 411 key MUST be known. The Secure Proxy ND's X509v3 certificate MUST 412 contain an extended key usage extension including the appropriate 413 KeyPurposeId value and prefix for the message to validate: 415 * For RA messages, a KeyPurposeId value of id-kp- 416 sendProxiedRouter MUST exist for the certificate, and the 417 prefix included in the RA message for on-link determination 418 and/or stateless address autoconfiguration MUST be encompassed 419 in the prefix associated to that certificate. 421 * For Redirect messages, a KeyPurposeId value of id-kp- 422 sendProxiedRouter MUST exist for the certificate, and the 423 prefix included in the Target Address of the Redirect message 424 MUST be encompassed in the prefix associated to that 425 certificate. 427 * For NA, NS and RS messages, a KeyPurposeId value of id-kp- 428 sendProxiedOwner MUST exist for the certificate, and the 429 source addresses of the messages MUST be encompassed in the 430 prefix associated to the certificate. 432 If any of these tests fails, the verification fails. 434 3. The Digital Signature field MUST have correct encoding, otherwise 435 the verification of the message including the PS option fails. 437 4. The Digital Signature verification MUST show that the signature 438 has been calculated as specified in Section 5.1, otherwise the 439 verification of the message including the PS option fails. 441 5. The Nonce option MUST be processed as specified in [RFC3971] 442 Section 5.3.4, except for replacing 'RSA Signature option' by 'PS 443 option'; if these tests fail, the verification of the message 444 including the PS option fails. 446 6. The Timestamp option MUST be processed as specified in [RFC3971] 447 Section 5.3.4, except for replacing 'RSA Signature option' by 'PS 448 option'. If these tests fail, the verification of the message 449 including the PS option fails. The receiver SHOULD store the 450 peer-related timing information specified in [RFC3971] Section 451 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each 452 different proxy (which could be identified by the different Key 453 Hash values of the proxied message) and separately from the 454 timing information associated to the IP address of a node for 455 which the message is proxied. In this way, a message received 456 for the first time from a proxy (i.e. for which there is no 457 information stored in the cache) for which the Timestamp option 458 is checked, SHOULD be checked as a message received from a new 459 peer (as in [RFC3971] section 5.3.4.2). 461 7. Messages with the Override bit [RFC4861] set MUST override an 462 existing cache entry regardless if it was created as a result of 463 a RSA Signature option or a PS option validation. When the 464 Override bit is not set, the advertisement MUST NOT update a 465 cached link-layer address created securely by means of RSA 466 Signature option or PS option validation. 468 Messages for which the verification fails MUST be silently discarded 469 if the node has been configured to accept only secured ND messages. 470 The messages MAY be accepted if the host has been configured to 471 accept both secured and unsecured messages but MUST be treated as an 472 unsecured message. 474 5.3. Proxying Link-Local Addresses 476 Secure Neighbor Discovery [RFC3971] relies on certificates to prove 477 that routers are authorized to announce a certain prefix. However, 478 Neighbor Discovery [RFC4861] states that routers do not announce the 479 Link-Local prefix (fe80::/64). Hence, it is not required for a SEND 480 certificate to hold a X.509 extension for IP addresses that 481 authorizes the fe80::/64 prefix. However, some Secure Proxy ND 482 scenarios ([RFC4389], [RFC5213]) impose providing the proxying 483 function for the Link-Local address of a node. When Secure ND proxy 484 functionality for a Link-Local address is required, either a list of 485 link-local addresses, or the fe80::/64 prefix MUST be explicitly 486 authorized to be proxied in the corresponding certificate. 488 6. Application Scenarios 490 In this section we describe three different application scenarios for 491 which Secure Proxy ND support for SEND can be applied. Note that the 492 particular way in which Secure Proxy ND support is applied (which ND 493 messages are proxied, in which direction, how the interaction with 494 non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on 495 the particular scenario considered. In the first two scenarios 496 presented below, ND messages are synthesized on behalf of off-link 497 nodes. In the third one, ND messages are translated from the 498 messages received in other interfaces of the proxy. 500 6.1. Scenario 1: Mobile IPv6 502 The description of the problems for deploying SEND in this scenario 503 is presented in [I-D.ietf-csi-sndp-prob]. 505 The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN) 506 to move from one link to another while maintaining reachability at a 507 stable address, the so-called MN's Home Address (HoA). When a MN 508 attaches to a foreign network, all the packets sent to the MN's HoA 509 by a Correspondent Node (CN) on the home link or a router, are 510 intercepted by the Home Agent (HA) on that home link, encapsulated 511 and tunneled to the MN's registered Care-of Address (CoA). 513 To deploy Secure Proxy ND in this scenario, i.e. to secure the HA 514 operation, a Secure Proxy ND certificate with a KeyPurposeId value of 515 id-kp-sendProxiedOwner for the prefix of the home link is required. 516 The Secure ND Proxy is configured with the private key associated to 517 this certificate. When a NS is intercepted by the HA on the home 518 link, the HA checks if the Target address within the NS matches with 519 any of the MN's Home Address in the Binding Cache and if so, it 520 replies with a Neighbor Advertisement (NA) constructed as described 521 in [RFC4861], containing its own link-layer address (HA_LL) as the 522 Target Link Layer Address Option (TLLAO). Then a timestamp 523 (generated by the proxy) and nonce (if appropriate, according to 524 [RFC3971]), MUST be included. Finally, a PS option signing the 525 message MUST be included as the last option of the message. 527 Node (N) Home Agent (HA) Mobile Node (MN) 528 on Home Link on Home Link on Foreign Link 529 | | | 530 | SRC = N | | 531 | DST = solicited_node(MN) | | 532 | ICMPv6 NS | | 533 | TARGET = MN | | 534 | SLLAO = N_LL | | 535 | [CGA] | | 536 | RSA signature | | 537 |------------------------->| | 538 | | | 539 | SRC = HA | | 540 | DST = N | | 541 | ICMPv6 NA | | 542 | TARGET = MN | | 543 | TLLAO = HA_LL | | 544 | PS signature | | 545 |<-------------------------| | 546 | | | 547 | traffic | | 548 | dest= MN HoA | | 549 |------------------------->| | 550 | | | 551 | | tunneled traffic | 552 | | dest= MN CoA | 553 | |------------------------->| 554 | | | 556 Figure 2: Proxy ND role of the Home agent in MIPv6 558 A node receiving the NA containing the PS option (e.g.: the CN in the 559 home link, or a router) MUST apply the rules defined in 560 Section 5.2.2. Note that in this case the Override bit of the NA 561 message is used to control which messages should prevail on each 562 case: the message generated by the proxy when the MN moves from the 563 home network, or the MN if it comes back to the home link, as defined 564 in the MIPv6 specification [RFC3775]. 566 6.2. Scenario 2: Proxy Mobile IPv6 568 Proxy Mobile IPv6 [RFC5213] is a network-based mobility management 569 protocol that provides IP mobility management support for MNs without 570 requiring MNs being involved in the mobility related signaling. The 571 IP mobility management is totally hidden to the MN in a Proxy Mobile 572 IPv6 domain and it is performed by two functional entities: the Local 573 Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). 575 When the MN connects to a new access link, it sends a muliticast 576 Router Solicitation (RS). The MAG on the new access link, upon 577 detecting the MN's attachment, signals the LMA requesting an update 578 of the binding state of the MN (by means of a Proxy Binding Update - 579 PBU). Once the signaling is completed (it receives a Proxy Binding 580 Ack - PBA), the MAG replies to the MN with a Router Advertisement 581 (RA) containing the home network prefix(es) that were assigned to 582 that mobility session, making the MN believe it is still on the same 583 link, so the IPv6 address reconfiguration procedure is not triggered 584 (Figure 3). 586 MN new MAG LMA 587 | | | 588 MN Attached | | 589 | | | 590 | MN Attached Event from MN/Network | 591 | | | 592 | SRC = MN | | 593 | DST = all-routers | | 594 | ICMPv6 RS | | 595 | [CGA] | | 596 | RSA signature | | 597 |--------------------->| | 598 | | | 599 | |--- PBU ------------->| 600 | | | 601 | | Accept PBU 602 | | | 603 | |<------------- PBA ---| 604 | | | 605 | Accept PBA | 606 | | | 607 | |==== Bi-Dir Tunnel ===| 608 | | | 609 | SRC = MAG4MN | | 610 | DST = MN | | 611 | ICMPv6 RA | | 612 | SLL = MAG_LL | | 613 | PS | | 614 |<---------------------| | 615 | | | 616 | | | 617 | | | 618 Figure 3: Mobile node's handover in PMIPv6 620 To avoid potential link-local address collisions between the MAG and 621 the MN after a handoff to a new link, the Proxy Mobile IPv6 622 specification requires the MAG's link-local address on the link to 623 which the MN is attached to be generated by the LMA when the MN first 624 attaches to a PMIPv6 domain, and to be provided to the new MN's 625 serving MAG after each handoff. Thus, from the MN's point of view, 626 the MAG's link-local address remains constant for the duration of 627 that MN's session. 629 The approach described above and the current SEND specification are 630 incompatible since sharing the same link-local address on different 631 MAGs would require all MAGs of a PMIPv6 domain to construct the CGA 632 and the RSA Signature option with the same public-private key pair, 633 which is not an acceptable security policy. 635 Using different public-private key pairs on different MAGs would mean 636 different MAGs use different CGAs as link-local address. Thus the 637 serving MAG's link-local address would change after each handoff of 638 the MN, which is in contradiction with the way MAG link-local address 639 assignment occurs in a PMIPv6 domain. 641 To provide SEND protection, each MAG MUST be configured to act as a 642 proxy by means of a certificate associated to the PMIPv6 domain, 643 authorizing each MAG to proxy securely NA and RS messages by means of 644 a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the 645 certificate MUST also authorize the MAG to advertise prefixes by 646 associating to the same certificate a KeyPurposeId value of id-kp- 647 sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId 648 values is supported by [I-D.ietf-csi-send-cert]. 650 When a MAG replies to a RS with a RA, the source address MUST be 651 equal to the MAG link-local address associated to the MN in this 652 PMIPv6 domain, with its own link-layer address as Source link-layer 653 address. Then a timestamp (generated by the proxy) and nonce (if 654 appropriate, according to [RFC3971]), MUST be included. Finally, a 655 PS option signing the message MUST be included as the last option of 656 the message. This procedure is followed for any other ND message 657 that could be generated by the MAG to the MN. 659 A node receiving a message from the MAG containing the PS option MUST 660 apply the processing rules defined in Section 5.2.2. Note that 661 unsolicited messages sent by the MAG should be validated by the host 662 according to timestamp values specific to the MAG serving the link, 663 not to any other MAG to which the host has been connected before in 664 other links, according to processing step number 6 of Section 5.2.2. 666 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy 668 The description of the problems for deploying SEND in this scenario 669 is presented in [I-D.ietf-csi-sndp-prob]. 671 Link 1 Link 2 673 Host A ND Proxy (P) Host B 674 | | | 675 | SRC = A | | 676 | DST = solicited_node(B) | | 677 | ICMPv6 NS | | 678 | TARGET = B | | 679 | SLLAO = A_LL | | 680 |------------------------->| | 681 | | SRC = A | 682 | | DST = solicited_node(B) | 683 | | ICMPv6 NS | 684 | | TARGET = B | 685 | | SLLAO = P_LL | 686 | |------------------------->| 687 | | | 688 | | SRC = B | 689 | | DST = A | 690 | | ICMPv6 NA | 691 | | TARGET = B | 692 | | TLLAO = B_LL | 693 | |<-------------------------| 694 | SRC = B | | 695 | DST = A | | 696 | ICMPv6 NA | | 697 | TARGET = B | | 698 | TLLAO = P_LL | | 699 |<-------------------------| | 700 | | | 702 Figure 4: RFC 4389 Neighbor Discovery Proxy operation 704 The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 705 method by which multiple link-layer segments are bridged into a 706 single segment and specifies the IP-layer support that enables 707 bridging under these circumstances. 709 A Secure ND Proxy MUST parse any IPv6 packet it receives on a proxy 710 interface to check whether it contains one of the following NDP 711 messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST 712 verify the authenticity of the received ND message, according to 713 [RFC3971]. If the SEND message is valid, then it proxies the 714 original message with the following changes: 716 1. The message MUST be processed according to [RFC4389]. This 717 includes changing the source link-layer address to the address of 718 the outgoing interface, maintaining the destination link-layer 719 address as the address in the neighbor entry corresponding to the 720 destination IPv6 address, etc. In particular any link-layer 721 address within the payload (that is, in a Source Local Link 722 Address option - SLLAO, or a Target Local Link Address option - 723 TLLAO) is substituted with the link-layer address of the outgoing 724 interface. 726 2. Any CGA or RSA option MUST be removed. 728 3. If a Nonce option existed in the original message, its value MUST 729 be preserved in the proxied message. The Timestamp MUST be 730 generated by the proxy. 732 4. The PS option MUST be added as the last option in the message, 733 signing all the information contained so far in the message. To 734 be able to sign any NS, NA, RS, RA o Redirect message, the key 735 used must correspond to a certificate with KeyPurposeId values of 736 id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. 738 When any other IPv6 unicast packet is received on a proxy interface, 739 if it is not locally destined then it is forwarded unchanged (other 740 than using a new link-layer header) to the proxy interface for which 741 the next-hop address appears in the neighbor cache. If no neighbor 742 cache entry is present, the Secure ND Proxy SHOULD queue the packet 743 and initiate a Neighbor Discovery signaling as if the NS message were 744 locally generated. 746 In order to deploy this scenario, nodes in proxied segments MUST know 747 the certificate authorizing proxy operation. To do so it could be 748 required to configure at least one device per each proxied segment 749 (may be the proxy itself) to propagate the required certification 750 path to authorize proxy operation by means of a CPS/CPA exchange. 752 7. Backward Compatibility with RFC3971 nodes and non-SEND nodes 754 In this section we discuss the interaction of Secure ND Proxies and 755 SPND nodes with RFC3971 nodes and non-SEND nodes. As stated in 756 [RFC3971], network operators may want to run a mixture of nodes 757 accepting secured and unsecured NDP messages at the same time. 758 Secure ND Proxies and SPND nodes SHOULD support the use of secured 759 and unsecured NDP messages at the same time. 761 7.1. Backward Compatibility with RFC3971 nodes 763 RFC3971 nodes, i.e. SEND nodes not compliant with the modifications 764 required in Section 5, cannot interpret correctly a PS option 765 received in a proxied ND message. These SEND nodes silently discard 766 the PS option, as specified in [RFC4861] for any unknown option. As 767 a result, these messages will be treated as unsecured as described in 768 Section 8 "Transitions Issues" of the SEND specification [RFC3971]. 770 When RFC3971 nodes and SPND nodes exchange ND messages (without proxy 771 intervention), in either direction, messages are generated according 772 to the SEND specification [RFC3971], so these nodes interoperate 773 seamlessly. 775 In the scenarios in which the proxy translates ND messages, the 776 messages to translate can either be originated in a RFC3971 node or 777 in an SPND node, without interoperability issues (note that the 778 difference between RFC3971 nodes and SPND nodes only affect to the 779 ability to process received NDP messages containing a PS option, not 780 in the way they generate messages secured by SEND). 782 7.2. Backward Compatibility with non-SEND nodes 784 Non-SEND nodes receiving NDP packets silently discard PS options, as 785 specified in [RFC4861] for any unknown option. Therefore, these 786 nodes interpret messages proxied by a Secure ND Proxy as any other ND 787 message. 789 When non-SEND nodes and SPND nodes exchange ND messages (without 790 proxy intervention), in either direction, the rules specified in 791 section 8 of [RFC3971] apply. 793 A Secure ND Proxy SHOULD support the use of secured and unsecured NDP 794 messages at the same time, although it MAY have a configuration that 795 causes not to perform proxying for unsecured NDP messages. A Secure 796 ND Proxy MAY also have a configuration option whereby it disables 797 secure ND proxying completely. This configuration SHOULD be switched 798 off by default, that is security is provided by default. In the next 799 paragraphs we discuss the recommended behavior of the Secure ND Proxy 800 regarding to the protection level to provide to proxied messages in a 801 mixed scenario involving SPND/RFC3971 nodes and non-SEND nodes. In 802 particular, two different situations occur depending on if the 803 proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes. 805 As a rule of thumb, if the proxied nodes can return to the link in 806 which the proxy operates, the Secure ND Proxy MUST only generate PS 807 options on behalf of nodes with SEND capabilities (i.e. that they 808 could use SEND to defend their messages if present on the same link 809 as the proxy, i.e. being either RFC3971 nodes or SPND nodes). This 810 is relevant to allow nodes to prefer secured information over 811 unsecured one, and to properly execute the DAD procedure, as 812 specified in [RFC3971]. Therefore, in this case the Secure ND Proxy 813 MUST synthesize/translate messages containing the PS option for SPND 814 and RFC3971 hosts, and MUST NOT synthesize/translate messages 815 containing the PS option for non-SEND nodes. Note that ND 816 advertisements in response to solicitations generated by a Secure ND 817 Proxy must be secured or not according to the previous considerations 818 (i.e. to the nature of the proxied node), and not according to the 819 secure or unsecure nature of the solicitation message. 821 In order to apply this rule, the Secure ND Proxy needs to know the 822 security capabilities of the proxied node. The way this information 823 is acquired depends on the application scenario, and it is discussed 824 next: 826 o For scenarios in which ND messages are translated for nodes that 827 can arrive to the link in which the proxy operates, the rule can 828 be easily applied: only for messages validated in the Secure ND 829 Proxy according to the SEND specification [RFC3971], or according 830 to Section 5.2.2 of this specification for messages containing a 831 PS option (which means that another proxy previously checked that 832 the original message was secured), the message MUST be proxied 833 securely by the inclusion of a PS option. Unsecured ND messages 834 could be proxied if unsecured operation is enabled in the proxy, 835 but the message generated by the Secure ND Proxy for the received 836 message MUST NOT include a PS option. 838 o For scenarios in which ND messages are synthesized on behalf of 839 remote nodes, different considerations should be made according to 840 the particular application scenario. 842 * For MIPv6, if the MN can return to the home link, it is 843 required for the proxy to know if the node could use SEND to 844 defend its address or not. A HA including the PS option for 845 proxying a non-SEND MN would make ND messages sent by the proxy 846 to be more preferred than a ND message of the non-SEND MN when 847 the MN returns to the home link (even if the proxied messages 848 have the Override bit set to 1). Not using the PS option for a 849 RFC3971 or SPND MN would make the address in the home link more 850 vulnerable when the MN is away than when it is in the home 851 link, defeating the purpose of the Secure Proxy ND mechanism. 852 Therefore, in this case the HA MUST know the SEND capabilities 853 of the MN, MUST use the PS option if the MN is a SPND or 854 RFC3971 host, and MUST NOT use PS option for non-SEND hosts. 856 * For the Proxy Mobile IPv6 scenario, a node moving from a link 857 in which PS option has been used to protect a link-layer 858 address to a link in which ND messages are not protected by 859 SEND would prevent the MN from adquiring the new information 860 until the cached information expires. However, in this case it 861 is reasonable to consider that all MAGs provide the same 862 security for protecting ND messages, and that either all MAGs 863 will behave as Secure ND Proxy, or none, so configuration is 864 expected to be easier. 866 8. Security Considerations 868 The mechanism described in this document introduces a new Proxy 869 Signature (PS) option allowing a Secure ND Proxy to synthesize or 870 translate a SEND message for a proxied address, to Redirect traffic 871 for given target addresses or to advertise prefix information by 872 means of RA messages. A SPND node only accepts such a message if it 873 includes a valid PS option generated by a properly authorized Secure 874 ND Proxy (with a certificate containing a KeyPurposeId with value id- 875 kp-sendProxiedOwner for protecting NA, NS and RS messages, or 876 containing a KeyPurposeId value of id-kp-sendProxiedRouter for 877 protecting RA and Redirect messages). Such a message has equivalent 878 protection against the threats presented in section 9 of [RFC3971] as 879 a message signed with a RSA Signature option. 881 The security of proxied ND messages not including a PS option is the 882 same as an unsecured ND message. The security of a proxied ND 883 message received by a non-SEND host or RFC3971 host is the same as an 884 unsecured ND message. 886 When a message including a PS option is received by a SPND node, any 887 CGA or RSA options also included in the message are removed and the 888 remaining message further processed. Altough properly formed proxied 889 messages MUST NOT include at the same time PS and CGA/RSA options, 890 discarding them if they appear does not affect to the security. If 891 the PS option is validated, then the information included in the 892 message has been validly generated by a proxy, and should be honored 893 (remember that anti-replay protection is provided by means of nonce 894 and timestamp options). If the PS option is not validated, then it 895 is treated as an unsecured message. In any case, there is no gain 896 for an attacker from appending false or old CGA/RSA information to a 897 message secured by a Secure ND Proxy. 899 A compromised Secure ND Proxy provisioned with an authorization 900 certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is 901 able, like a compromised router to siphon off traffic from the host, 902 or mount a man-in-the-middle attack, for hosts communicating to off- 903 link hosts. A compromised Secure ND Proxy provisioned with an 904 authorization certificate with a KeyPurposeId value of id-kp- 905 sendProxiedOwner can siphon off traffic or mount a man-in-the-middle 906 attack for communication between on-link hosts, even if the hosts use 907 SEND. Note that different application scenarios may require one type 908 of authorization, the other, or both. To minimize security risks, 909 authorization capabilities SHOULD NOT exceed the ones strictly 910 required by the application scenario to be deployed. 912 The messages for which a Secure ND Proxy performs its function and 913 the link for which this function is performed MUST be configured 914 appropriately for each proxy and scenario. This configuration is 915 specially relevant if Secure Proxy ND is used for translating ND 916 messages from one link to another. 918 Section 7 discusses the security considerations resulting from the 919 decision of appending or omitting the PS option depending on the 920 SEND-awareness of the proxied nodes. 922 Protection against replay attacks from unsolicited messages such as 923 NA, RA, and Redirects is provided by means of the Timestamp option. 924 When Secure ND Proxy is used, each proxy and the host for which a 925 proxy acts on behalf are considered to be different peers in terms of 926 Timestamp verification. Since the information provided by the host 927 and a proxy maybe different, including different link-layer 928 addresses, a replay attack could affect the operation of a third 929 node: replaying messages issued by a host that is no longer in the 930 link can prevent the use of a proxy, and replaying messages of a 931 proxy when the host is back in the link can prevent communication 932 with the host. This kind of attacks can be performed until the 933 timestamp of the peer (either the host or a proxy) is no longer valid 934 for the receiver. The window of vulnerability is in general larger 935 for the first message received from a new peer than for subsequent 936 messages received from the same peer (see [RFC3971]). A more 937 detailed analysis of the possible attacks related with the Timestamp 938 option is described in section 7.3 of [I-D.ietf-csi-sndp-prob]. 940 9. IANA Considerations 942 IANA is requested to allocate: 944 A new IPv6 Neighbor Discovery Option type for the PS option, as 945 TBA. The value need to be allocated from the namespace specified 946 in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS 947 located at http://www.iana.org/assignments/icmpv6-parameters. 949 A new 128-bit value under the CGA Message Type [RFC3972] 950 namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. 952 10. Acknowledgements 954 The text has benefited from feedback provided by Jari Arkko, Jean- 955 Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey 956 Melnikov and Sandra Murphy. 958 The work of Alberto Garcia-Martinez was supported in part by T2C2 959 project (TIN2008-06739-C04-01, granted by the Spanish Science and 960 Innovation Ministry). 962 11. References 964 11.1. Normative References 966 [I-D.ietf-csi-send-cert] 967 Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 968 profile and certificate management for SEND", 969 draft-ietf-csi-send-cert-07 (work in progress), 970 September 2010. 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, March 1997. 975 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 976 in IPv6", RFC 3775, June 2004. 978 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 979 Neighbor Discovery (SEND)", RFC 3971, March 2005. 981 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 982 RFC 3972, March 2005. 984 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 985 Proxies (ND Proxy)", RFC 4389, April 2006. 987 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 988 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 989 September 2007. 991 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 992 Address Autoconfiguration", RFC 4862, September 2007. 994 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 995 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 997 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 998 PKCS 1 , November 2002. 1000 [SHA1] National Institute of Standards and Technology, "Secure 1001 Hash Standard", FIPS PUB 180-1 , April 1995. 1003 11.2. Informative References 1005 [I-D.ietf-csi-sndp-prob] 1006 Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor 1007 Discovery Proxy: Problem Statement", 1008 draft-ietf-csi-sndp-prob-04 (work in progress), 1009 January 2010. 1011 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1012 Discovery (ND) Trust Models and Threats", RFC 3756, 1013 May 2004. 1015 Authors' Addresses 1017 Suresh Krishnan 1018 Ericsson 1019 8400 Decarie Blvd. 1020 Town of Mount Royal, QC 1021 Canada 1023 Phone: +1 514 345 7900 x42871 1024 Email: suresh.krishnan@ericsson.com 1026 Julien Laganier 1027 QUALCOMM Incorporated 1028 5775 Morehouse Dr 1029 San Diego, CA 92121 1030 USA 1032 Phone: +1 858 658 3538 1033 Email: julienl@qualcomm.com 1035 Marco Bonola 1036 Rome Tor Vergata University 1037 Via del Politecnico, 1 1038 Rome I-00133 1039 Italy 1041 Phone: 1042 Email: marco.bonola@gmail.com 1044 Alberto Garcia-Martinez 1045 U. Carlos III de Madrid 1046 Av. Universidad 30 1047 Leganes, Madrid 28911 1048 Spain 1050 Phone: +34 91 6248782 1051 Email: alberto@it.uc3m.es 1052 URI: http://www.it.uc3m.es/