idnits 2.17.00 (12 Aug 2021) /tmp/idnits56954/draft-mun-aaa-dbu-mobileipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 37 == Unused Reference: '3' is defined on line 640, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 643, but no explicit reference was found in the text == Outdated reference: draft-ietf-aaa-diameter has been published as RFC 3588 == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-aaa-nai-03 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Miyoung Kim 3 Expires May 2003 Youngsong Mun 4 Soongsil University 5 Jaehoon Nah 6 Seungwon Sohn 7 ETRI 8 Nov 2002 10 Dynamic Binding Update using AAA 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC 2119]. 38 Abstract 40 This document describes the procedure of how dose the Mobile Node(MN) 41 exchange the messages with it's Corresponeant Node(CN) by using 42 the secure communication platform, the AAA infrastructure that consists 43 of the many AAA servers in different domains when the MN is about to 44 enter the visited link. 46 The MIPv6 node (MN, CN or both) has the unique identifier, NAI 47 (Network Access Identifier) to distinguish itself from others and by 48 parsing the NAI[5], we can get the information on which domain the MN 49 belongs. 51 In this document, we consider the main idea is applied into two 52 different cases. The first case is that the MN and CN are belonged 53 to the same domain which means that the MN and CN has the same domain 54 identifier in their NAI. In this case, the two nodes have the same 55 AAA server. Another case is denoted as the MN and CN belong to the 56 different domain in which the two nodes have the different AAA 57 servers. 59 We assume that the AAA servers are connected each other using the 60 secure communication protocols (e.g. DIAMETER) and they have the 61 common and global roaming contracts for mobility service. 62 By this assumptions, the AAA server in the MN's visited domain is 63 responsible for processing the request from the MN which comes from 64 the different domain and passing it to the MN's home AAA server 65 using its AAA infrastructure. 67 We use the 'Diameter' protocol as the AAA infrastructure which is 68 extendible for our purpose and guarantees the secure communications. 69 Comparing to another AAA protocol (e.g. RADIUS), the Diameter reduced 70 and optimized the message round-trips for their use. 71 (However, we don't set limits to use Diameter. If another protocol 72 is developed and proved as it is secure, the new one can be applied 73 to these cases.) 75 In this document, we define the new Diameter messages and AVPs to 76 provide the functionalities for making it possible that the MN is 77 roaming across the different domains. Also, we describe the 78 procedure to exchange the messages(and AVPs) between MN and CN. 80 Using this procedure, the mobile entities(MN and CN) are able to share 81 the keying-materials which are used to derive the secure key to protect 82 the 'Binding Registration(BU/BA)' and 'Route Optimization' messages. 84 1. Introduction 86 We introduce the new Diameter messages and the related AVPs to deliver 87 the parameters needed from considering the two cases as described 88 earlier. 90 In the case of a large amount of traffic occurs between the MN and 91 CN, the route optimization procedure can take place to optimize the 92 packet routing[2] and the secret key is used to make the BU/BA 93 messages secure. 95 To protect the binding information, the various methods are proposed. 96 These methods provide the strong-level of security however it is the 97 burden for the mobile node since each received packets encrypted with 98 the strong-level of security algorithms are also decrypted by the 99 mobile node with the same mechanism where the node is most likely the 100 battery-powered device. IPSec/IKE is tested for many mobile consider- 101 ations to bring it into MIPv6, however the test results are reported 102 as it is contrary to expectations for their performance and 103 extensibility for the large scale mobile networks.[6] 105 Another mechanism, the RR(Return Routablity) is proposed to protect 106 the binding information to simplify the distribution of the keying- 107 materials without depending on the underlying infrastructure where 108 the MN starts the procedure and the CN is responsible for making the 109 binding key and distributing the keying-materials to the MN. 110 However, even if the MN implements the strong-level of security 111 algorithms and it negotiates with the CN for the security key to 112 make the RO more secure, the attacker in the middle of them is able to 113 eavesdrop the negotiation packets and bring down the level of 114 security algorithm by forging the packets of deceiving the two 115 nodes (Bidding Down Attack). This can be a big problem since the 116 level of security provided by the RR isn't strong now. 118 In our proposal, we introduce the methods with Diameter message 119 exchange between the mobile entities(MN and CN) without using the RR. 121 2. Model and Entities 123 The model and entities for our proposal is denoted as: 125 +----------------------+ +--------------------------+ 126 | AAA Infra-Structure | | AAA Infra-Structure | 127 | +--------------+ | | +-------+ +-------+ | 128 | | H_AAA Server | | | | H_AAA | | H_AAA | | 129 | +--------------+ | | |Server1|<--->|Server2| | 130 +----------------------+ | +-------+ +-------+ | 131 ^ ^ +--------------------------+ 132 | | ^ ^ 133 +----------+ +-----------+ | | 134 | Attendant| | Attendant | +----------+ +----------+ 135 +----------+ +-----------+ |Attendant | | Attendant| 136 | | +----------+ +----------+ 137 v v | | 138 +---------+ +--------------+ v v 139 | Mobile | | Correspondant| +---------+ +-------------+ 140 | Node(MN)| | Node(CN) | | Mobile | |Correspondant| 141 +---------+ +--------------+ | Node(MN)| | Node(CN) | 142 +---------+ +-------------+ 144 Figure 1. AAA Authentication Model 146 The Diameter network provides the Diameter servers with secure 147 communication infrastructure[1]. Entering to the visited link, 148 the MN has to be authenticated by the authentication entity in the 149 link to gain the access for the link. The Attendant is the first 150 entity the MN tries to connect when it enters into the visited link. 151 At this point, the MN searches the attendant using the layer-2 152 protocol(e.g. ethernet broadcast) and the EAP protocol(also 153 layer 2) is used to send and receive the authentication request/ 154 response messages between the MN and Attendant since the IP adress 155 is not allocated to the MN and the access from the MN is not granted 156 by the local authentication entity. 158 The left-side of the figure shows that the MN and CN belong to the 159 same domain where they have the same AAA server. Another side of 160 figure shows that the MN and CN which belong to the different domains 161 are communicating. 163 The entities to provide the mobility and roaming service in the same 164 or different domains are Home AAA server, Local AAA server(in visited 165 link), Attendant, MN, CN, and HA. 167 - Home AAA server (H_AAA): AAA server in MIPv6 node's home domain. 169 - Local AAA server (V_AAA): AAA server in the domain the MN is 170 visiting. 172 - Home Agent: A node in the MNPv6 node's home link which is able to 173 maintain the binding information and process the 'Home 174 Registration' message from the MN to provide the MN with mobility 175 service. 177 - Attendant: An entity which is capable of controlling the access 178 from the MN to use the visited link. Attendant is the first entity 179 the MN connects to and it plays a role as the bridge between the MN 180 and the visited network. The link between the MN and Attendant(Air) 181 MUST be secure with the session key. 183 - Mobile Node(MN): a node implementing MIPv4/v6 [2] 185 - Correspondant Node(CN): A node implementing MIPv4/v6 [2] and 186 communicating with the MN. It is responsible for generating the 187 secure key and distributing the keying-materials to the MN when 188 performing the RO(Route Optimization) 190 3. Message Definition 192 The messages are listed as: 194 AReq(Attendant Request): The first authentication message from issued 195 by the MN. It is used for MN to request the establishment of the 196 session key(MN <-> Attendant), and Route Optimization(MN <-> CN). 197 This message is encoded as the form of Layer-2 protocol, EAPoL(EAP 198 over LAN) even though the MN has configured its CoA from the local 199 DHCP server since the AReq is sent from the MN before establishing 200 the session key and the CoA is not granted to access the link 201 at that point of time. 203 AMR(AA-MN-Request): A Diameter message converted and mapped by the 204 Attendant from the AReq(EAPoL) message sent from the MN to request 205 the authentication and keying-materials. Attendant relays this 206 message to it's local AAA server which delivers it to the MN's 207 home AAA server for further processing. 209 ACR(AAA-CN-Request): The message sent from the AAA server to the CN 210 which contains the parameters of keying materials for generating 211 the binding key. The AAA server converts the Diameter message into 212 the other message form known to the CN. (This maybe the normal IP 213 packets). 215 ACA(AA-CN-Answer): The response message for ACR sent from CN. 217 AMA(AA-MN-Answer): The Diameter message sent from the AAA server to 218 the Attendant. The AAA server gathers the ACR the response 219 message for ACA and constructs the Diameter message and AVPs 220 by putting the parameters from the ACA into the AVPs. 222 ARsp(Attendant Response): The response message for AReq which is 223 converted to EAPoL by the Attendant and sent to the MN. 225 4. Payloads (The contents of AVPs) 227 The parameters carried by the Diameter messages defined in Section 3 228 are as follow: 230 aaa_key: Keying materials generated by the MN(Algorithm, the secret 231 value and lifetime for encryption) 233 attendant_key: Keying materials generated by the MN which is used to 234 protect the messages between the MN and Attendant. 236 BU(Binding Update: The MIPv6 message to update or create the binding 237 information. Home Registration MUST be processed. 239 BA(Binding Acknowledgement): The response message for received BU. 241 CR(MN Credential): The AAA credentials sent from the H_AAA to 242 authenticate the MN. The MN may create the authentication 243 information using the Diffie-Hellman public value and the H_AAA is 244 able to authenticate the MN's validity by searching the DH public 245 value. 247 SecureParam_I: The security parameters sent from the MN which contains 248 the items(HASH_I, SA, Ni, KE, etc.) to establish the 249 SA(Security Association). 251 SecureParam_R: The security parameters sent from the CN which 252 contains the items(HASH_R, SA, Nr, KE, etc.) to establish the SA. 254 NAI(MN's NAI): The identifier for the MN. It is used for the V_AAA 255 server to find the home domain of the MN by referencing the domain 256 part of the NAI and send the request messages from the MN to the 257 AAA server in the MN's home domain. 259 Public_key: A public key of H_AAA. 261 RPI(Replay Protection Indicator): A random value(Timestamp, Nonce or 262 Cookies) to provide the replay protection between the MN and H_AAA. 264 HoA(Home Address): MN's Home Address. 266 HaA(Home Agent Address): Home Agent's Address of the MN. 268 RC(Result Code): The result code for the AAA response messages. 270 5. Diameter Message and AVPs 272 In our proposal, we define the new Diameter messages and it's AVPs 273 according to the Diameter message format described in [2]. 275 There are two messages, AMR and AMA. 276 (The abbreviation name of the messages are identical to its name and 277 message codes are not fixed here since it SHOULD be allocated by the 278 IANA and Diameter WG later) 280 - AMR: AA-Authentication-Request-MN (Code: Not specified, Abbr: AMR) 281 - AMA: AA-Authentication-Answer-MN (Code: Not specified, Abbr: AMA) 283 New AVPs are: 284 Group1. Address AVP(Assigned code=1) 285 : Defines the options related on the address processing. 286 - Home-Address-Option: MN's home address (code=0x01) 287 - CN-Address-Option: CN's address(code=0x03) 288 The CN's address communicating with the MN. This option can be 289 encoded multiply since the MN communicates with one or more CNs. 291 Group2. Security AVP(Assigned Code=2) 292 : Defines the options related on the security processing. 293 - Nonce-Option: Timestamp, Nonce or Cookies for replay protection. 294 (code=0x01) 295 - AAA-Key-Option: The keying-materials protected by the H_AAA's 296 public key. It is used to protect the AAA messages (code=0x02) 297 - Attendant-Key-Option: A key protected by the aaa_key(specified 298 in AAA-Key-Option). This is used to protect the messages between 299 MN and Attendant. (code=0x03) 300 - Security-Parameter-Option: The keying materials protected by the 301 aaa_key(specified in AAA-Key-Option). It contains the parameters 302 (HASH, Nonce, SA, KE, etc.) to establish the SA for CN.(code=0x04) 304 - Authenticator-Option: The hash value to verify the integrity of 305 the message payloads. This is a signature for the AVPs.(code=0x05) 307 Group3. Authentication-Path AVP(Assigned Code = 3) 308 : Defines the NAI of the MN. 309 - NAI-Option: The MN's identifier to find the home AAA server of 310 the MN(code=0x01) 312 Group4. Action AVP(Assigned Code = 4) 313 : Defines the option for the results of the AAA message processing. 314 (code=0x01). It defines the following abnormal codes. 315 NAI_ROAMING_INVALID(1): Error on the wrong NAI(Invalid NAI) occurs or 316 no roaming contract exists between the visited and home domains. 317 MSG_AUTHENTICATOR_ERR(2): The validation of message integiry has 318 failed.(Message has changed from the illegal node.) 319 ACA_TIME_OUT(3): The H_AAA didn't get the response message for 320 ACR during the specified waiting-time. (Response Timeout) 322 6. Protocol Overview 324 6.1 Binding Key Exchage between two nodes belong to the same domain 326 The following message exchanges occur for the nodes which belong to 327 the same domain. 328 MN Attendant V_AAA H_AAA CN[1..n] 329 | | | | | 330 | AReq | | | | 331 |-------->| | | | 332 | | AMR | | | 333 | |-------->| | | 334 | | | AMR | | 335 | | |--------->| | 336 | | | | | 337 | | | | ACR | 338 | | | |---------->| 339 | | | ACA | 340 | | | |<----------| 341 | | | AMA | | 342 | | |<---------| | 343 | | AMA | | | 344 | |<--------| | | 345 | ARsp | | | | 346 |<--------| | | | 347 |BU | | | | 348 |---------|---------|----------|---------->| 349 | | | | BA | 350 |<--------|---------|----------|-----------| 351 | | | | | 353 Figure 2.Binding Key Exchange between two nodes 354 belong to the same domain 356 When the MN is about to enter the visited link, it receives the 357 Attendant Advertisement message from the Attendant or scans the 358 attendant by sending the Attendant Search message and receiving the 359 Attendant Response message. At this point of time, although the MN 360 has configured it's CoA with stateful or stateless methods[2] from 361 the local DHCP server or MN's interface ID and it's prefix value 362 advertised from the local router, the IP packets outgoing and 363 incoming from/to the MN are deffered or discarded by the attendant 364 since the MN is not authenticated from the local AAA server and not 365 allow to access the visited link. Therefore, the Layer-3 protocol, 366 IP is unable to be used until the allocation of the session key by 367 authentication between the MN and attendant is completed. So, the 368 EAPoL(layer-2 protocol) is used between the MN and Attendant at this 369 time and the Local Challenge(LC) advertised from the Attendant 370 Advertisement message is used for providing the minimal security 371 between them. 373 The following keys are needed to provide the secure roaming: 375 - MN-Attendant Session Key: The session key to protected the packets 376 between the MN and attendant. After successful authentication of 377 MN they share the session key.[6][7] 379 - MN-CN Binding Key: The binding key to protect the route 380 optimization messages(BU and BA) exchanged between the MN and CN. 382 The following procedures represent the messages and its parameters 383 for each step. 385 Step1. AReq(Attendant Request: MN -> Attendant) 386 To authenticate itself to the visited domain and to get the keying 387 materials, the MN first sends the request message to the attendant 388 using the EAPoL. 389 Parameters: 390 - Local Challenge: The random value copying from the previous 391 'Attendant Advertisement' message. This is used to protect the 392 messages between the MN and Attendant. 393 - NAI: MN's identifier. 394 - RPI: A random value for replay protection(Timestamp, Nonce, or 395 Cookies) 396 - HoA: MN's home address. 397 - HaA: MN's home-agent address. 398 - CnA: CN's address. This can be specified in multiple. 399 - aaa_key: A keying material protected by the H_AAA's public 400 value. It is used to protect the AAA messages. 401 - attendant_key: A key protected by the aaa_key. 402 - SecureParam_I: The keying materials protected by th aaa_key 403 which contains the various items to establish the Security 404 Association. 405 - CR: An authenticator to verify the sender of the message and 406 check the integrity of that message. 408 Step2. AMR(AA-MN-Request: Attendant -> V_AAA) 409 Upon receiving the AReq message, the Attendant passes it to its AAA 410 server with converted message.(Diameter message form) 411 Parameters: 412 - Address AVP 413 Home-Address-Option(Code=0x01, HoA) 414 Home-Agent-Address-Option(Code=0x02, HaA) 415 CN-Address-Option(Code=0x03, CnA) 416 - Security AVP 417 Nonce-Option(Code=0x01, RPI) 418 AAA-Key-Option(Code=0x02, aaa_key) 419 Attendant-Key-Option(Code=0x03, attendant_key) 420 Security-Parameter-Option(Code=0x05, SecureParam_I) 421 Authenticator-Option(CR) 422 - Authentication-Path AVP 423 NAI-Option(Code=0x01, NAI) 425 Step3. AMR(AA-MN-Request: V_AAA -> H_AAA) 426 The V_AAA server looks up the MN's home AAA server by referencing 427 the NAI option and forwards this message to that server. 428 Parameters: 429 - Same paramaters are used since it does modified on this 430 message (just through passing) 432 Step4. ACR(AAA-CN-Request: H_AAA -> CN) 433 The purpose of this message is to deliver the keying materials sent 434 from the MN to its CNs. The H_AAA server determines the address of 435 the CN by referencing the CnA parameter. If more than one CNs 436 exist, which means the multiple CN's address CnA parameters are 437 included in the message parameter, then the H_AAA SHOULD send the 438 same message to the multiple targets after converting the previous 439 message(AHR) to another form known to the CNs. 440 Parameters: 441 - HoA: MN's home address 442 - SecureParam_I: The keying materials protected by the 443 aaa_key. It contains the various items (HASH_I, Ni, SA, KE, 444 etc.) to establish the Security Association. 446 Step5. ACA(AA-CN-Answer: CN -> H_AAA) 447 As the response for the ACR request message, the CN stores the 448 SecureParam_I received in Step4 into the secure local storage and 449 returns the SecureParam_R the keying materials used to generate 450 CN's Security Association. 451 Parameters: 452 - SecureParam_R: The parameters for establishing the Security 453 Association for the CN. 455 Step6. AMA(AA-MN-Answer: H_AAA -> V_AAA) 456 After receiving the ACA the response messages for 457 ACR, the H_AAA server constructs the Diameter message to send. If 458 the ACR message was sent to the multiple CNs then, it waits the 459 response messages(ACA) from them until the specified timer (lifetime) 460 expires. If it can't receive the response message from some CNs, 461 the H_AAA sets the 'ACA_TIME_OUT(4)' in the Result Code for the 462 CNs when returning this messages. 463 Parameters: 464 - Address AVP 465 Home-Address-Option(Code=0x01, HoA): Optional 466 Home-Agent-Address-Option(Code=0x02, HaA): Optional 467 - Security AVP 468 Security-Parameter-Option(Code=0x04, SecureParam_R of HA, 469 SecureParam_R of CNs) 470 - Action AVP 471 Result-Code-Option(Code=0x01, status value) 473 Step7. AMA(AA-MN-Answer: V_AAA -> Attendant) 474 After adding some parameters for local security to the AMA message, 475 the V_AAA sends this message to the Attendant. 476 Parameters: 477 - Security AVP 478 Attendant-Key-Option(Code=0x03, attendant_key) 479 Nonce-Option(Code=0x01, RPI) 481 Step8. ARsp(Attendant Response: Attendant -> MN) 482 Upon receiving the AMA from V_AAA server, the Attendant extracts 483 the secret values from the Nonce-Option and Attendant-key-Option 484 for local security and sends this message to the MN after 485 converting the Diameter to EAPoL. 486 Parameters: 487 - Local Challenge: As a random value to protect messages between 488 the MN and Attendant, this value is same one with the 489 challenge sent in the Attendant Response(AR) the response 490 message from MN to find the attendant(Attendant Request,AR) 491 when the MN is about to enter the visited link and try to 492 access the resource of it. 493 - RPI: A random value for replay protection(e.g. Timestamp, 494 Nonce, or Cookies) 495 - HoA: MN's home address. 496 - HaA: MN's home agent address. 497 - attendant_key: A key protected by the aaa_key. 498 - SecureParam_R: The keying materials protected by the aaa_key. 499 it contains the items to establish the Security Association for 500 CN. If the ACR message is destined to the multiple CNs, this 501 parameter contains the set of security parameters. 502 {SecureParam_R(CN) x N}, where N is the number of CNs which has 503 received the ACR from the H_AAA. 504 - Result: A code value indicating the result of the message 505 processing(The definition of the code value is identical to as 506 defined in 'Result-Code-Option'. 508 At this point of time, the MN has the security parameters received 509 from CNs(SecureParam_R(CN) x N) and it use the parameters as the 510 keying materials to derive the binding key until the lifetime 511 specified in the parameter expires. Similarly, the CNs also has 512 the security parameter(keying materials) sent from the MN to 513 derive the binding key to decrypt the binding registration 514 message encrypted with the same key by MN. 516 Step9. BU(Binding Update: MN -> CN) 517 After deriving the binding key from the security parameters, 518 the MN sends the binding registration message(BU) to perform 519 the Route Optimization procedure. This message is protected by 520 the key. The MN may send this message to multiple CNs if it has 521 the keying materials and is able to derive the key for the CNs. 522 Parameters: 523 - All parameters defined in MIPv6 are included.[2] 525 Step10. BA(Binding Acknowledgement: CN -> MN) 526 The CN performs the Route Optimization request message(BU) using 527 its key and sends the response message(BA) protected by the key 528 derived from the keying materials sent by the MN(SecureParam_I). 529 Upon receiving this message, the MN processes the message with its 530 key. 531 Parameters: 532 - All parameters defined in MIPv6 are included.[2] 534 6.2 Binding Key Exchange between two nodes belonging 535 to the different domain 537 The following message sequence occurs when the communication peers 538 (the MN and CN) are belonging to the same domain: 540 MN Attendant V_AAA(m) V_AAA(c) CN[1..n] 541 | | | | | 542 | AReq | | | | 543 |-------->| | | | 544 | | AMR | | | 545 | |-------->| | | 546 | | | AMR | | 547 | | |--------->| | 548 | | | | | 549 | | | | ACR | 550 | | | |---------->| 551 | | | | | 552 | | | | ACA | 553 | | | |<----------| 554 | | | AMA | | 555 | | |<---------| | 556 | | AMA | | | 557 | |<--------| | | 558 | | | | | 559 | ARsp | | | | 560 |<--------| | | | 561 | | | | | 562 |BU | | | | 563 |---------|---------|----------|---------->| 564 | | | | BA | 565 |<--------|---------|----------|-----------| 566 | | | | | 568 Figure 3. Binding Key Exchange between two nodes belonging 569 to the different domain 571 In this case, we SHOULD consider the factors below when performing 572 the Route Optimization procedure. 574 - V_AAA[1..m]: The local AAA server that the CN is now visiting. 575 - CN[1..n]: One or more CNs the MN wishes to go on communicating. 577 where, the MN sends the request message to more than one CNs to make 578 the Route Optimization and each CN is in the different domains(m=n) 579 or some CNs may be in the same domain(m