idnits 2.17.1 draft-qin-mipshop-pmipro-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1030. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (November 14, 2007) is 5980 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-01 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-07 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei Technologies USA 4 Expires: May 17, 2008 A. Qin 5 A. Huang 6 W. Wu 7 Huawei Technologies 8 November 14, 2007 10 PMIPv6 Route Optimization Protocol 11 draft-qin-mipshop-pmipro-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 17, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines route optimization protocol for Proxy Mobile 45 IPv6. Proxy home test, concurrent proxy care-of test and handover 46 procedures based on Enhanced Route Optimization for Mobile IPv6 are 47 explained. Mobile access gateway uses cryptographically generated 48 home addresses so that no more home test is needed after the initial 49 home test. Handover home keygen token is used during handover in 50 order to eliminate home test for the next mobile access gateway. The 51 protocol also supports IPv4 transport network operation. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. PMIPv6 RO Scenarios and Overview . . . . . . . . . . . . . . 5 58 3.1. PMIPv6 RO Scenario Analysis . . . . . . . . . . . . . . . 5 59 3.2. PMIPv6 RO Overview . . . . . . . . . . . . . . . . . . . . 6 60 4. PMIPv6 Route Optimization for Type 1 Correspondent Nodes . . . 8 61 4.1. Proxy Home Test Procedure . . . . . . . . . . . . . . . . 8 62 4.2. Concurrent Proxy Care-of Test . . . . . . . . . . . . . . 9 63 4.3. Handover . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.4. Complete Proxy Binding Update . . . . . . . . . . . . . . 11 65 5. PMIPv6 Route Optimization for Type 2 Correspondent Nodes . . . 13 66 5.1. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . 14 67 6. Local Mobility Anchor Considerations . . . . . . . . . . . . . 15 68 7. Mobile Access Gateway Considerations . . . . . . . . . . . . . 16 69 8. Correspondent Node Considerations . . . . . . . . . . . . . . 16 70 9. Requirements on PMIPv6 Handover/Context Protocol . . . . . . . 17 71 10. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 72 10.1. Proxy Home Test . . . . . . . . . . . . . . . . . . . . . 18 73 10.2. Proxy Home Test Init Message . . . . . . . . . . . . . . . 19 74 10.3. Handover Home Keygen Token option . . . . . . . . . . . . 19 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 80 14.2. Informative references . . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 Intellectual Property and Copyright Statements . . . . . . . . . . 23 84 1. Introduction 86 In Mobile IPv6, the mobile nodes (MN) can establish a direct route 87 with the correspondent nodes (CN), i.e. can optimize the route 88 through MN establishing a binding of its Home Address (HoA) with its 89 current care-of address (CoA) at CN [RFC3775]. The binding is 90 established using return routability signaling and then refreshed 91 periodically (every 7 minutes) and when MN's IP connectivity changes. 92 Return routability procedure also called Correspondent Registrations 93 involves CN's verification of MN's ownership of both HoA using a home 94 address test (HoT) and CoA using care-of address test (CoT) all 95 together designed to counter for the unprecedented security threats 96 identified in [RFC4225] like impersonation and flooding threats. 98 Return routability procedure is lightweight, does not require a 99 global Public-Key Infrastructure (PKI) or preshared keys between MN 100 and CN. However, it increases signaling overhead and handoff delays. 101 Return routability procedure can be optimized by using preshared keys 102 [RFC4449] or cryptographically generated addresses [RFC4866]. 104 In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is transparent to 105 mobile nodes (MN) by the mobile access gateway (MAG) simulating a 106 home link and acting as a proxy on Mobile IP operation, also is 107 transparent to correspondent nodes (CN) by forcing all datagrams for 108 a mobile node to be routed through its local mobility anchor (LMA). 109 Thus, datagrams to the mobile node are often routed along paths that 110 are significantly longer than optimal. However, packets could be 111 routed directly between correspondent nodes and the mobile access 112 gateway instead of through local mobility anchor, such path is 113 optimal. Moreover, immunity to impersonation, denial of service, and 114 redirection-based flooding is necessary for a route optimization 115 protocol in PMIPv6. This document presents a mechanism, based on 116 PMIPv6 [I-D.ietf-netlmm-proxymip6] and Enhanced Route Optimization 117 for Mobile IPv6 [RFC4866], to securely establish optimal route 118 between MAG and correspondent nodes or between two MAGs. 120 The following types of correspondent nodes are considered: 121 correspondent nodes which have both Mobile IPv6 stack defined in 122 RFC3775 and recognize PMIPv6 messages, correspondent nodes without 123 Mobile IPv6 function which are provided mobility support by Proxy 124 Mobile IPv6. This document discusses both the first (Type 1 CNs) and 125 the second (Type 2 CNs). 127 Type 1 CN's MUST support Enhanced Route Optimization for Mobile IPv6 128 [RFC4866] and extensions defined in this document. PMIPv6 RO is 129 transparent for Type 2 CNs. 131 Some terminology is defined in Section 2. In Section 3 scenarios are 132 defined and an overview of PMIP6 RO is given. Section 4 presents 133 PMIPv6 Route Optimization Protocol for Type 1 CNs and Section 5 134 presents for Type 2 CNs. Section 6 defines local mobility anchor, 135 Section 7 defines mobile access gateway and Section 8 defines 136 correspondent node behaviour. Section 9 is on requirements this 137 protocol imposes on PMIPv6 Handover and Context Transfer protocol. 138 In Section 10, formats and options of messages are defined. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 Most of the terminology used in this document refers to PMIPv6 147 [I-D.ietf-netlmm-proxymip6], Enhanced Route Optimization for Mobile 148 IPv6 [RFC4866] and [I-D.ietf-netlmm-pmip6-ipv4-support]. The changed 149 definitions are listed below: 151 Mobile Access Gateway (MAG) 152 As is defined in [I-D.ietf-netlmm-proxymip6]. In this document, 153 the route optimization function is also provided by MAG. 154 Proxy Binding Cache 155 A cache of mobility bindings of mobile nodes, maintained by a 156 mobile access gateway for use in sending or forwarding datagrams 157 to MAGs serving for these mobile nodes. 158 Binding Update List 159 In this document, Binding Update List data structure is extended 160 to keep correspondent registrations at the mobile access gateway. 161 Correspondent registration could be to another MAG for Type 2 CNs. 162 Cryptographically generated home addresses 163 A cryptographically generated home address enables correspondent 164 nodes to securely authenticate the owner of home address (HoA), by 165 means of a strong, cryptographic binding between the interface 166 identifier of the address and the address owner's public key. 167 From the perspective of the correspondent node, the home address 168 of the mobile node is owned by mobile access gateway during route 169 optimization procedure. In this document, proxy mobile IPv6 home 170 addresses are cryptographically generated home addresses using the 171 mobile node's public key. 172 Permanent home keygen token 173 Permanent home keygen token A secret permanent home keygen token, 174 which is generated by a correspondent node for a mobile node, is 175 exchanged between mobile access gateway and a correspondent node. 176 Permanent home keygen token kept by mobile access gateway is used 177 to authenticate the mobile access gateway more efficiently in 178 subsequent correspondent registrations. The permanent home keygen 179 token is renewed over complete PBU exchange and is not used to 180 authenticate the early PBU message while the mobile node moves to 181 the next mobile access gateway. Since the lifetime of proxy 182 binding update is due, permanent home keygen token should be re- 183 generated too. 184 Handover home keygen token 185 A secret handover home keygen token is a 64-bit random number 186 generated by a correspondent node for a mobile node when the first 187 proxy binding update containing Signature Option is received. 188 Handover home keygen token is used to authenticate the early proxy 189 binding update message and because of this, proxy home test after 190 each handover can be skipped. During handover, handover home 191 keygen token is transferred from the previous mobile access 192 gateway to the next mobile access gateway. 193 Type 1 Correspondent Node 194 A node that is Mobile IPv6 enabled to be a correspondent node as 195 per [RFC3775]. Type 1 CNs can receive route optimized traffic 196 from mobile access gateways serving their mobile nodes. 197 Type 2 Correpondent Node 198 A mobile node that is served by mobile access gateway. Route 199 optimization is transparent to Type 2 CNs. Mobile access gateway 200 provides both mobility and route optimization services to Type 2 201 CNs. 203 3. PMIPv6 RO Scenarios and Overview 205 3.1. PMIPv6 RO Scenario Analysis 207 There are many possible scenarios due to the different location and 208 capability of correspondent node (see Figure 1): 209 o Case #1 : MN and CN attach to the same MAG and they belong to 210 the same LMA. 211 o Case #2 : MN and CN attach to the same MAG but they belong to 212 different LMAs. 213 o Case #3 : MN and CN attach to different MAGs, but they have the 214 same LMA. 215 o Case #4 : MN and CN attach to different MAGs, and they have 216 different LMAs. 217 o Case #5 : A MN is in the PMIPv6 domain and initiates route 218 optimization procedures with a CN that is outside of the PMIPv6 219 domain, e.g. CN1 in Figure 1. In this case, the CN MUST support 220 route optimization procedures defined in this document. 221 In Cases #1 through #4, the CN is a Type 2 CN. The MAG of the CN is 222 involved with route optimization protocol. In Scenario #5, the CN is 223 a Type 1 CN. The MAG of the MN has to negotiate with the CN 224 directly. The route optimization mechanism should concern about the 225 CN's security requirement. 227 Cases 1 and 2 do not require any signaling between PMAs and packets 228 can be locally routed. As such, these cases are covered in the base 229 specification [I-D.ietf-netlmm-proxymip6]. 231 The protocol defined in Section 5 covers Cases #3 and #4. PMIPv6 RO 232 Protocol for Scenario Case #5 is defined in Section 4. For Cases #3 233 and #4, IPv4 transport network is supported. 235 / \ 236 |-----------------------|- | Internet | 237 | | \ / 238 +-----+ +-----+ \ 239 |LMA1 |~~~~~~~~~~~~~~~~~|LMA2 | | 240 /+-----+\\ +-----+\\ +-------+ 241 // \\ \\ + CN1 | 242 // \\ \\ +-------+ 243 // \\ \\ IPv6/IPv4 244 // \\ \\ Transport 245 // \\ \\ Network 246 +----+ +----+ +----+ 247 |MAG2|~~~~~~~~~~~~~~~~~~|MAG1|~~~~~~~~~~~~~~~|MAG3| 248 +--+-+ +-+--+ +-+--+ 249 | | | IPv6/IPv4 250 | | | Access Network 251 -----+---- ----+------- ---+--+-- 252 | 253 +-----+ +--+--+ 254 <-----| MN1 | | CN2 | 255 +-----+ +-----+ 257 Figure 1: Route Optimization Scenarios in PMIPv6 259 3.2. PMIPv6 RO Overview 261 This document describes a route optimization protocol for PMIPv6. 262 For Scenarios case #3 and case #4, specialized signaling can be 263 defined between mobility access gateways or between local mobility 264 anchors and mobility access gateways to setup and maintain route 265 optimization states for MN and CN. However such an approach does not 266 exploit the existing route optimization protocol defined for Mobile 267 IPv6 in [RFC3775]. For Scenarios case #3, #4 and #5, return 268 routability test procedures of Mobile IPv6 can be adopted to PMIPv6 269 route optimization. However such an approach does not leverage the 270 enhancements to the return routability test procedures defined for 271 Mobile IPv6 in [RFC4866]. Therefore, the protocol defined in this 272 document for PMIPv6 route optimization is based on Enhanced Route 273 Optimization for Mobile IPv6. 275 Once a mobile node enters its Proxy Mobile IPv6 domain, mobile access 276 gateway which runs on the access router does the mobility related 277 signaling on behalf of the mobile node. In MIPv6, a mobile node may 278 determine when and which correspondent node needs route optimization. 279 In contrast, in this document, such determination is done by the 280 mobile access gateway according to some policies. The configuration 281 of such policies is out of scope. 283 As soon as mobile access gateway makes decision on which 284 correspondent node needs route optimization, mobile access gateway 285 initiates proxy home test procedure depicted in Section 4.1. 286 Correspondent nodes verify the reachability of home address via this 287 procedure. 289 Correspondent nodes also need to verify the reachability of care-of 290 address. Proxy care-of test init message is piggybacked on a proxy 291 binding update message which is sent by mobile access gateway on 292 behalf of the mobile node to register with a correspondent node. 293 After the first round trip of proxy binding update exchange is over 294 between a correspondent node with mobile access gateway, the 295 correspondent node sets up a binding cache entry and MAY start 296 routing packets directly to care-of address of the mobile node even 297 though the care-of address is not verified. However, the mobile 298 access gateway obtains care-of keygen token via this round trip of 299 proxy binding update exchange [RFC4866]. 301 The mobile access gateway MAY initiate another proxy binding update 302 exchange. Thus, the correspondent node MAY authenticate this proxy 303 binding update with both temporary home keygen token and care-of 304 keygen token, and then it makes sure of the validity of proxy binding 305 cache entry created by early proxy binding update exchange. In order 306 to protect against redirection-based flooding attacks, Credit-Based 307 Authorization (CBA) can be exploited as described in [RFC4866]. 309 During handover, the next mobile access gateway simulates home link 310 for the mobile node. For the sake of security, proxy home test 311 should be executed over again for correspondent node to verify the 312 reachability and validity of home address of MN. In order to reduce 313 handover latency brought up with the proxy home test, handover home 314 keygen token is introduced in Section 4.3. Handover home keygen 315 token is used to eliminate the home test (PHoTI-PHoT exchange) at the 316 next mobile access gateway because the correspondent node can 317 authenticate early proxy binding update message sent by the new MAG 318 using the shared handover home keygen token. 320 In PMIPv6 route optimization protocol, the proxy home test and proxy 321 care-of test exchanges are initiated by MAG instead of MN. However, 322 both the source address of proxy home test init message and the 323 destination address of proxy home test message are home address of 324 mobile node. So, the destination mobile access gateway MUST 325 identify, intercept and process the proxy home test init message and 326 the source mobile access gateway MUST identify, intercept and process 327 the proxy home test message. 329 For the sake of security, cryptographically generated home addresses 330 and permanent home keygen token, defined in [RFC4866], are used in 331 PMIPv6 route optimization (PMIPv6RO) protocol. Cryptographically 332 generated home addresses, CGA parameters and signature are calculated 333 with the mobile node's public key and private key by each MAG the 334 mobile node visits. The input parameters to the CGA calculations 335 [RFC3972] like the subnet prefix, public key and private key are 336 available to each MAG. One possible mechanism is context transfer 337 from the previous MAG. 339 4. PMIPv6 Route Optimization for Type 1 Correspondent Nodes 341 4.1. Proxy Home Test Procedure 343 Proxy Home Test procedure validates the home address. It includes 344 two messages as follows: 346 Proxy Home Test Init (Proxy HoTI) 348 Proxy Home Test (Proxy HoT). 350 Since the destination address of Proxy HoT message is the home 351 address of MN, the destination MAG MUST intercept and process Proxy 352 Home Test message instead of forwarding it to MN. 354 When handoff occurs, correspondent nodes must re-verify the 355 reachability of home address by initiating the proxy home test. The 356 next mobile access gateway MAY also initiate the proxy home test. 357 Mobile access gateway MUST keep correspondent nodes list in its 358 Binding Update List. When MN roams into the next MAG, the entries in 359 the Binding Update List on MN identity like NAI, private and public 360 keys, etc. SHOULD be transferred to the next MAG. 362 As shown in Figure 2, the mobile access gateway imitates the Mobile 363 IP client of the mobile node. The Proxy Home Test Init (PHoTI) 364 message is sent from MAG to the correspondent node, and it should be 365 transmitted via the shared tunnel between the local mobility anchor 366 and MAG. 368 MAG LMA CN 369 According to some policies 370 Decide to optimize route | | 371 | | | 372 |==Proxy Home Test Init (PHoTI)=>|---------------------->| 373 | | | 374 | | | 375 |<====Proxy Home Test (PHoT)=====|<----------------------| 376 | | | 378 Figure 2: Proxy Home Test Procedure 380 4.2. Concurrent Proxy Care-of Test 382 Correspondent nodes also need to prove the reachability of care-of 383 address. In this document, since the care-of test is initiated by 384 mobile access gateway instead of by mobile node, we call it as proxy 385 care-of test procedure. 387 The early PBU is a PBU which does not carry the care-of keygen token. 388 A complete PBU follows up an early PBU after receiving a PBA message 389 with a Care-of Test option as shown in Figure 3. 391 a) As a Type 1 CN receives an early PBU message which contains HoA 392 option, Care-of Test Init option, the CGA Parameters and Signature 393 options, it returns PBA message containing a care-of keygen token in 394 Care-of Test option. 396 b) The MAG initiates complete proxy binding update exchange by 397 sending a PBU message. CN authenticates this proxy binding update 398 with both temporary home keygen token generated during proxy home 399 address test procedure and care-of keygen token. CN also validates 400 the proxy binding cache entry created by early proxy binding update 401 exchange and then sends a complete PBA as a reply. 403 The MAG calculates CGA parameters and signature option according to 404 MN's home address. MAG sends CGA parameters and signature in a 405 complete proxy binding update message to acquire permanent home 406 keygen token from the correspodent node in a PBA. MAG adds the 407 permanent home keygen token to the binding update list entry for the 408 correspondent node. The approach leverages the mechanism specified 409 in section 4 in [RFC4866]. 411 MAG CN 412 | | 413 | -------Early Proxy Binding Update------------>|a) 414 | (HoA, Care-of Test Init option) | 415 | | 416 | <------Early Proxy Binding Acknowledgement----| 417 | (HoA, Care-of Test option) | 418 | | 419 |-------- Complete PBU ------------------------>|b) 420 | (HoA, CGA parameters,signature...) | 421 | | 422 |<-------------Complete PBA---------------------| 423 | (HoA, Permanent home keygen token) | 424 | | 426 Figure 3: Concurrent Proxy Care-of Test 428 4.3. Handover 430 When handoff occurs, proxy care-of address changes. CN must re- 431 verify the reachability of home address. The next MAG MAY also 432 initiate the proxy home test. Handover home keygen token is used to 433 authenticate early PBU originated from the next MAG, after handover 434 home keygen token is transferred from the previous MAG to the next 435 MAG. Eliminating proxy home test procedure makes the protocol more 436 efficient by reducing the handover latency. 438 The handover procedure is depicted in Figure 4 and the steps are 439 explained below. 441 a) If the previous MAG forecasts the forthcoming handover of the MN 442 via layer 2 indication, the previous MAG MAY transfer context which 443 includes HoA, CN addresses and corresponding handover home keygen 444 tokens to the next MAG proactively. If the MN accessed to the next 445 MAG before the context is transferred, the case is a reactive case. 446 In reactive handover, as soon as the next MAG detects the attachment 447 of the MN, the MAG requests the private key and other pertinent 448 parameters from the previous MAG if the previous MAG is known. MAG 449 MAY also obtain the private key during the authentication procedure. 451 b) After the MN left the previous MAG, the previous MAG deregisters 452 the Binding Cache Entry with correspondent nodes. From this point 453 on, the CN does not renew the permanent home keygen token but 454 reserves the handover home keygen token for further use. 456 c) After the next MAG obtains handover home keygen token from the 457 previous MAG, it sends out early proxy binding update piggybacked by 458 care-of test init option to correspondent nodes. At this moment, the 459 MAG calculates the Binding Authorization Data option field of early 460 proxy binding update message with handover home keygen token and 461 care-of keygen token which is set to ZERO. 463 d) The next MAG renews the permanent home keygen token and handover 464 home keygen token via complete proxy binding update exchanges. 466 Previous Next Correspondent 467 mobile access gateway mobile access gateway node 469 | Handover context | | 470 |----------------------->| |a) 471 |(HoA,CN address,handover| | 472 |home keygen token) | | 473 handover \\ \\ | 474 | Proxy binding update(lifetime = 0) | 475 |------------------------------------------------------>|b) 476 | Proxy binding Acknowledge (if sent) | 477 |<------------------------------------------------------| 478 | | Early Proxy Binding Update | 479 | |----------------------------->|c) 480 | | Proxy Binding Acknowledge | 481 | |<-----------------------------| 482 | | Complete Proxy Binding Update| 483 | |----------------------------->|d) 484 | |Proxy Binding Acknowledge | 485 | |<-----------------------------| 486 | |(new Permanent, | 487 | |Handover home keygen token) | 488 | | | 490 Figure 4: Route Optimization during Handover Procedure 492 4.4. Complete Proxy Binding Update 494 A complete proxy binding update is a proxy binding update defined in 495 [I-D.ietf-netlmm-proxymip6]. After proxy binding update which 496 piggybacks care-of test exchanges is finished, a complete proxy 497 binding update must be done. The Binding Authorization Data option 498 field of the complete proxy binding update is calculated by care-of 499 keygen token for correspondent nodes to verify the reachability of 500 care-of address and authenticate the legitimacy of the MAG which is 501 sending this message on behalf of MN. The complete proxy binding 502 update is exchanged as depicted in Figure 5. 504 Complete PBU message must be sent with CGA parameters and signature 505 option for the mobile access gateway to request permanent home keygen 506 token and handover home keygen token from the correspondent node. A 507 CGA provides a strong binding between its interface identifier and 508 the CGA owner's public key. This enables other nodes to securely 509 authenticate the CGA owner. Depending on the strong security brought 510 up with cryptographically generated home addresses, lifetime of 511 binding is extended to a longer period than 7 minutes [RFC3775]. 512 Except for the initial test, the subsequent home tests every 7 513 minutes are no longer needed. 515 The correspondent node MUST authenticate the complete proxy binding 516 update message based on the CGA property of the mobile node's home 517 address. If the mobile access gateway has only temporary home keygen 518 token, and then the mobile access gateway uses it to calculate the 519 Binding Authorization Data option for the complete proxy Binding 520 Update message. 522 If the mobile access gateway has permanent home keygen token, the 523 mobile access gateway uses it to calculate the Binding Authorization 524 Data option. The home nonce index is set to ZERO. 526 If the permanent home keygen token is required, both permanent home 527 keygen token and handover home keygen token are generated and 528 encrypted with the mobile access gateway's public key. Both of the 529 two tokens are transferred from correspondent node to the next mobile 530 access gateway via the proxy binding acknowledgement response to the 531 complete proxy binding update message. This new handover home keygen 532 token will be exploited when the next handover occurs. 534 The PBA MAY be protected by CGA property of correspondent nodes. 536 Mobile Correspondent Node 537 Access Gateway 538 | Complete Proxy Binding Update | 539 |--------------------------------------------->| 540 | (CGA parameters, signature, home nonce index)| 541 | | 542 | | 543 | Proxy Binding Acknowledgement | 544 |<---------------------------------------------| 545 |(Permanent home keygen token, | 546 | Handover home keygen token) | 547 | | 548 | | 550 Figure 5: Complete Proxy Binding Update 552 5. PMIPv6 Route Optimization for Type 2 Correspondent Nodes 554 This section describes route optimization procedure for correspondent 555 nodes that are served by mobile access gateways. 557 If a mobile access gateway provides mobility service for 558 correspondent nodes, PMIPv6 Route Optimization protocol could be used 559 for such correspondent nodes, as long as the mobile access gateway 560 intercepts and processes route optimization extensions by looking 561 over the MH types and distinguishing Proxy Mobile IP signaling from 562 data. 564 The process for Scenario case #4 is shown in Figure 6. The proxy 565 home test init message is transmitted over the shared tunnel between 566 mobile access gateway and local mobility anchor of mobile node. This 567 proxy home test init message is forwarded to home address of the 568 correspondent node by LMA. At the local mobility anchor of the 569 correspondent node, this message is tunnelled into the shared tunnel 570 between the home agent of correspondent node and the mobile access 571 gateway of the correspondent node. 573 The mobile access gateway of CN intercepts proxy home test init 574 message and extracts MN's home address and care-of address from 575 PHoTI. MAG of CN sends a proxy home test message back to MAG of MN 576 and adds care-of address of CN into PHoT message. MAG of CN creates 577 a Binding Cache entry for this MN. PHoT is transmitted over the 578 shared tunnel between MAG of CN and LMA of CN. LMA of CN forwards 579 this message to the home address of MN which tunnels it to MAG of MN. 581 MAG of MN receives PHoT message, it extracts the care-of address of 582 CN and adds this information to the Binding Cache entry for CN. MAG 583 of MN next starts care-of test signaling by sending an early binding 584 update message directly to the care-of address of CN, i.e. to MAG of 585 CN. 587 Due to the address exchange using PHoTI and PHoT messages, care-of 588 test signaling in Figure 6 MUST NOT be started in parallel to home 589 test signaling. 591 Since the mobile access gateway is sending PBA on behalf of the 592 correspondent node, that mobile access gateway SHOULD use the 593 correspondent node's CGA property to protect PBA. 595 MAG(MN) LMA(MN) LMA(CN) MAG(CN) 596 | Proxy HoTI | | | 597 |===============>|-------------->|===============>| 598 | Proxy HoT | | | 599 |<===============|<--------------|<===============| 600 | Early Proxy Binding Update | | 601 |------------------------------------------------>| 602 | Proxy Binding Acknowledgement| | 603 |<------------------------------------------------| 604 | Complete Proxy Binding Update| | 605 |------------------------------------------------>| 606 | Proxy Binding Acknowledgement| | 607 |<------------------------------------------------| 608 | | | 610 Figure 6: Route Optimization for Type 2 Correspondent Nodes 612 Scenario case #3 route optimization is a simpler case of Figure 6. 613 LMA of MN has to re-encapsulate each packet and send it in MAG-LMA 614 tunnel of CN's MAG and back in MAG-LMA tunnel of MN's MAG. 616 5.1. IPv4 support 618 The typical IPv4 transport network scenario is as follows: both the 619 MN and the CN, located in PMIP domains, are IPv6-enabled nodes, 620 allocated IPv6 addresses and being served by dual-stack MAGs. The 621 transport network between the LMA and the MAG is an IPv4 network. 623 Initially, both MN and CN configure IPv4 home addresses by exchanging 624 PBU/PBA as explained in [I-D.ietf-netlmm-pmip6-ipv4-support]. In 625 Scenario case #3, MAG of MN starts RO signaling by sending PHoTI 626 message to CN in IPv4 tunnel established between MAG and LMA of MN. 627 MAG of MN MUST add IPv4 care-of address of MN into the care-of 628 address field of PHoTI. LMA removes IPv4 header and looks at the 629 destination address of inner header. LMA finds MAG address of this 630 CN and sends PHoTI in IPv4 tunnel between MAG and LMA of CN. PHoTI 631 message sent from MAG to LMA is shown at Figure 7: 633 PHoTI message: 634 IPv4 header (src=MAG of MN's IPv4 P.CoA, dst=IPv4 LMAA) 635 IPv6 header (src=MN's IPv6 HoA, dst=IPv6 HoA of CN) 636 Mobility header 637 - Proxy HoTI 638 IPv4 care-of address of MN 639 Mobility Options 641 Figure 7: PHoTI message 643 MAG of CN sends a PHoT message as a reply. PHoT message is sent in 644 IPv4 tunnel to LMA encapsulated in an IPv4 header. MAG of CN must 645 add IPv4 care-of address of CN into the care-of address field of 646 PHoT. PHoT message gets routed to MN. MAG of MN MUST obtain IPv4 647 address of CN from PHoT message's care-of address field. This 648 establishes direct route between MN and CN. 650 PHoT message: 651 IPv4 header (src= MAG of CN's IPv4 652 P.CoA, dst= IPv4 LMAA) 653 IPv6 header (src=MAG of CN's IPv6 P.CoA, dst=IPv6 HoA of MN) 654 Mobility header 655 - PHoT 656 IPv4 care-of address of CN 657 Mobility Options 659 Figure 8: PHoT message 661 In Scenario case #4, after receiving PHoTI message, LMA of MN needs 662 to map IPv6 home address of CN to either IPv4 address of CN's LMA or 663 IPv4 home address of CN. One possible solution is that MAG of MN 664 includes IPv4 home address of CN in PHoTI message. LMA of MN then 665 sends pHoTI message in an IPv4 tunnel to CN which is received by LMA 666 of CN. LMA of CN processes PHoTI exactly like LMA of CN did in 667 Scenario case #3 and sends the message to MAG of CN. 669 MAG of CN sends a PHoT message as a reply. PHoT message is sent in 670 IPv4 tunnel to LMA of CN encapsulated in an IPv4 header. MAG of CN 671 must add IPv4 care-of address of CN into the care-of address field of 672 PHoT. MAG of CN must also add IPv4 address of MN into the care-of 673 address field of PHoT. PHoT message gets routed to MN. MAG of MN 674 MUST obtain IPv4 address of CN from PHoT message's care-of address 675 field. This establishes direct route between MN and CN. 677 For supporting IPv4 private address space, NAT detection Option is 678 required from the DSMIP6 specification 679 [I-D.ietf-mip6-nemo-v4traversal]. For the NAT handling, UDP header 680 MUST be always used for the proxy binding update. These operations 681 are defined in [I-D.ietf-netlmm-pmip6-ipv4-support]. 683 6. Local Mobility Anchor Considerations 685 The local mobility anchor MUST drop all HoTI messages received from a 686 home address that has corresponding Binding Cache entry with the 687 proxy registration flag set. The local mobility anchor MUST forward 688 all Proxy HoTI messages received from a home address that has 689 corresponding Binding Cache entry with the proxy registration flag 690 set. 692 7. Mobile Access Gateway Considerations 694 MAG, after successful Home and Care-of Test exchanges, creates a 695 Binding Cache entry for the correspondent node or MAG of the 696 correspondent node. For each mobile node, the Binding Cache contains 697 one entry for each correspondent node. After handover, context 698 transfer procedure and PBU with lifetime set to zero exchanges are 699 finished, the previous MAG deletes deletes the Binding Cache entry 700 and deregisters MN with all its correspondent nodes. 702 MAG MUST maintain a Binding Update List for each MN. The fields are 703 as defined in [RFC3775] and with extensions defined in 704 [I-D.ietf-netlmm-proxymip6]. For each MN for which route 705 optimization service is offered, the list in addition MUST contain 706 the private and public keys of MN as well as the permanent home 707 keygen token and handover home keygen token. Apart from home 708 registrations as in [I-D.ietf-netlmm-proxymip6], Binding Update List 709 contains correspondent registrations for route optimization. 711 After handover, correspondent registration entries in the Binding 712 Update List SHOULD be transferred to the next MAG except for the 713 permanent home keygen token. Such a transfer provides continuity of 714 correspondent registrations for route optimization. The next MAG 715 refreshes such registrations only after lifetime expiry. 717 MAG MUST maintain a Binding Cache if it has Type 2 CNs. Binding 718 cache entries are created when MAG receives a home test init message. 719 This Binding Cache is called Proxy Binding Cache. 721 From the correspondent nodes MAG receives data packets with Type 2 722 routing header. Type 2 routing header MUST conform to the structure 723 given in Section 6.1.5 of [RFC3775]. MAG MUST process the packet as 724 follows: MAG replaces the source address with the home address given 725 in Type 2 routing header. MAG removes Type 2 routing header. MAG 726 sends the packet to MN. 728 8. Correspondent Node Considerations 730 This section states the differences in the behaviour of a 731 correspondent node that conforms to Section 9 of [RFC3775] and 732 [RFC4866]. 734 Upon receiving a Proxy Home Test Init message, Early Proxy Binding 735 Update and Complete Proxy Binding Update message, the correspondent 736 node verifies the following: The packet MUST NOT include a Home 737 Address destination option. The correspondent node MUST silently 738 ignore such packets. 740 Correspondent nodes MUST have a handover home keygen token in the 741 binding cache entry for each mobile node they are involved in route 742 optimized communication. 744 After a successful Home and Care-of Test exchanges, the correspondent 745 node creates a Binding Cache entry for the mobile access gateway 746 proxying the mobile node. The entry MUST be deleted after the 747 expiration of its lifetime or after receiving a proxy binding update 748 message which deregisters the mobile node. 750 Correspondent node MUST receive route optimized data packets from MAG 751 encapsulated in IP-in-IP encapsulation. Source address of the outer 752 header MUST be equal MAG's egress interface address and MUST match 753 the Binding Cache entry. CN MUST remove the outer header before 754 passing the packet to the upper layers. 756 CN MUST use Type 2 routing header in outgoing packets to MAG. The 757 destination address is MAG's egress interface address which serves as 758 Care-of address for the mobile node and the type 2 routing header 759 contains MN's home address. 761 9. Requirements on PMIPv6 Handover/Context Protocol 763 PMIPv6 RO Protocol has the following requirements on PMIPv6 Handover/ 764 Context Transfer protocol: Context transfer from the previous MAG to 765 the next MAG SHOULD include: 767 HoA of MN, Home Network Prefix (HNP) of MN, 769 Address of each CN and handover home keygen token from the Binding 770 Update list entry for this MN, 772 Permanent home keygen token, 774 Private and public key of MN. 776 10. Message Formats 778 This section defines extensions to the Proxy Mobile IPv6 779 [I-D.ietf-netlmm-proxymip6] protocol messages and the enhanced route 780 optimization in MIPv6 protocol messages [RFC4866]. 782 10.1. Proxy Home Test 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Home Nonce Index | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | | 787 + Home Init Cookie + 788 | | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 + Home Keygen Token + 792 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 + + 796 | | 797 + Care-of Address + 798 | | 799 + + 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | | 803 . . 804 . Mobility options . 805 . . 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 A new MH type should be assigned by IANA. 811 Home Keygen Token 812 This field contains the 64 bit temporary home keygen token used to 813 authenticate the proxy binding update. 815 Care-of Address 816 This field contains the care-of address assigned to the CN by MAG. 817 For descriptions of other fields present in this message, refer to 818 section 6.1.5 in [RFC3775]. 820 10.2. Proxy Home Test Init Message 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Reserved | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | | 825 + Home Init Cookie + 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 + + 830 | | 831 + Care-of Address + 832 | | 833 + + 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 . . 838 . Mobility Options . 839 . . 840 | | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 A new MH type should be assigned by IANA. 845 Care-of Address 846 This field contains the care-of address assigned to the mobile 847 node by MAG. 848 For descriptions of other fields present in this message, refer to 849 section 6.1.5 in [RFC3775]. 851 10.3. Handover Home Keygen Token option 853 Handover home keygen token is a mobility option. It is sent by CN in 854 proxy binding acknowledgement message. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Option Type | Option Length | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | 862 : : 863 : Handover Home Keygen Token : 864 : : 865 | | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 Option Type 869 8-bit identifier of the type of this mobility option. Its value 870 is TBD by IANA. 872 Option Length 873 8-bit unsigned integer representing the length of the Handover 874 Home Keygen Token field in octets. 875 Handover Home Keygen Token 876 This field contains the Handover home keygen token generated by 877 the correspondent node. The content of this field MUST be 878 encrypted with the mobile access gateway's public key. The length 879 of the handover home keygen token is 8 octets before encryption. 880 After it is encrypted, this field may be longer than 8 octets. 882 11. IANA Considerations 884 TBD. 886 12. Security Considerations 888 Security mechanism is very important in the route optimization 889 process, especially for the proposal of establishing the tunnel 890 between two mobile access gateways. In the case of route 891 optimization without return routability, if mobile access gateway 892 does not authenticate Proxy Binding Update and Proxy Binding 893 Acknowledge messages, a malicious node may send such signaling 894 messages to mobile access gateways to get the data packets destined 895 for other nodes directed to itself. 897 In addition, when mobile access gateway sends data packets through 898 the bi-directional tunnel between two mobile access gateways, 899 corresponding MAG SHOULD examine the data packets to make sure there 900 is a Binding Cache entry for the data source terminal. 902 Route optimization signaling between MAG of MN and CN specified in 903 this document is based on [RFC4866] and use return routability with 904 better security properties than the return routability of the base 905 protocol [RFC3775]. 907 Return routability signaling between two MAGs specified in this 908 document is also based on [RFC4866] and has better security 909 properties. 911 13. Acknowledgements 913 We would like to thank Dr. Vogt for his comments that have lead to 914 many improvements in this document. 916 14. References 918 14.1. Normative References 920 [I-D.ietf-netlmm-pmip6-ipv4-support] 921 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 922 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01 923 (work in progress), July 2007. 925 [I-D.ietf-netlmm-proxymip6] 926 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 927 and B. Patil, "Proxy Mobile IPv6", 928 draft-ietf-netlmm-proxymip6-07 (work in progress), 929 November 2007. 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, March 1997. 934 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 935 in IPv6", RFC 3775, June 2004. 937 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 938 RFC 3972, March 2005. 940 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 941 Optimization for Mobile IPv6", RFC 4866, May 2007. 943 14.2. Informative references 945 [I-D.ietf-mip6-nemo-v4traversal] 946 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 947 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05 948 (work in progress), July 2007. 950 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 951 Nordmark, "Mobile IP Version 6 Route Optimization Security 952 Design Background", RFC 4225, December 2005. 954 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 955 Using a Static Shared Key", RFC 4449, June 2006. 957 Authors' Addresses 959 Behcet Sarikaya 960 Huawei Technologies USA 961 1700 Alma Dr. Suite 500 962 Plano, TX 75075 964 Email: sarikaya@ieee.org 966 Alice Qin 967 Huawei Technologies 968 No.91 BaiXia Rd. 969 Nanjing, Jiangsu 210001 970 China 972 Email: Alice.Q@huawei.com 974 Andy Huang 975 Huawei Technologies 976 No.91 BaiXia Rd. 977 Nanjing, Jiangsu 210001 978 China 980 Phone: +86-25-84565457 981 Email: hpanda@huawei.com 983 Wenson Wu 984 Huawei Technologies 985 No.91 BaiXia Rd. 986 Nanjing, Jiangsu 210001 987 China 989 Phone: +86-25-84565459 990 Email: sunseawq@huawei.com 992 Full Copyright Statement 994 Copyright (C) The IETF Trust (2007). 996 This document is subject to the rights, licenses and restrictions 997 contained in BCP 78, and except as set forth therein, the authors 998 retain all their rights. 1000 This document and the information contained herein are provided on an 1001 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1002 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1003 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1004 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1005 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1006 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1008 Intellectual Property 1010 The IETF takes no position regarding the validity or scope of any 1011 Intellectual Property Rights or other rights that might be claimed to 1012 pertain to the implementation or use of the technology described in 1013 this document or the extent to which any license under such rights 1014 might or might not be available; nor does it represent that it has 1015 made any independent effort to identify any such rights. Information 1016 on the procedures with respect to rights in RFC documents can be 1017 found in BCP 78 and BCP 79. 1019 Copies of IPR disclosures made to the IETF Secretariat and any 1020 assurances of licenses to be made available, or the result of an 1021 attempt made to obtain a general license or permission for the use of 1022 such proprietary rights by implementers or users of this 1023 specification can be obtained from the IETF on-line IPR repository at 1024 http://www.ietf.org/ipr. 1026 The IETF invites any interested party to bring to its attention any 1027 copyrights, patents or patent applications, or other proprietary 1028 rights that may cover technology that may be required to implement 1029 this standard. Please address the information to the IETF at 1030 ietf-ipr@ietf.org. 1032 Acknowledgment 1034 Funding for the RFC Editor function is provided by the IETF 1035 Administrative Support Activity (IASA).