idnits 2.17.1 draft-le-aaa-diameter-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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 108 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** 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 an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '...ssumed that an IPv6 mobile node SHOULD...' RFC 2119 keyword, line 166: '... node SHOULD be able to use its NAI ...' RFC 2119 keyword, line 181: '...has a MN-NAI, it SHOULD use the MN_NAI...' RFC 2119 keyword, line 186: '... the MN MAY use the IPv6 permanen...' RFC 2119 keyword, line 211: '...Pv6 mobile nodes SHOULD have the capab...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '... It is inapp...' == Line 648 has weird spacing: '...chanism that ...' == Line 1067 has weird spacing: '...chanism that ...' -- 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1256 looks like a reference -- Missing reference section? '2' on line 1260 looks like a reference -- Missing reference section? '3' on line 1264 looks like a reference -- Missing reference section? '4' on line 1268 looks like a reference -- Missing reference section? '5' on line 1272 looks like a reference -- Missing reference section? '6' on line 1276 looks like a reference -- Missing reference section? '7' on line 1280 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA WG Stefano M. Faccin 3 INTERNET-DRAFT Franck Le 4 Date: July 2001 Basavaraj Patil 5 Expires: January 2002 Charles E. Perkins 6 Nokia Research Center 8 Diameter Mobile IPv6 Application 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies a new Application to Diameter for Mobile 35 IPv6, allowing an IPv6 mobile node to receive service from foreign 36 service providers thanks to the support of inter domain roaming by 37 the AAA infrastructure. The draft describes a solution that allows 38 the Diameter infrastructure to authenticate and authorize an IPv6 39 mobile node, distribute security keys to enable the provisioning of 40 services to the IPv6 mobile node, and perform and optimize mobility 41 procedures for the IPv6 mobile node. 43 1. Introduction 45 Mobile IP defines a method that allows a Mobile Node to change its 46 point of attachment to the Internet with minimal service disruption. 47 Mobile IP in itself does not provide any specific support for 48 mobility across different administrative domains, which limits the 49 applicability of Mobile IP in a large scale commercial deployment. 51 AAA protocols such as Diameter precisely enable mobile users to roam 52 and obtain service in networks that may not necessarily be owned by 53 their home service provider. The AAA functions provided by Diameter, 54 thus combined with Mobile IP, allow a inter domain development of 55 Mobile IP. This allow Diameter to be used in large scale commercial 56 networks such as future cellular networks. 58 Diameter extensions for Mobile IPv4 [1] have already been specified 59 allowing a MIPv4 node to receive services from service providers 60 (home and foreign) and allowing the Diameter servers to authenticate, 61 authorize and collect accounting information for those MIPv4 nodes. 63 Even though MIPv4 and MIPv6 are similar when observed at high level, 64 the two protocols are actually quite different when considering the 65 support for Inter Domain deployment. This document therefore defines 66 the IPv6 specific solution to support roaming of an IPv6 mobile node 67 between different administrative domains. 69 In order to give access to a mobile node to network resources, the 70 mobile node needs to be authenticated and authorized. Besides 71 supporting mobile node authentication and authorization, the AAA 72 infrastructure can also be used for distributing the security keys 73 needed to support the mobile node roaming. Optionally, the AAA 74 infrastructure can be used to support mobility procedures and to 75 optimize authentication, authorization and mobility in a common 76 procedure. 78 This document defines the Diameter Mobile IPv6 application. It 79 identifies the information that needs to be exchanged between the MN 80 and the AAA Client but it does not specify any particular mechanism 81 to convey information between the mobile node and the AAA Client: the 82 set of information identified in the follow can be conveyed between 83 the mobile node and the AAA client in a different suitable manner 84 outside the scope of this document (e.g. ICMP, BURP, etc.). The 85 extensions defined for Diameter allow for any of these alternatives, 86 thus enabling such extensions to be deployed independently of the 87 choice of the protocol used between the MN and the network. 89 The basic AAA model for inter domain roaming and the assumptions 90 behind the model are described first. The basic features supported by 91 the Diameter Mobile IPv6 application are described next, with the 92 definition of the Diameter messages and AVPs and with the behavior of 93 the various elements. Finally, enhanced features are described and 94 the AVPs and the behavior of the various elements is described. 96 This first version focuses on the different functionalities involved 97 in the support by the AAA infrastructure of inter domain roaming of 98 Mobile IPv6 nodes..LP 100 2. The model and assumptions 102 2.1. The model 104 The following entities are involved in the model: 106 Visited Domain Home Domain 107 +--------+ +--------+ 108 |abc.com | (3) |xyz.com | 109 | AAAv |<------------------->| AAAH | 110 +->| server | server-server | server | 111 | +--------+ communication +--------+ 112 | ^ ^ 113 (2) | | (2) client-server | (4) 114 | | communication | 115 v v v 116 +---------+ +---------+ +---------+ 117 | AAA | | AAA | | Home | 118 | Client | | Client | | Agent | 119 +---------+ +---------+ +---------+ 120 ^ 121 | (1) 122 | 123 v 124 +--------+ 125 | Mobile | 126 | Node | mn@xyz.com 127 +--------+ 129 * The Mobile Node 131 * The AAA Client: it is the function that allows the MN to register 132 and be authenticated by the network service provider, by providing 133 identity and authentication information to the local network which 134 then uses a AAA infrastructure to validate the user, charge him 135 and, authorize use of resources. In addition to authorization and 136 authentication, the MN may provide the AAA Client with mobility 137 management information (e.g. embedded BUs) to perform MIP 138 procedures. The AAA Client can be an attendant, e.g. located in an 139 Access Router, or can be a registration agent as the one 140 identified in BURP BOF. 142 * AAAv: is the AAA server in the local network 144 * AAAh: is the AAA server in the home network of the MN 146 * HA: is a Home Agent 148 2.2. Assumptions 150 * Mobile nodes are identified by their Network Access Identifier 151 (NAI) in an unique manner: 153 RFC2794 specifies an identifier for mobile nodes, the MN-NAI. The MN- 154 NAI is used by the AAA infrastructure to authenticate mobile IPv4 155 nodes. 157 The Mobile IPv6 specification mandates the existence of a security 158 association between the MN and its Home Agent. In certain scenarios 159 and future deployments a MN may not have any Home Agent or a home 160 address assigned to it. A MN may instead have a security association 161 with the home AAA network element and may use this to obtain a home 162 address, and an HA. 164 In this document it is assumed that an IPv6 mobile node SHOULD 165 identified by a MN-NAI in a unique manner, and that an IPv6 mobile 166 node SHOULD be able to use its NAI instead of its home address to get 167 authenticated/authorized by the AAA infrastructure when roaming to 168 foreign domains. In fact, in general the network needs to 169 authenticate the user that is roaming, not the specific device, and 170 in the future there may be cases where a specific user is accessing 171 the network through several devices, or several users are accessing 172 the network through the same device. 174 In general, anyway, it is better to allow identification of an IPv6 175 mobile node also through the use of its IPv6 permanent address: this 176 allows users that have not been provided with a NAI by their home 177 domain to get authenticated and authorized by the AAA infrastructure. 179 The assumption made in this document is that: 181 * when the MN has a MN-NAI, it SHOULD use the MN_NAI to get 182 authenticated/authorized by the AAA infrastructure, independently 183 of whether the MN has or not a permanent address 185 * when the MN does not have a MN-NAI but only a permanent address, 186 the MN MAY use the IPv6 permanent address to get 187 authenticated/authorized by the AAA infrastructure 189 * Mobile Node and AAAh share a long-term key: 191 This long-term key provides network authentication and user 192 authentication; it can also be used in order to derive session keys 193 or local security associations as explained in the following 194 sections. 196 * AAAv and AAAh share a security association 198 This inter AAA security association allows the home and visited 199 domain to trust each other, and to exchange information in an 200 authenticated and protected manner. 202 3. Basic supported features 204 3.1. Authentication/authorization 206 Before giving access to the network, the visited network wants to 207 authenticate the user. The IPv6 mobile node may also want to 208 authenticate the network to prevent network impersonation such as 209 false BTS attacks. 211 The IPv6 mobile nodes SHOULD have the capability to use many 212 different authentication methods: The IPv6 mobile nodes could e.g. 213 use EAP at layer 3 for authentication: This document does not define 214 how the authentication information are exchanged between the Mobile 215 nodes and the network (it could be performed using BURP, ICMPv6 216 messages) but the AAA infrastructure allows that authentication and 217 authorization; and the defined Diameter messages support many round 218 trips if the authentication method adopted requires it. 220 3.2. Dynamic Home Agent assignment in Home domain 222 It is possible that when the mobile node needs to send a Binding 223 Update to its home agent to register its new primary care-of address, 224 the mobile node may not know the address of any router on its home 225 link that can serve as a home agent for it. For example, some nodes 226 on its home link may have been reconfigured while the mobile node has 227 been away from home, such that the router that was operating as the 228 mobile node's home agent has been replaced by a different router 229 serving this role. 231 The dynamic Home agent assignment feature also provides more 232 flexibility to the service provider: in general, a mobile node home 233 network may not assign statically a home agent to the mobile node to 234 maintain flexibility in the allocation of the home agent to achieve 235 better load sharing and fault tolerance. 237 In this case, the mobile node MAY use the dynamic home agent address 238 discovery mechanism to find the address of a suitable home agent on 239 its home link. 241 The current Mobile IPv6 specification describes a dynamic Home Agent 242 discovery procedure; as an alternative, this document describes 243 another home agent assignment procedure relying on the present AAA 244 infrastructure. 246 Whereas the current dynamic home agent address discovery mechanism 247 requires many round trips between the mobile node and its home domain 248 thus resulting in additional signaling over the access link and 249 between the home and visited domains; and also adding more delay in 250 the procedure, the solution relying on the AAA infrastructure only 251 requires one round trip. 253 And instead of sending specific IP address to request for a Home 254 address/Home agent in the Home/Visited domain, the proposed solution 255 is based on flags: less data thus needs to be sent over the access 256 link, and the AAAh (AAAv) instead creates the binding update message 257 when assigning the home agent..RE 259 3.3. Key distribution 261 Many security associations need to be dynamically established such 262 as: 264 * the security association between the mobile node and the visited 265 network to protect data (e.g. confidentiality and integrity 266 protection) over the access link 268 * the security association between the mobile node and the home 269 agent, to authenticate the binding update/acknowledgement 270 messages. According to the current specifications, after the 271 dynamic home agent address discovery is performed, the mobile node 272 sends a Binding Update to the selected Home agent to create the 273 Binding Cache. This Binding Update MUST be authenticated, 274 therefore a key distribution, e.g. IKE, may need to be executed. 275 This requires many messages to be exchanged between the mobile 276 node and the Home Agent. 278 As an alternative, after the authentication and authorization steps, 279 the AAA servers can be involved and play a role in the key generation 280 and/or the key distribution. 282 Diameter Mobile IPv4 Application defines one key distribution 283 mechanism; for Mobile IPv6, many different schemes could be applied 284 (e.g. based on random numbers or Diffie Hellman as described in [2]) 285 thus providing more flexibility and different properties as outlined 286 in the corresponding documents [3]. 288 More details will be provided for key distribution in the next 289 versions of the document. 291 3.4. Optimization of Binding Updates 293 As previously explained, in addition to authentication, authorization 294 and key distribution functionalities, the AAA servers can perform 295 mobility procedures such as dynamic home agent assignment. In case, 296 the IPv6 mobile node already has a pre-configured Home Agent, some 297 optimization can also be achieved by having the mobile node 298 encapsulating the binding update to its Home agent. 300 3.5. Summary 302 MN authentication is in general required to grant access to a MN to 303 the foreign domain. In fact, this may be needed in most of the cases 304 even if access to the foreign domain resources is free. Due to the 305 roaming, the MN needs to perform also mobility procedures to obtain 306 reachability in the new location. Optionally, key distribution may be 307 need to take place. Using the AAA infrastructure to achieve these 308 functions can significantly reduce inter domain signaling and time 309 delay of the overwhole procedure performed by a MN to get access to 310 the foreign domain. 312 Currently the mobile node first gets authenticated using the AAA 313 infrastructure to obtain network access, then it may perform dynamic 314 home agent address discovery [4] and set up a security association 315 (using e.g. Internet Key Exchange [5]) with the selected Home agent 316 before sending a Binding Update. This will require several round 317 trips between the foreign domain and the home domain, whereas the use 318 of the AAA infrastructure provides a more efficient and quicker 319 alternative. 321 4. Mobile IPv6 Application Diameter messages 323 This memo introduces some new Command codes (AA-Registration-Request, 324 AA-Registration-Answer, Home-Agent-MIPv6-Request, Home-Agent- 325 MIPv6-Answer) and AVPs (MIP-Binding-Update AVP, MIP-Binding- 326 acknowledgement AVP, MIPv6-Mobile-Node-Address AVP, MIPv6-Home-Agent- 327 Address AVP, MIPv6-Feature-Vector AVP, Key-Request AVP, MN-Key- 328 Distribution AVP, Key-Distribution AVP) to achieve all the previously 329 identified functionalities. 331 The exact format of the messages will be provided in the next 332 versions. 334 4.1. Command Codes 336 This document introduces four new Command Codes: 338 * AA-Registration-Request Command (ARR) 340 * AA-Registration-Answer Command(ARA) 342 * Home-Agent-MIPv6-Request Command (HOR) 344 * Home-Agent-MIPv6-Answer Command (HOA) 346 4.2. AVPs 348 4.2.1. MIP-Binding-Update AVP 350 The MIP-Binding-Update AVP (AVP Code TBD) is of type OctetString and 351 contains the Mobile IP Binding Update. 353 4.2.2. MIP-Binding-acknowledgement AVP 355 The MIP-Binding-acknowledgement AVP (AVP Code TBD) is of type 356 OctetString and contains the Mobile IP Binding Acknowledgement sent 357 by the Home Agent to the MN. 359 4.2.3. MIPv6-Mobile-Node-Address AVP 361 The Mobile-Node-Address AVP (AVP Code TBD) is of type IPAddress and 362 contains the Mobile Node's Home Address. 364 4.2.4. MIPv6-Home-Agent-Address AVP 366 The Home-Agent-Address AVP (AVP Code TBD) is of type IPAddress and 367 contains the Mobile Node's Home Agent Address. 369 4.2.5. MIPv6-Feature-Vector AVP 371 The MIPv6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned32 and 372 allows for dynamic Home Agent assignment in Home Domain. In the basic 373 proposal, only one flag is defined; the other ones are reserved for 374 the enhanced version and for future utilization. 376 Flag values currently defined include: 378 1 Home-Agent-Requested: This flag is set to 1 when the 379 mobile node requests for a dynamic home agent 380 assignment. When this flag is set to 1, a dynamic 381 session key to be shared between the MN and the HA is 382 also required in order to authenticate BUs from 383 the MN to the HA: the MN may indicate through a Security 384 Key Request Option the methods it supports to compute 385 it; or a default method known to the MN and the AAAh 386 should exist(e.g. pre-set by the home domain and 387 communicated to the MN at subscription time). 389 4.2.6. Security Key AVPs 391 The AAA servers can play a role in key distribution and many methods 392 can be used with their own properties and characteristics. The 393 security keys AVPs (Key-Request AVP, MN-Key-Distribution AVP, Key- 394 Distribution AVP) format and utilization will be described in the 395 next versions as well as the AAA servers' behaviors. 397 5. Information exchange between the mobile node and the AAA Client 399 Although this document is not intended to specify any particular 400 mechanism to convey information between the mobile node and the AAA 401 Client, the information that needs to be exchanged are described. The 402 set of information identified in the follow can actually be conveyed 403 between the mobile node and the network in a different suitable 404 manner outside the scope of this document (e.g. ICMP, BURP, etc.). 405 The extensions defined for Diameter allow for any of these 406 alternatives, thus enabling such extensions to be deployed 407 independently of the choice of the protocol used between the MN and 408 the network. 410 5.1. MIP Feature Data 412 Contrary to Mobile IPv4 where the Mobile nodes send a Registration 413 Request with specific IP addresses values to request for dynamic home 414 agent assignment in home/visited networks; the IPv6 mobiles nodes 415 SHOULD use some MIP Feature data whose content includes the 416 information required in the previously defined MIPv6 Feature Vector 417 AVP: The IPv6 mobile nodes will not use specific IPv6 addresses 418 values but use flags and this will significantly reduces the amount 419 of data to be sent over the access link. In addition, the attendant 420 will only need to encapsulate that option in the corresponding 421 MIPv6-Feature-Vector AVP. 423 The MIP Feature data could be sent as an extension to ICMPv6 424 messages, a new Destination Option or carried in any other way. 426 5.2. EAP Data 428 The IPv6 Mobile Node should be able to use different authentication 429 methods such as the different EAP types. 431 The EAP Data could be sent as an extension to ICMPv6 messages, 432 carried using BURP or any other protocol. 434 5.3. Security Key Data 436 This document does not defines the protocol between the mobile nodes 437 and the network but the mobile node SHOULD use some key request 438 option to indicate the keys it needs, but also the methods it 439 supports to generate them. 441 Those Security Key data SHOULD contain the relevant information so 442 the AAA client can create the corresponding Security Keys AVPs. 444 The required information will be described in the next versions of 445 the document. 447 5.4. Embedded Data 449 The embedded data enables the mobile node to send a binding update at 450 the same time the mobile node gets authorized/authenticated by the 451 network (e.g. by mechanism that BURP will provide) thus saving round 452 trips between the home and the visited domains. 454 6. Basic Protocol Overview 456 6.1. Authentication 458 Authentication is required before providing network access to the 459 user. 461 Different authentication should be supported to allow more 462 flexibility; but as demonstrated in [6], both network and user 463 authentication should be supported. 465 And current authentication mechanisms, even those recently specified 466 in different standardization for a (UMTS AKA in 3GPP; CAVE based 467 security functions in IS41 Systems) have security flaws. 469 For these reasons, even as previously mentioned any existing 470 authentication could be used, in the following illustrations and 471 procedures, a mutual challenge response based authentication method 472 will be suggested and used as default. 474 The authentication mechanism assumed here assumes that a Local 475 Challenge is broadcast over the access link in Router Advertisement 476 messages. 478 6.2. Information flows 480 Basic Procedure with dynamic Home Agent assignment in the Home 481 network or pre-configured Home Agent 483 Mobile Node AAA Client AAAv AAAh Home Agent 484 ----------- ----------- ------------ ---------- ---------- 485 Advertisement & 486 <---1.1 -- Challenge 487 -1.2 IPv6 ----> 488 1.3 ARR-------------> 489 1.4 ARR------------> 490 1.5 HOR-----------> 491 <----------1.6 HOA 492 <-----------1.7 ARA 493 <------------1.8 ARA 494 <----1.9 IPv6 496 6.3. MN Considerations 498 6.3.1. Generation of information in MN 500 1) When entering a new network or at power up, the MN listens to the 501 router advertisements and retrieves: 503 The Local Challenge 504 The visited network identifier 505 The information to derive the CoA 507 2) It computes the CoA, and based on the following information, 508 * The NAI 509 * The long-term security key shared with its AAAh 510 * The Home Address: in the basic mode, the mobile node is 511 assumed to have a pre-configured Home IP address 512 * The Home Agent (if any), otherwise MN can request to have 513 one assigned 515 creates a message with the CoA as the Source IP address and the AAA 516 Client address as the Destination IP address. (The MN can learn the 517 IP address of the AAA Client through router advertisements or others 518 mechanisms outside the scope of this document.) As previously 519 explained, the mobile node also sends its NAI. 521 3) The MN optionally generates a Host Challenge that it will send to 522 the network for both network authentication and anti replay attacks. 523 Then the MN computes the MN authentication data using the long-term 524 key, the host challenge, the visited network identifier, the local 525 challenge, and an authentication algorithm it shares with its home 526 network. The MN authentication data is then sent to the AAA Client, 527 4) If the MN does not have a Home Agent and requests one, the MN 528 includes a MIP Feature Option with the Home-Agent-Requested flag set 529 to 1. The home agent will then be assigned by the home AAA server, 530 and the binding update will be sent by the AAA server to the Home 531 Agent on behalf of the mobile node that, in turn, does not need to 532 send any. 534 If the MN have a pre configured Home Agent, it may creates the 535 binding update message and sends it encapsulated to the AAA client. 536 The Binding Update message will be forwarded to the designated home 537 agent via the AAA infrastructure. This binding update message has 538 the MN IP CoA as the source IP address, the pre-configured HA as the 539 destination IP address and the BU option with the pre-configured Home 540 IP address in the Home address sub option. 542 5) The MN may also requests for some security keys thanks to the 543 Security Key Request Option. 545 The MN SHOULD perform authentication in the following cases: 547 * When changing visited domain: MN can know that by listening 548 the router advertisements 549 * When requesting session keys 550 * When requesting a Home Agent assignment 551 * When requesting a home address assignment 553 6.3.2. Replies to MN 555 When receiving the reply from the AAA Client, the MN: 557 * Authenticates the network thanks to the network authentication 558 data sent by the AAA Client 560 * If the MN requested a Home agent, it will learn and store the Home 561 Agent address from the source IP address of the Home Binding 562 Acknowledgement. 564 The MN creates the security associations from the keying material 565 received. 567 6.4. AAA Client Operation 569 As indicated above, the mobile node may interact with the AAA Client 570 to perform authentication/authorization and optionally Mobile IP 571 procedures. Thus, the AAA client may perform authentication functions 572 and optionally Mobile IP functions 574 When the AAA Client receives an authentication request message from a 575 IPv6 Mobile node: 577 The AAA Client first verifies the freshness of the request thanks to 578 the Local Challenge contained in it (i.e. the MN may use an older 579 Local Challenge) and if successful, performs Duplicate Address 580 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 581 message carrying the following information to the AAAh: 583 * User Name AVP [7] carrying the user's NAI 585 * EAP AVP to carry the authentication data for mutual authentication 586 derived from the content of the received authentication data 588 * if a MIP feature Option was received from the MN, a MIPv6-Feature- 589 Vector AVP whose content is derived from the MIP feature Option, 590 sent within the ARR message it sends to the AAAv 592 * MIP-Binding Update AVP if the MN sent a Home Binding Update in an 593 Embedded data option 595 * MIPv6-Home-Agent-Address AVP if the MN sent a binding update 596 message: the Home agent address value is extracted from the 597 Destination IP address field of the embedded home binding update. 598 This AVP enables the AAAh to know where to send the MIP-Home- 599 binding-Update AVP if one was present. 601 * if the MN provides a Key Request Option, a Security-Key-Request- 602 AVP whose content is derived from the Key Request Option. 604 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 605 the AAA Client converts the message to appropriate protocol to the 606 MN; this message carries: 608 * the authentication data 610 * Binding Acknowledgement in an Embedded Data Option if MN sent a 611 home Binding Update or requested for a dynamic home agent 612 assignement. 614 The message may also include: 616 *Keying 618 6.5. AAAv Operation 620 When AAAv receives an ARR message [7]: 622 First the AAAv verifies the message is coming from a valid AAA Client 623 and then, checks the MIPv6 Feature Vector AVP, and then sends it to 624 the MN's home AAA server. 626 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 627 according to the behaviour specific for speficic EAPs or other 628 mechanisms defined elsewhere, store locally information contained in 629 the AVPs of the message received from the AAAh (e.g. session keys, 630 etc.) and then forwards the message to the AAA Client. 632 6.6. AAAh operations 634 * When receiving an ARR message from an AAAv, the AAAh first 635 verifies the message is coming from a valid AAAv. Security 636 associations between AAA server are outside the scope of the 637 present document. 639 The AAAh then authenticates the user using the NAI provided by the MN 640 as MN identity. If the mobile Node is successfully authenticated: 642 * AAAh also computes some network authentication data based on the 643 Host Challenge and eventually other information depending on the 644 authentication algorithm adopted. 646 Depending on the authentication method requirements, the AAAh may 647 exchange many messages with the MN via the AAAv (e.g. for a user 648 authentication mechanism that requires more than one round-trip): 649 AAAh may send a ARA Command with the ppropriate authentication 650 information and indication, which will be converted to EAP Option by 651 the AAA Client to the MN or conveyed to the MN in other suitable 652 manner (outside the scope of this document). The number of round 653 trips varies depending on the authentication mechanism used. 655 * If the MN asks for some security keys, the AAAh performs the 656 appropriate steps and eventually sends the corresponding messages 657 to achieve the key distribution: many mechanisms exist and will be 658 described later on. Such steps may require the AAAh to distribute 659 keys and keying material to the MN, to other AAA servers or other 660 nodes. 662 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 663 the address is that of a known and valid Home Agent, and one that 664 the Mobile Node is allowed to request. AAAh then forwards the MIP- 665 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 666 MIP-Request) message. 668 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 669 MIPv6-Feature-Vector AVP if any. If present, AAAh performs the 670 dynamic home agent assignment in the Home network: 672 Mobile Node AAA Client AAAv AAAh Home Agent 673 ----------- ----------- ------------ ---------- ---------- 674 Advertisement & 675 <---1.1 -- Challenge 676 -1.2 IPv6 ------> 677 1.3 ARR-------------> 678 1.4 ARR------------> 679 1.5 HOR-----------> 680 <----------1.6 HOA 681 <-----------1.7 ARA 682 <------------1.8 ARA 683 <-------1.9 IPv6 685 (1.5) AAAh allocates a Home agent on behalf of the MN: this can 686 be done in a variety of ways, including using a load balancing 687 algorithm in order to keep the load on all HAs equal. 689 * AAAh sends a HOR message to the HA including a newly created 690 binding update. 692 * AAAh sends some security keying material to allow the Home 693 Agent to comupte the key(s) for the security association 694 between the MN and the Home Agent to authenticate future 695 Binding Updates. 697 (1.6) the Home Agent creates the Binding Cache and computes the 698 key(s) for the security association with the MN from the data 699 received. It also generates a Binding Acknowledgement message to 700 be sent encapsulated to the MN. 702 * The HA sends a HOA message to the AAAh including the Binding 703 Ack. 705 (1.7) AAAh may also compute other keying material according to the 706 keys requested by the MN and send it to the MN passing through the 707 AAAv. 709 * AAAh then send an ARA message to the AAAv including the 710 MIPv6-Home-Agent-Address AVPs if the MN did not have any Home 711 address or Home agent. 713 6.7. Home Agent Behavior 715 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 716 message: if the HOR is invalid, a HOA is returned with the Result- 717 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 718 processes the MIP-Binding-update AVP and creates the Binding 719 Acknowledgement, encapsulating it within the MIP-binding- 720 acknowledgement AVP. 722 HA also creates the Binding Cache and computes the key(s) for the 723 security association with the MN from the data received. 725 7. Enhanced features 727 In addition to the previously described features, additional features 728 can be supported by the AAA infrastructure for the inter-domain 729 roaming of an IPv6 mobile node, thus providing more flexibility and 730 allowing new options to the services providers to develop business 731 models. 733 A IPv6 mobile node can have a pre-configured home address and a pre- 734 configured home agent and, as explained in the previous section, the 735 basic features of the Mobile IPv6 Diameter Application allow an 736 optimization of the authentication, the binding update and the key 737 distribution procedures. 739 Optionally, two enhanced features are suggested: 741 * The dynamic Home agent assignment in the Visited Domain 742 * The dynamic Home address assignment 744 7.1. Dynamic Home Agent/ Home Address assignment in Visited domain 746 The Dynamic Home Agent assignment in visited networks allows more 747 flexibility and allows new business scenarios. As an example, service 748 providers may just own a AAA server for accounting purposes and, 749 thanks to roaming agreements, they may offer Mobile IP services to 750 its subscribers. Another scenario where this can be applied is when 751 IPv6 mobile nodes need to obtain reachability from other CN only at 752 the application level, i.e. through a SIP infrastructure. This may be 753 the case of a basic IPv6 MN supporting only voice services through 754 SIP. In such cases, when a CN needs to reach the MN an identifier at 755 the application level (e.g. MN SIP URL) is used, and the CN does not 756 need to know the permanent address of the MN. Somebody may argue that 757 Mobile IP is not needed at all in such cases, but it may instead be 758 used to support mobility between the initial point of attachment 759 (i.e. when the MN powered up in the foreign domain) and following 760 points of attachment in the foreign domain. 762 7.2. Dynamic Home address assignment in Home Domain 764 The mobile node may not always have a pre-configured IPv6 address and 765 may need to have one dynamically assigned. In addition since the Home 766 Agent and the mobile node permanent address need to be on the same 767 link, to support dynamic home agent assignment in visited networks, 768 dynamic home address assignment in visited networks is supported. 770 Finally, this dynamic Home address feature provides more flexibility 771 to the service provider even when the Home agent is to be assigned in 772 the Home network since the Home agent and the home address should be 773 on the same subnet. Additionally, the scenario described in section 774 7.2 of a MN node needing reachability only at the application layer 775 applies to this case too. 777 7.3. Enhanced AVPs 779 In addition to the Command Codes and AVPs described in section 4, 780 some new AVP need to be defined to support the enhanced features. 782 7.3.1. MIPv6-Feature-Vector AVP 784 In the extended mode, dynamic home agent assignment in the visited 785 network is feasible.Additional flags of the MIPv6-Feature-Vector AVP 786 are therefore defined. 788 The following flags allow the Visited AAA server, AAAv, to inform of 789 its capabilities and if the Home agent is assigned in the visited 790 network, the Home address must also be assigned in the visited 791 network. 793 The AAA Client includes a MIPv6-Feature-Vector AVP within the ARR 794 message it sends to the AAAv if the MN sent a MIP Feature option. 796 Flag values currently defined include: 798 1 Home-Agent-Requested: This flag is set to 1 when the 799 mobile node requests for a dynamic home agent 800 assignment. When this flag is set to 1, a dynamic 801 session key to be shared between the MN and the HA is 802 also required in order to authenticate BUs from 803 the MN to the HA: the MN may indicate through a Security 804 Key Request Option the methods it supports to compute 805 it; or a default method known to the MN and the AAAh 806 should exist(e.g. pre-set by the home domain and 807 communicated to the MN at subscription time). 809 2 Mobile-Node-Home-Address-Requested flag: This flag to 1 810 if the mobile node does not have any Home address and 811 requires one. Default value is 0. 813 4 Home-Address-Allocatable-Only-in-Home-Domain flag: This 814 flags is set to 1 if the mobile node requests for one 815 Home address and wants it to be assigned by its home 816 network. Default value is 0 and means that the MN does 817 not have any preference on whether the Home Address 818 shall be allocated in the home domain and 819 visited domain. 821 8 Home-Agent-in-Visited-Domain flag: The mobile node 822 indicates its preference to have its Home Agent 823 allocated in the visited domain by having this flag set 824 to 1 826 16 Visited-Home-Agent-Available flag: The Visited Domain 827 sets this flag to 1 if the MN asks a dynamic Home Agent 828 assignment in the Visited Domain and the Visited Domain 829 agrees to allocate one to the MN. 831 8. Enhanced Protocol Overview 833 The enhanced mode allows dynamic home agent and dynamic home address 834 assignment in the visited network. The mobile node may not have any 835 preconfigured home address nor any home agent. The following text 836 describes the different entities' behaviors in the Enhanced mode. 838 The authentication procedure is the same than the one described 839 above. 841 All the functionalities (key distribution, optimization of Binding 842 Upate, dynamic Home Agent assignment in Home network) of the basic 843 mode are present but in addition the Home agent and the home address 844 can be assigned in the visited network: the entities behaviours and 845 the way the corresponding AVPs are processed, are explained 847 8.1. Information flow 849 Enhanced Procedure with dynamic Home agent and Home address in the 850 Visited network 852 Mobile Node AAA Client Home Agent AAAv AAAh 853 ----------- ----------- ------------- ---------- -------- 854 <---2.1 Challenge--- 855 -2.2 IPv6 -----> 856 ----------2.3 ARR-------------> 857 ---2.4 ARR----> 858 <--2.5 HOR----- 859 <---2.6 HOR----- 860 ----2.7 HOA-----> 861 ---2.8 HOA----> 862 <--2.9 ARA----- 863 <-----------2.10 ARA------------ 864 <-2.11 IPv6 ----- 866 8.2. MN Considerations 868 8.2.1. Generation of information in MN 870 The mobile node performs the same steps as in the basic mode (steps 871 (1), (2), (3) section 6.3.1) and then 873 4) If the MN does not have a Home Address and requests one, the MN 874 also includes a MIP Feature Option with the Mobile-Node-Home-Address- 875 Requested flag set to 1: 877 * If MN wants its Home address to be allocated by its home network, 878 it also sets the value of Home-Address-Allocatable-Only-in-Home- 879 Domain flag to 1. 881 If the MN does not have a Home Agent and requests one, the MN also 882 includes a MIP Feature Option with the Home-Agent-Requested flag set 883 to 1. The home agent will then be assigned by the AAA server, and the 884 binding update will be sent by the AAA server to the Home Agent on 885 behalf of the mobile node that, in turn, does not need to send any. 887 * If MN wants its Home agent to be allocated by the visited network, 888 it also sets the Home-Agent-in-Visited-Network flag to 1. 890 The following table describes the different supported cases and the 891 flags that need to be set according to the needs: 893 HD means Home Domain 894 VD means Visited Domain 895 NP means MN has No Preference 896 X means not supported 898 P: Mobile-Node-Home-Address-Requested flag 899 H: Home-Address-Allocatable-Only-in-Home-Domain 900 A: Home-Agent-Requested 901 V: Home-Agent-In-Visited-Network 903 +---------+------------------------------------------------+ 904 | | Home agent Requested | 905 +---------+---+--------------------+-----------------------+ 906 | | | YES | NO | 907 | +---+--+-----+-----+-----+-----------------------+ 908 | | | | HD | VD | NP | | 909 |Home addr| +--+-----+-----+-----+-----------------------+ 910 |Requested| |HD| PAH | x | x | PH | 911 | | +--+-----+-----+-----+-----------------------+ 912 | |YES|VD| x |PAV | x | x | 913 | | +--+-----+-----+-----+-----------------------+ 914 | | |NP| x | x |PA | P | 915 | +---+--+-----+-----+-----+-----------------------+ 916 | | | | | | | | 917 | | NO| | A* | x | x | no MIP FeatureOption | 918 | | | | | | | | 919 +---------+---+--+-----+-----+-----+-----------------------+ 921 A*: MN already has a home address in its Home network and may request 922 for a Home Agent. The HA can thus only be assigned in the Home Network. 924 While the MN gets authenticated and authorized, if the MN already has 925 a home address and a home agent, it can send a Home Binding Update 926 together with the request to be authorized and authenticated to save 927 one round trip over the access link and between the visited and home 928 networks. This binding update is in this case sent as Embedded Data 929 option: 931 The Home Binding Update has: 932 * The H flag set to 1. 933 * The source IP address equals to the CoA 934 * The destination IP address set to the Home agent address 935 * The Home Address Option set to the MN Home address 937 5) The MN may also requests for some security keys thanks to the 938 Security Key Request Option. 940 The MN SHOULD perform authentication in the following cases: 942 * When changing visited domain: MN can know that by 943 listening the router advertisements 944 * When requesting session keys 945 * When requesting a Home Agent assignment 946 * When requesting a home address assignment 948 8.2.2. Replies to MN 950 When receiving the reply from the AAA Client, the MN: 952 * Authenticates the network thanks to the network authentication 953 data sent by the AAA Client 955 * If the MN requested a Home agent, it will learn and store the Home 956 Agent address from the source IP address of the Home Binding 957 Acknowledgement. 959 * If the MN did not have a Home IP address and requested for one, 960 the MN will learn and store the assigned home address from the 961 home address option of the Home Binding Acknowledgement (embedded 962 data option). 964 The MN creates the security associations from the keying material 965 received. 967 8.3. AAA Client Operation 969 As indicated above, the mobile node may interact with the AAA Client 970 to perform authentication/authorization and optionally Mobile IP 971 procedures. Thus, the AAA client may perform authentication functions 972 and optionally Mobile IP functions 974 When the AAA Client receives an authentication request message from a 975 IPv6 Mobile node: 977 The AAA Client first verifies the freshness of the request thanks to 978 the Local Challenge contained in it (i.e. the MN may use an older 979 Local Challenge) and if successful, performs Duplicate Address 980 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 981 message carrying the following information to the AAAh: 983 * User Name AVP [7] carrying the user's NAI 985 * EAP AVP to carry the authentication data for mutual authentication 986 derived from the content of the received authentication data 988 * if a MIP feature Option was received from the MN, a MIPv6-Feature- 989 Vector AVP whose content is derived from the MIP feature Option, 990 sent within the ARR message it sends to the AAAv 992 * MIP-Binding Update AVP if the MN sent a Home Binding Update in an 993 Embedded data option 995 * MIPv6-Home-Agent-Address AVP if the MN sent a Home binding update: 996 the Home agent address value is extracted from the Destination IP 997 address field of the embedded home binding update. This AVP 998 enables the AAAh to know where to send the MIP-Home-binding-Update 999 AVP if one was present. 1001 * if the MN provides a Key Request Option, a Security-Key-Request- 1002 AVP whose content is derived from the Key Request Option. 1004 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 1005 the AAA Client converts the message to appropriate protocol to the 1006 MN; this message carries: 1008 * the authentication data 1010 * Binding Acknowledgement in an Embedded Data Option if MN sent a 1011 home Binding Update or requested for a dynamic home agent 1012 assignment. 1014 The message may also include: 1016 * Keying material to set up the different session keys, in different 1017 Security Key Data Option created by the AAA Client from the MN- 1018 Key-Distribution AVP. When the MN asks for a dynamic Home Agent, 1019 AAAh must compute the security key to be shared between MN and the 1020 HA for authenticating subsequent Binding Updates, and sends the 1021 corresponding keying material to the MN. 1023 8.4. AAAv Operation 1025 When AAAv receives an ARR message [7]: 1027 First the AAAv verifies the message is coming from a valid AAA Client 1028 and then, checks the MIPv6 Feature Vector AVP: 1030 * If the MN requested a Home Agent by setting the Home-Agent- 1031 Requested flag to 1, and does not specify that this one should be 1032 assigned only in its Home domain by setting the Home-Address- 1033 Allocatable-Only-in-Home-Domain flag to 1, the AAAv checks if it 1034 can allocate a Home Agent for the mobile node in the visited 1035 domain. If AAAv can allocate a Home Agent in the visited domain, 1036 it indicates this to the AAAh by setting the Visited-Home-Agent- 1037 Available flag to 1 of the MIPv6 Feature Vector AVP forwarded to 1038 the AAAh. 1040 When receiving a HOR message from the AAAh for a dynamic Home Agent 1041 assignment in the visited network, the AAAv performs the dynamic Home 1042 agent assignment and MAY perform some key distribution depending on 1043 the mechanisms. 1045 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 1046 according to the behavior specific for speficic EAPs or other 1047 mechanisms defined elsewhere, store locally information contained in 1048 the AVPs of the message received from the AAAh (e.g. session keys, 1049 etc.) and then forwards the message to the AAA Client. 1051 8.5. AAAh operations 1053 * When receiving an ARR message from an AAAv, the AAAh first 1054 verifies the message is coming from a valid AAAv. Security 1055 associations between AAA server are outside the scope of the 1056 present document. 1058 The AAAh then authenticates the user using the NAI provided by the MN 1059 as MN identity. If the mobile Node is successfully authenticated: 1061 * AAAh also computes some network authentication data based on the 1062 Host Challenge and eventually other information depending on the 1063 authentication algorithm adopted. 1065 Depending on the authentication method requirements, the AAAh may 1066 exchange many messages with the MN via the AAAv (e.g. for a user 1067 authentication mechanism that requires more than one round-trip): 1068 AAAh may send a ARA Command with the appropriate authentication 1069 information and indication, which will be converted to EAP Option by 1070 the AAA Client to the MN or conveyed to the MN in other suitable 1071 manner (outside the scope of this document). The number of round 1072 trips varies depending on the authentication mechanism used. 1074 * If the MN asks for some security keys, the AAAh performs the 1075 appropriate steps and eventually sends the corresponding messages 1076 to achieve the key distribution: many mechanisms exist and will be 1077 described later on. Such steps may require the AAAh to distribute 1078 keys and keying material to the MN, to other AAA servers or other 1079 nodes. 1081 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 1082 the address is that of a known and valid Home Agent, and one that 1083 the Mobile Node is allowed to request. AAAh then forwards the MIP- 1084 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 1085 MIP-Request) message including the appropriate key material to set 1086 up the security association between the MN and the Home Agent. 1088 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 1089 MIPv6-Feature-Vector AVP if any. Depending on the mobile node 1090 request (Home-Agent-in-Visited-Network flag), the visited network 1091 capabilities (Visited-Agent-Available AVP) and the local policy, 1092 the AAAh decides whether to assign the HA in the home or visited 1093 network: 1095 8.5.1. Home Agent Assignement in Visited Network 1097 If the AAAh accepts the HA to be assigned in the visited domain, the 1098 following exchange of messages takes place: 1100 Mobile Node AAA Client Home Agent AAAv AAAh 1101 ----------- ----------- ------------- ---------- ------- 1102 <---2.1 Challenge---- 1103 -2.2 IPv6 ---------> 1104 ----------2.3 ARR-------------> 1105 ---2.4 ARR----> 1106 <--2.5 HOR----- 1107 <---2.6 HOR----- 1108 ----2.7 HOA-----> 1109 ---2.8 HOA----> 1110 <--2.9 ARA----- 1111 <-----------2.10 ARA------------ 1112 <-2.11 IPv6 --------- 1114 (2.5): AAAh sends a HOR message to the AAAv with neither any 1115 MIPv6-Mobile-Node-Address AVP nor any MIPv6-Home-Agent-Address 1116 AVP. 1118 * AAAh may send some keying material for HA to derive the key(s) 1119 for the security association between the MN and the Home Agent 1120 to authenticate future Binding Updates depending on the key 1121 distribution mechanism chosen 1123 * AAAh may also send other keying material according to the keys 1124 requested by the MN 1126 (2.6): AAAv assigns a Home agent and then creates and sends it a 1127 newly created Binding Update encapsulated in the HOR message. 1129 * AAAv may assign Home IP address for the MN and informs the Home 1130 Agent by adding a MIPv6-Mobile-Node-Address AVP in the HOR 1131 message; or let the Home Agent assigns the Home address by not 1132 providing a MIPv6-Mobile-Node-Address AVP in the HOR message. 1134 * AAAv may forward to the Home Agent some keying material 1135 depending on the key distribution mechanism adopted to set up 1136 the security association between the MN and the Home Agent 1138 (2.7): The Home agent assigns a Home IP address if requested and 1139 creates a Binding Cache for the MN. 1141 * The Home agent creates the Security Association according to 1142 the mechanism adopted 1144 * The Home Agent creates the Binding Acknowledgement to be sent 1145 encapsulated to the MN. 1147 * The Home Agent sends back a HOA to the AAAv to inform it of the 1148 status: it includes the assigned Mobile Node Home Address if 1149 the Home Agent assigned one; it also includes the Binding ack 1150 created by the Home Agent to be sent encapsulated to the MN. 1152 (2.8) The AAAh is informed of the assigned Home IP address 1153 (contained in the MIPv6-Mobile-Node-Address AVP) and the Home 1154 Agent address (contained in the MIPv6-Home-Agent-Address AVP) by 1155 the HOA message sent from the AAAv. 1157 (2.9) The AAAh sends the AAAv an ARA carrying the Home IP address, 1158 the Home Agent IP address, the keying material with the previous 1159 information. 1161 8.5.2. Home Agent Assignment in Home Network 1163 If the AAAh decides to assign the HA in the Home network, the 1164 following exchange of messages takes place: 1166 Mobile Node AAA Client AAAv AAAh Home Agent 1167 ----------- ----------- ------------ ---------- ---------- 1168 Advertisement & 1169 <---3.1 -- Challenge 1170 -3.2 IPv6 ------> 1171 3.3 ARR-------------> 1172 3.4 ARR------------> 1173 3.5 HOR-----------> 1174 <----------3.6 HOA 1175 <-----------3.7 ARA 1176 <------------3.8 ARA 1177 <-------3.9 IPv6 1179 (3.5) AAAh allocates a Home agent on behalf of the MN: this can be 1180 done in a variety of ways, including using a load balancing 1181 algorithm in order to keep the load on all HAs equal. 1183 * AAAh sends a HOR message to the HA including a newly created 1184 binding update and: 1186 * The AAAh may allocate a home address for the mobile node and 1187 include it in a MIPv6-Mobile-Node-Address AVP within the HOR or 1188 else leave this allocation responsibility for the HA by leaving 1189 the Home address option of the binding update to zero and not 1190 sending any MIPv6-Mobile-Node-Address AVP. 1192 * AAAh sends some security keying material to allow the Home 1193 Agent to compute the key(s) for the security association 1194 between the MN and the Home Agent to authenticate future 1195 Binding Updates. 1197 (3.6) If the Home Agent does not receive any MIP-Mobile-node- 1198 address, and receives a BU with a Home address equals to 0, it 1199 assigns a Home IP address for that user; then creates the Binding 1200 Cache and computes the key(s) for the security association with 1201 the MN from the data received. It also generates a Binding 1202 Acknowledgement message to be sent encapsulated to the MN. 1204 * The HA sends a HOA message to the AAAh including the Binding 1205 Ack and eventually the assigned Home IP address if one was 1206 requested. 1208 (3.7) AAAh may also compute other keying material according to the 1209 keys requested by the MN and send it to the MN passing through the 1210 AAAv. 1212 * AAAh then send an ARA message to the AAAv including the 1213 MIPv6-Mobile-Node-Address and MIPv6-Home-Agent-Address AVPs if 1214 the MN did not have any Home address or Home agent. 1216 8.6. Home Agent Behavior 1218 Upon receipt of the HOR, the Home Agent first processes the 1219 DIAMETER message: if the HOR is invalid, a HOA is returned with 1220 the Result-Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the 1221 Home Agent processes the MIP-Binding-update AVP and creates the 1222 Binding Acknowledgement, encapsulating it within the MIP-binding- 1223 acknowledgement AVP. 1225 If a home address is needed, the Home Agent assigns one and 1226 includes the address in both the Binding acknowledgement message 1227 (Home address option) and in the MIPv6-Mobile-Node-Address AVP. 1229 HA then creates the Binding Cache and computes the key(s) for the 1230 security association with the MN from the data received. 1232 9. Conclusions 1234 The Diameter Mobile IPv6 application defined in this document 1235 allows for support of authentication and authorization of IPv6 1236 mobile nodes roaming between different domains. In addition, it 1237 support key distribution and mobility by optimizing these 1238 procedures. The application defines also new enhanced features 1239 that introduce flexibility in the definition of business models 1240 for service providers and allow for different types of terminals. 1242 This first version focuses on the different functionalities 1243 involved in the support by the AAA infrastructure of inter domain 1244 roaming of Mobile IPv6 nodes. 1246 10. Security Considerations 1248 The Diameter Mobile IPv6 application defined in this document does 1249 not create new security breaches for the IPv6 MN and the foreign 1250 and visited domain. On the contrary, it allows for an effective 1251 and efficient MN authentication and authorization when roaming 1252 between different domains. 1254 11. References 1256 [1] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile 1257 IPv4 Application" Internet draft, Internet Engineer Task 1258 Force, June 2001 1260 [2] Diffie, W. and Hellman, M., "New Directions ijn 1261 Cryptography", IEEE Transactions on Information Theory, 1262 Vol. IT-22, Nov. 1976, pp. 664-654 1264 [3] Franck Le, Stefano M. Faccin, "Key distribution 1265 mechanisms for Mobile IPv6" Internet draft, Internet 1266 Engineer Task Force, February 2001 1268 [4] David B. Johnson, Charles Perkins, "Mobility Support in 1269 IPv6" Internet draft, Internet Engineer Task Force, July 1270 2001 1272 [5] D. Harkins, D. Carrel, "The Internet Key Exchange 1273 (IKE)", RFC 2409, Internet Engineer Task Force, November 1274 1998 1276 [6] Sarvar Patel, "Weaknesses of North American Wireless 1277 Authentication Protocol", IEEE Personal Communications, 1278 June 1997 1280 [7] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, 1281 Allan C. Rubens,Glen Zorn, "Diameter Base Protocol" 1282 Internet draft, Internet Engineer Task Force, June 2001 1284 12. Authors' Addresses 1286 Stefano M. Faccin 1287 Nokia Research Center 1288 6000 Connection Drive 1289 Irving, TX 75039 1290 USA 1292 Phone: +1 972 894-4994 1293 E-mail: stefano.faccin@nokia.com 1295 Franck Le 1296 Nokia Research Center 1297 6000 Connection Drive 1298 Irving, TX 75039 1299 USA 1301 Phone: +1 972 374-1256 1302 E-mail: franck.le@nokia.com 1304 Basavaraj Patil 1305 Nokia Corporation 1306 6000 Connection Drive 1307 Irving, TX 75039 1308 USA 1310 Phone: +1 972-894-6709 1311 E-Mail: Raj.Patil@nokia.com 1313 Charles E. Perkins 1314 Nokia Research Center 1315 313 Fairchild Drive 1316 Mountain View, California 94043 1317 USA 1319 Phone: +1 650-625-2986 1320 E-Mail: charliep@iprg.nokia.com