idnits 2.17.1 draft-calhoun-diameter-mobileip-11.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: '2' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1177, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-08 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-aaa-reqs (ref. '3') ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2486 (ref. '6') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '7') == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-08 -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-05 -- Possible downref: Normative reference to a draft: ref. '14' -- Unexpected draft version: The latest known version of draft-calhoun-mobileip-aaa-key is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-02) exists of draft-hiller-cdma2000-aaa-01 ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '16') -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-05 -- Possible downref: Normative reference to a draft: ref. '18' Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Laboratories, Inc. 4 Title: draft-calhoun-diameter-mobileip-11.txt Charles E. Perkins 5 Date: September 2000 Nokia Research Center 7 DIAMETER Mobile IP Extensions 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 This document is an individual contribution for consideration by the 31 AAA Working Group of the Internet Engineering Task Force. Comments 32 should be submitted to the mobileip@nortelnetworks.com mailing list. 34 Distribution of this memo is unlimited. 36 Copyright (C) The Internet Society 1999. All Rights Reserved. 38 Abstract 40 This document specifies an extension to the DIAMETER base protocol 41 that allows a DIAMETER server to authenticate, authorize and collect 42 accounting information for services rendered to a mobile node. 43 Combined with the Inter-Domain capability of the base protocol, this 44 extension allows mobile nodes to receive service from foreign service 45 providers. The DIAMETER Accounting extension will be used by the 46 Foreign and Home agents to transfer usage information to the DIAMETER 47 servers. 49 Table of Contents 51 1.0 Introduction 52 1.1 Requirements language 53 1.2 Inter-Domain Mobile IP 54 1.3 Allocation of Home Agent in Foreign Network 55 1.4 DIAMETER Session Termination 56 2.0 Command-Code Values 57 2.1 AA-Mobile-Node-Request (AMR) Command 58 2.2 AA-Mobile-Node-Answer (AMA) Command 59 2.3 Home-Agent-MIP-Request (HAR) Command 60 2.4 Home-Agent-MIP-Answer (HAA) Command 61 2.5 Home-Agent-Allocated-Ind (HAI) Command 62 3.0 Result-Code AVP Values 63 4.0 DIAMETER AVPs 64 4.1 MIP-Reg-Request AVP 65 4.2 MIP-Reg-Reply AVP 66 4.3 MN-AAA-Auth AVP 67 4.4 Mobile-Node-Address AVP 68 4.5 Home-Agent-Address AVP 69 4.6 Previous-FA-NAI AVP 70 4.7 Previous-FA-Addr AVP 71 4.8 MIP-Feature-Vector AVP 72 5.0 Key Distribution Center 73 5.1 Distributing the Mobile-Home Registration Key 74 5.2 Distributing the Mobile-Foreign Registration Key 75 5.3 Distributing the Foreign-Home Registration Key 76 5.4 Key Distribution Example 77 6.0 Key Distribution Center (KDC) AVPs 78 6.1 Mobile Node Session Key AVPs 79 6.2 Mobility Agent Session Key AVPs 80 6.3 FA-MN-Preferred-SPI AVP 81 6.4 FA-HA-Preferred-SPI AVP 82 7.0 Interactions with Resource Management 83 8.0 Acknowledgements 84 9.0 IANA Considerations 85 10.0 Security Considerations 86 11.0 References 87 12.0 Authors' Addresses 88 13.0 Full Copyright Statement 90 1.0 Introduction 92 Mobile IP, as defined in [4], defines a method that allows a Mobile 93 Node to change its point of attachment to the Internet with minimal 94 service disruption. Mobile IP does not provide any specific support 95 for mobility across disparate administrative domains, and therefore 96 does not specify how usage can be accounted for, which has limited 97 the applicability of Mobile IP in a IPv4 commercial deployment. The 98 Mobile IP protocol [4] requires that mobile nodes have static home 99 agent and home addresses, which is not desirable in a commercial 100 network. Recent specification [8] allows a mobile node to use its 101 NAI instead of its home address, which better accommodates current 102 administrative practice. 104 This document specifies Extension 4 to the DIAMETER base protocol [1] 105 that allows a DIAMETER server to authenticate, authorize and collect 106 accounting information for services rendered to a mobile node. 107 DIAMETER nodes conforming to this specification MUST include an 108 Extension-Id AVP with a value of four in the Device-Reboot-Ind 109 Command [1]. Combined with the Inter-Domain capability of the base 110 protocol, this extension allows mobile nodes to receive service from 111 foreign service providers. The DIAMETER Accounting extension [12] 112 will be used by the Foreign and Home agents to transfer usage 113 information to the DIAMETER servers. 115 The Mobile IP protocol [4] specifies a security model that requires 116 that mobile nodes and home agents share a pre-existing security 117 association, which leads to scaling and configuration issues. This 118 specification defines DIAMETER functions that allow the AAA server to 119 act as a Key Distribution Center (KDC), whereby dynamic registration 120 keys are created and distributed to the mobility entities for the 121 purposes of securing Mobile IP Registration messages. 123 As with the DIAMETER base protocol, AAA servers implementing the 124 Mobile IP extension can process users' identities supplied in a 125 Network Access Identifier (NAI) format [6], which is used for 126 DIAMETER message routing purposes. Mobile nodes include their NAI in 127 Registration messages, as defined in [8]. The use of the NAI is 128 consistent with the roaming model defined by the ROAMOPS Working 129 Group [7]. 131 The DIAMETER Mobile-IP Extension meets the requirements specified in 133 [3, 16]. Later subsections in this introductory section provide some 134 examples and message flows of the Mobile IP and DIAMETER messages 135 that occur when a Mobile Node requests service in a foreign network. 136 In this document, the role of the "attendant" [3] is performed by the 137 foreign agent for the Mobile-IP Extension, and these terms will be 138 used interchangeably. 140 1.1 Requirements language 142 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 143 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 144 described in [11]. 146 1.2 Inter-Domain Mobile IP 148 When a Mobile Node node requests service by issuing a Registration 149 Request to the foreign agent, the foreign agent creates the AA- 150 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 151 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 152 important fields are extracted from the registration messages for 153 possible inclusion as DIAMETER AVPs. The AMR message is then 154 forwarded to the local DIAMETER server, known as the AAA-Foreign, or 155 AAAF. 157 Visited Domain Home Domain 158 +--------+ +--------+ 159 |abc.com | AMR/AMA |xyz.com | 160 | AAAF |<------------------->| AAAH | 161 +->| server | server-server | server | 162 | +--------+ communication +--------+ 163 | ^ ^ 164 | AMR/AMA | client-server | HAR/HAA 165 | | communication | 166 v v v 167 +---------+ +---------+ +---------+ 168 | Foreign | | Foreign | | Home | 169 | Agent | | Agent | | Agent | 170 +---------+ +---------+ +---------+ 171 ^ 172 | Mobile IP 173 | 174 v 175 +--------+ 176 | Mobile | 177 | Node | mn@xyz.com 178 +--------+ 179 Figure 1: Inter-Domain Mobility 181 Upon receiving the AMR, the AAAF follows the procedures outlined in 182 [1] to determine whether the AMR should be processed locally, or if 183 it should be forwarded to another DIAMETER Server, known as the AAA- 184 Home, or AAAH. Figure 1 shows an example in which a mobile node 185 (mn@xyz.com) requests service from a foreign provider (abc.com). The 186 request received by the AAAF is forwarded to abc.com's AAAH server. 188 Figure 2 shows the message flows involved when the attendant (foreign 189 agent) invokes the AAA infrastructure to request that a mobile node 190 be authenticated and authorized. Note that it is not required that 191 the foreign agent invoke AAA services every time a Registration 192 Request is received from the mobile, but rather only when the prior 193 authorization from the AAAH expires. The expiration time of the 194 authorization (and registration keys, if allocated by the AAA server) 195 is communicated through the Session-Time AVP in the AA-Mobile-Node- 196 Answer (AMA, see section 2.2) from the AAAH. 198 Mobile Node Foreign Agent AAAF AAAH Home Agent 199 ----------- ------------- ------------ ---------- ---------- 200 Advertisement & 201 <--------- Challenge 202 Reg-Req&MN-AAA ----> 203 AMR-------------> 204 AMR------------> 205 HAR-----------> 206 <----------HAA 207 <-----------AMA 208 <------------AMA 209 <-------Reg-Reply 211 Figure 2: Mobile IP/DIAMETER Message Exchange 213 The foreign agent (as shown in Figure 2) MAY provide a challenge, 214 which gives it direct control over the replay protection in the 215 Mobile IP registration process, as described in [5]. The mobile node 216 includes the Challenge and MN-AAA authentication extension to enable 217 authorization by AAAH. If the authentication data supplied in the 218 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 219 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 221 If the Mobile Node was successfully authenticated, the AAAH checks 222 for the Home-Agent-Address AVP. If one was specified, the AAAH 223 checks that the address is that of a known Home Agent, and one that 224 the Mobile Node is allowed to request. If no Home Agent was 225 specified, and if the MIP-Feature-Vector has the Home-Agent-Requested 226 flag set, and if allowed by policy in the home domain, the AAAH 227 SHOULD allocate a home agent on behalf of the Mobile Node. This can 228 be done in a variety of ways, including using a load balancing 229 algorithm in order to keep the load on all home agents equal. The 230 actual algorithm used and the method of discovering the home agents 231 is outside the scope of this specification. 233 If AAAH does not know the address of the home agent (perhaps because 234 it will be allocated by AAAF within the visited domain as described 235 in section 1.3), then AAAH sends an AMA message back to AAAF which 236 does not contain a MIP-Reg-Reply AVP. 238 Otherwise, if the home agent address is known, the AAAH then sends a 239 Home-Agent-MIP-Request (HAR), which contains the Mobile IP 240 Registration Request message data encapsulated in the MIP-Reg-Request 241 AVP, to the assigned or requested Home Agent. The AAAH MAY allocate 242 a home address for the mobile node, and include it in a Mobile-Node- 243 Address AVP within the HAR, or else leave this allocation 244 responsibility for the Home Agent. 246 Upon receipt of the HAR, the Home Agent first processes the DIAMETER 247 message. If the HAR is invalid, a HAA is returned with the Result- 248 Code AVP set to DIAMETER_ERROR_BAD_HAR (see section 3.0). Otherwise, 249 the Home Agent processes the MIP-Reg-Req AVP and creates the 250 Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. 251 If a home address is needed, the Home Agent MUST assign one and 252 include the address in both the Registration Reply and within the 253 DIAMETER Mobile-Node-Address AVP. The DIAMETER response is then 254 forwarded to the AAAH. 256 Upon receipt of the HAA, the AAAH sets the Command-Code field to AA- 257 Mobile-Node-Answer (AMA) and forwards the message to the AAAF. The 258 AAAH includes the Home-Agent-Address and Mobile-Node-Address AVPs in 259 the AMA message, enabling appropriate firewall controls for the 260 penetration of tunneled traffic between the Home Agent and the Mobile 261 Node. 263 The AAAF is responsible for ensuring that the AMA message is properly 264 forwarded to the correct foreign agent. 266 1.3 Allocation of Home Agent in Foreign Network 268 The DIAMETER Mobile IP extension allows a Home Agent to be allocated 269 in a foreign network, as required in [3, 16]. When a foreign agent 270 detects that the mobile node has a home agent address equal to 271 0.0.0.0 or 255.255.255.255 in the Registration Request message, it 272 MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag 273 set to one. If the home agent address is equal to 255.255.255.255, 274 then the foreign agent also MUST set the Home-Address-Allocatable- 275 Only-in-Home-Domain flag equal to one. 277 When the AAAF receives a AMR message with the Home-Agent-Requested 278 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 279 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 280 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 281 willing and able to assign a Home Agent for the Mobile Node. 283 In the event that the mobile node requests a home agent in the 284 foreign network, and the AAAF authorizes its use, the AAAF MUST set 285 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 286 This could happen when the AAA request is sent to "extend" a mobile 287 node's current session. 289 When the AAAH receives a AMR message, it first checks the 290 authentication data supplied by the mobile node, according to the 291 MIP-Reg-Req AVP and MN-AAA-Auth AVP, and determines whether to 292 authorize the mobile node. If the AMR indicates that the AAAF has 293 offered to allocate a home agent for the mobile node, then the AAAH 294 must decide whether its local policy would allow the user to have a 295 Home Agent in the foreign network. If so, and after checking 296 authorization from the data in the AMR message, the AAAH sends the 297 AMA message to the AAAF that does not contain the Home-Agent-Address. 299 Visited Domain Home Domain 300 +--------+ +--------+ 301 | | AMR/AMA | | 302 | AAAF |<------------------>| AAAH | 303 +--->| server | server-server | server | 304 | +--------+ communication +--------+ 305 | ^ 306 | | 307 HAR/HAA | AMR/AMA | client-server 308 v v communication 309 +---------+ +---------+ 310 | Home | | Foreign | 311 | Agent | | Agent | 312 +---------+ +---------+ 313 ^ 314 +--------+ | 315 | Mobile |<----------+ 316 | Node | Mobile IP 317 +--------+ 318 Figure 3: Home Agent allocated in Visited Domain 320 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 321 the Result-Code AVP indicating success, the AAAF MUST issue a HAI 322 message to the AAAH. The HAI message MUST include the Home-Agent- 323 Address and the Mobile-Node-Address AVPs. 325 Mobile Node Foreign Agent Home Agent AAAF AAAH 326 ----------- ------------- ------------- ---------- ---------- 328 <--------- Challenge 329 Reg-Req(Response)-> 330 AMR----------------------------> 331 AMR------------> 332 <------------AMA 333 <-------------HAR 334 HAA------------> 335 <----------------------------AMA 336 HAI------------> 337 <--------- Reg-Reply 338 Figure 4: Mobile IP/DIAMETER Message Exchange 340 If the Mobile Node moves to another Foreign Network, it can either 341 request to keep the same Home Agent within the old foreign network, 342 or it can request that a new one be assigned in the new network, by 343 setting the Home Agent address to 0.0.0.0 in its Registration Request 344 message. When the Mobile Node requests such a service, the AAAH MUST 345 interact with two AAAFs if it is willing to allow the Mobile Node to 346 receive such service. The AAAH issues the HAR to the AAAF that 347 oversees that Home Agent, and the AMA is issued to the AAAF that 348 oversees the Foreign Agent. 350 1.4 DIAMETER Session Termination 352 A Foreign and Home Agent following this specification MAY expect 353 their respective DIAMETER servers to maintain session state 354 information for each mobile node in their networks. In order for the 355 DIAMETER Server to release any resources allocated to a specific 356 mobile node, the mobility agents MUST send a Session-Termination- 357 Request (STR) [1] to their respective DIAMETER servers. 359 The Home DIAMETER server SHOULD only deallocate all resources after 360 the STR is received from the Home Agent. This ensures that a Mobile 361 Node that moves from one Foreign Agent to another (hand-off) does not 362 cause the Home DIAMETER Server to free all resources for the Mobile 363 Node. The DIAMETER Server is free to initiate the session termination 364 at any time by issuing the Session-Termination-Ind (STI) [1]. 366 2.0 Command-Code Values 368 This section defines Command-Code [1] values that MUST be supported 369 by all DIAMETER implementations conforming to this specification. 370 The following Command Codes are defined in this specification: 372 Command-Name Abbreviation Code Section 373 ----------------------------------------------------------- 374 AA-Mobile-Node-Request AMR 260 2.1 375 AA-Mobile-Node-Answer AMA 261 2.2 376 Home-Agent-MIP-Request HAR 262 2.3 377 Home-Agent-MIP-Answer HAA 263 2.4 378 Home-Agent-Allocated-Ind HAI 279 2.5 380 2.1 AA-Mobile-Node-Request (AMR) Command 382 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 383 set to 260, is sent by an attendant, acting as a DIAMETER client, to 384 a server in order to request the authentication and authorization of 385 a Mobile Node. The Foreign Agent uses information found in the 386 Registration Request to construct the AMR such as: 388 home address (Mobile-Node-Address AVP), 389 home agent address (Home-Agent-Address AVP), 390 mobile node NAI (User-Name AVP [1]). 392 If the mobile node's home address is zero, the foreign agent MUST NOT 393 include a Mobile-Node-Address AVP in the AMR. In this case, the AAAF 394 MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature- 395 Vector AVP in the AMR message to indicate that it is willing to 396 assign a Home Agent in the visited domain. 398 If the Previous-FA-NAI AVP is found in the request, the DIAMETER 399 client requests that the server return the registration key that was 400 assigned to the previous Foreign Agent for use with the Mobile Node 401 and Home Agent. The registration key is identified through the use of 402 the Mobile-Node-Address AVP. 404 Message Format 406 ::= 407 408 [ 409 ] 410 411 412 [] 413 [] 414 [] 415 [] 416 [] 417 [ | 418 ] 419 [] 420 [ 421 422 ] 424 2.2 AA-Mobile-Node-Answer (AMA) Command 426 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 427 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 428 Request message. The Result-Code AVP MAY contain one of the values 429 defined in section 3.0, in addition to the values defined in [1]. If 430 the home agent is situated in the home domain, a successful response 431 MUST include the MIP-Reg-Reply AVP. 433 The Home-Agent-Address AVP contains the Home Agent assigned to the 434 Mobile Node, while the Mobile-Node-Address AVP contains the home 435 address that was assigned. 437 The AMA message MUST contain the FA-to-HA-Key, FA-to-MN-Key and MIP- 438 Reg-Reply AVPs if they were received by AAAH in the HAA message. 440 Message Format 442 ::= 443 444 445 446 [] 447 [] 448 [] 449 [] 450 [] 451 [] 452 [] 453 [] 454 [ 455 456 ] 458 2.3 Home-Agent-MIP-Request (HAR) Command 460 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 461 set to 262, is sent by the AAA to the Home Agent. If the Home Agent 462 is to be assigned in a foreign network, the HAR is issued by AAAF. 463 If the HAR message does not include a Mobile-Node-Address AVP, and 464 the Registration Request has 0.0.0.0 for the home address, and the 465 HAR is successfully processed, the Home Agent MUST allocate one such 466 address to the mobile node. If the home agent's local AAA server 467 allocates the mobile node's home address, it MUST include the 468 assigned address in an Mobile-Node-Address AVP. 470 If a AAAF receives a HAR that does not include the MIP-Reg-Reply AVP, 471 then a Home Agent MUST be assigned in the foreign network. 473 When registration keys are requested for use by the mobile node (see 474 section 5.0), the AAAH MUST create them and include them in the HAR 475 message. When a Foreign-Home registration key is requested, it will 476 be created and distributed by the AAA server in the same domain as 477 the home agent. 479 Message Format 481 ::= 482 483 484 485 [ 486 ] 487 [] 488 [] 489 [] 490 [] 491 [] 492 [] 493 [ 494 495 ] 497 2.4 Home-Agent-MIP-Answer (HAA) Command 499 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 500 set to 263, is sent by the Home Agent to its local AAA server in 501 response to a Home-Agent-MIP-Request. If the home agent allocated a 502 home address for the Mobile Node, the address MUST be included in the 503 Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of the 504 values defined in section 3.0 instead of the values defined in [1]. 506 Message Format 508 ::= 509 510 511 512 [] 513 [] 514 [] 515 [ 516 517 ] 519 2.5 Home-Agent-Allocated-Ind (HAI) Command 521 The Home-Agent-Allocated-Ind (HAI), indicated by the Command-Code 522 field set to 279, is sent by the AAAF to the AAAH upon receipt of a 523 successful HAA when the Home Agent was assigned in the visited 524 network. The HAI MUST include the Home-Agent-Address and Mobile- 525 Node-Address AVPs. 527 Message Format 529 ::= 530 531 532 [] 533 [] 534 [] 535 [ 536 537 ] 539 3.0 Result-Code AVP Values 541 This section defines new Result-Code [1] values that MUST be 542 supported by all DIAMETER implementations that conform to this 543 specification. 545 DIAMETER_ERROR_BAD_KEY 16 546 This error code is used by the Home Agent to indicate to the 547 local DIAMETER server that the key generated is invalid. 549 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 550 This error code is used by the Home Agent to indicate that the 551 Home Address chosen by the Mobile Node or assigned by the local 552 DIAMETER server is unavailable. 554 DIAMETER_ERROR_TOO_BUSY 18 555 This error code is used by the Home Agent to inform the 556 DIAMETER Server that it cannot handle an extra Mobile Node. 557 Upon receiving this error the DIAMETER Server can try to use an 558 alternate Home Agent if one is available. 560 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 561 This error code is used by the Home Agent to inform the 562 DIAMETER server that the Registration Request failed. 564 DIAMETER_ERROR_AUTH_FAILURE 20 565 This error code is used by AAAH to inform AAAF that the 566 authentication data in the MN-AAA authentication extension is 567 invalid. 569 DIAMETER_ERROR_BAD_HAR-day 21 570 This error code is used by HA to inform the AAA server that the 571 Home-Agent-Request (HAR) message could not be processed 572 correctly. 574 4.0 Mandatory AVPs 576 The following table describes the DIAMETER AVPs defined in the Mobile 577 IP extension, their AVP Code values, types, possible flag values and 578 whether the AVP MAY be encrypted. 580 +---------------------+ 581 | AVP Flag rules | 582 |----+-----+----+-----|----+ 583 AVP Section Value | | |SHLD| MUST|May | 584 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 585 -----------------------------------------|----+-----+----+-----|----+ 586 MIP-Reg-Request 320 4.1 Data | M | P | | V | Y | 587 MIP-Reg-Request 321 4.2 Data | M | P | | V | Y | 588 MN-AAA-Auth 322 4.3 Complex | M | P | | V | Y | 589 Mobile-Node- 333 4.4 Address | M | P | | V | Y | 590 Address | | | | | | 591 Home-Agent- 334 4.5 Address | M | P | | V | Y | 592 Address | | | | | | 593 Previous-FA-NAI 335 4.6 String | M | P | | V | Y | 594 Previous-FA-Addr 336 4.7 Address | M | P | | V | Y | 595 MIP-Feature-Vector 337 4.8 Integer32| M | P | | V | Y | 597 4.1 MIP-Reg-Request AVP 599 The MIP-Reg-Request AVP (AVP Code 320) is of type data and contains 600 the Mobile IP Registration Request [4] sent by the Mobile Node to the 601 Foreign Agent. 603 4.2 MIP-Reg-Reply AVP 605 The MIP-Reg-Reply AVP (AVP Code 321) is of type data and contains the 606 Mobile IP Registration Reply [4] sent by the Home Agent to the 607 Foreign Agent. 609 4.3 MN-AAA-Auth AVP 611 The MN-AAA-Auth AVP (AVP Code 322) is of type complex and contains 612 some ancillary data to simplify processing of the authentication data 613 in the Mobile IP Registration Request [4] by the target AAA server. 614 The ancillary data fields have the following format: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | AVP Header | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | MN-AAA SPI | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Authentication Input Data Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Authenticator Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Authenticator Offset | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 MN-AAA SPI 631 The SPI which indicates the algorithm by which the targeted 632 AAA server (AAAH) should attempt to validate the 633 Authenticator computed by the mobile node over the 634 Registration Request data 636 Authentication Input Data Length 637 The length in bytes of the Registration Request data (data 638 portion of MIP-Reg-Request AVP) that should be used as 639 input to the algorithm (indicated by the MN-AAA SPI) used 640 to determine whether the Authenticator Data supplied by the 641 Mobile Node is valid. 643 Authenticator Length 644 The length of the authenticator to be validated by the 645 targeted AAA server (i.e., AAAH). 647 Authenticator Offset 648 The offset into the Registration Request Data, of the 649 authenticator to be validated by the targeted AAA server 650 (i.e., AAAH). 652 4.4 Mobile-Node-Address AVP 654 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 655 contains the Mobile Node's Home Address. 657 4.5 Home-Agent-Address AVP 659 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 660 contains the Mobile Node's Home Agent Address. 662 4.6 Previous-FA-NAI AVP 664 The Previous-FA-NAI AVP (AVP Code 335) is of type String and contains 665 the Network Access Identifier [6] of the Mobile Node's old Foreign 666 Agent. The Mobile Node MAY include this information in the 667 Registration Request when it moves its point of attachment to a new 668 foreign agent under the same administrative domain as the old FA 669 (identified by the realm portion of the NAI). 671 When this AVP is present in the AA-Mobile-Node-Request, it indicates 672 that the local DIAMETER server overseeing the Foreign Agent should 673 attempt to return the registration key that was previously allocated 674 to the old Foreign Agent for the Mobile Node. The registration key is 675 identified through the use of the Mobile-Node-Address AVP, which MUST 676 be present if this extension is present. 678 In many circumstances, this allows the Mobile Node to move from one 679 Foreign Agent to another within the same administrative domain 680 without having to send the request back to the Mobile Node's Home 681 DIAMETER Server (AAAH). 683 4.7 Previous-FA-Addr AVP 685 The Previous-FA-Addr AVP (AVP Code 336) is of type Address and 686 contains the IP Address of the Mobile Node's old Foreign Agent. The 687 Mobile Node MAY include this information in the Previous Foreign 688 Agent Notification Extension to the Mobile IP Registration Request 689 when it moves its point of attachment to a new foreign agent. 691 When this AVP is present in the AA-Mobile-Node-Request, it indicates 692 that the local DIAMETER server overseeing the Foreign Agent should 693 attempt to return the registration key that was previously allocated 694 to the old Foreign Agent for the Mobile Node. The registration key is 695 identified through the use of the Mobile-Node-Address AVP, which MUST 696 be present if this extension is present. 698 In many circumstances, this allows the Mobile Node to move from one 699 Foreign Agent to another within the same administrative domain 700 without having to send the request back to the Mobile Node's Home 701 DIAMETER Server (AAAH). 703 4.8 MIP-Feature-Vector AVP 705 The MIP-Feature-Vector AVP (AVP Code 337) is of type Integer32 and is 706 added with flag values set by the Foreign Agent or by the AAAF owned 707 by the same administrative domain as the Foreign Agent. The Foreign 708 Agent SHOULD include MIP-Feature-Vector AVP within the AMR message it 709 sends to the AAAF. 711 Flag values currently defined include: 712 1 Mobile-Node-Home-Address-Requested 713 2 Home-Address-Allocatable-Only-in-Home-Domain 714 4 Home-Agent-Requested 715 8 Foreign-Home-Agent-Available 716 16 MN-HA-Key-Request 717 32 MN-FA-Key-Request 718 64 FA-HA-Key-Request 719 128 Home-Agent-In-Foreign-Network 721 The flags are set according to the following rules. 723 If the mobile node includes a valid home address (i.e., not equal to 724 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 725 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 726 Feature-Vector AVP. 728 If the mobile node sets the home address field equal to 0.0.0.0 in 729 its Registration Request, the Foreign Agent sets the Mobile-Node- 730 Home-Address-Requested flag to one, and zeroes the Home-Address- 731 Allocatable-Only-in-Home-Domain flag in the MIP-Feature-Vector AVP. 733 If the mobile node sets the home address field equal to 734 255.255.255.255 in its Registration Request, the Foreign Agent sets 735 both the Mobile-Node-Home-Address-Requested flag and the Home- 736 Address-Allocatable-Only-in-Home-Domain flag to one in the MIP- 737 Feature-Vector AVP. 739 If the mobile node sets the home agent field equal to 0.0.0.0 in its 740 Registration Request, the Foreign Agent sets the Home-Agent-Requested 741 flag to one in the MIP-Feature-Vector AVP. 743 Whenever the Foreign Agent sets either the Home-Address-Requested 744 flag or the Home-Agent-Request flag to one, it MUST also set the MN- 745 HA-Key-Request flag to one. 747 If the mobile node includes a Registration Key Request [17] extension 748 in its Registration Request, the Foreign Agent sets the MN-FA-Key- 749 Request flag to one in the MIP-Feature-Vector AVP. 751 If the mobile node requests a home agent in the foreign network, and 752 the AAAF authorizes the request, the AAAF MUST set the Home-Agent- 753 In-Foreign-Network bit to one. 755 The Foreign Agent MUST NOT set the FA-HA-Key-Request flag, Foreign- 756 Home-Agent-Available, and Home-Agent-In-Foreign-Network flag to one. 758 When the AAAF receives the AMR message, it MUST first verify that the 759 sender was an authorized Foreign Agent. The AAAF then takes any 760 actions indicated by the settings of the MIP-Feature-Vector AVP 761 flags. The AAAF then MAY set additional flags. Only the AAAF may 762 set the FA-HA-Key-Request flag or the Foreign-Home-Agent-Available 763 flag to one. This is done according to local administrative policy. 764 When the AAAF has finished setting additional flags according to its 765 local policy, then the AAAF transmits the AMR with the possibly 766 modified MIP-Feature-Vector AVP to the AAAH. 768 5.0 Key Distribution Center 770 The mobile node and mobility agents use registration keys to compute 771 authentication extensions applied to registration messages, as 772 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 773 registration keys are requested the AAA server(s) MUST create them 774 after the Mobile Node is successfully authenticated and authorized. 776 The keys destined for each mobility entity are encrypted either using 777 the secret shared with the entity [1], or via its public key [9], as 778 indicated by the relevant security association. If the AAAH does not 779 communicate directly with the Foreign Agent, those keys are encrypted 780 using the security association shared with the AAAF. The Session- 781 Timeout AVP contains the number of seconds before registration keys 782 destined for the Home Agent and/or Foreign Agent expire. A value of 783 zero indicates infinity (no timeout). 785 AAA support for key distribution departs slightly from the existing 786 SPI usage, as described in [4]. The SPI values are used as key 787 identifiers, meaning that each registration key has its own SPI 788 value; nodes that share a key also share an SPI. If no preferred SPI 789 value is indicated the registration keys the foreign agent needs, the 790 AAA server MAY generate SPI values for the Mobility Agents as opposed 791 to the receiver choosing its own SPI value. For example, suppose a 792 Mobile Node and a Foreign Agent share a key that was generatied by 793 AAAH with a corresponding SPI value of 37,496. All Mobile-Foreign 794 Authentication extensions will be computed by either entity (in this 795 example) using the shared key and MUST include the SPI value of 796 37,496. 798 Once the registration keys have been distributed, subsequent Mobile 799 IP registrations need not invoke the AAA infrastructure until the 800 keys expire. These registrations MUST include the Mobile-Home 801 authentication extension. In addition, subsequent registrations MUST 802 also include Mobile-Foreign authentication extension if the Mobile- 803 Foreign key was generated and distributed by AAA; similarly for 804 subsequent use of the Foreign-Home authentication extensions. 806 Each registration key that is generated by AAA will generally be 807 distributed to two parties; for instance, a Mobile-Foreign key goes 808 to both a mobile node and a foreign agent. The methods by which the 809 key is encoded will depend upon the security associations available 810 to the AAA server and each recipient of the key. These methods will 811 often be different for the two recipients, so that the registration 812 key under consideration has to be encoded twice. 814 See sections 6.1 and 6.2 for details about the format of the AVPs 815 used to distribute the registration keys. 817 5.1 Distributing the Mobile-Home Registration Key 819 If the mobile node does not have a Mobile-Home registration key, then 820 the AAAH is likely to be the only entity trusted that is available to 821 the mobile node. Thus, the AAAH has to generate the Mobile-Home 822 registration key, and encode it for eventual consumption by the 823 mobile node and home agent. 825 If the home agent is in the home domain, then AAAH can directly 826 encode the Mobile-Home registration key into a HA-MN-Key AVP and 827 include that AVP in the HAR message for delivery to the home agent. 829 If, on the other hand, the home agent is to be allocated in the 830 visited domain, the AAAH does not transmit the HAR to the home agent. 831 Instead, AAAH has to include the HA-MN-Key AVP in the AMR message 832 which it sends to the AAAF. In this latter case, the Mobile-Home 833 registration key is encoded into HA-MN-Key AVP using the method 834 indicated by the security association between the AAAF and the AAAH. 835 When the AAAF receives the AMR, it first allocates a home agent, and 836 then creates a HAR message for that home agent. After the AAAF 837 decodes the registration key, it re-encodes the key into a new HA- 838 MN-Key AVP which is to be included within the HAR message. 840 The AAAH also has to arrange for the key to be delivered to the 841 mobile node. Unfortunately, the AAA server only knows about DIAMETER 842 messages and AVPs, and the mobile node only knows about Mobile IP 843 messages and extensions[4]. The AAA server has to rely on a mobility 844 agent (that also understands DIAMETER) to transfer the key into a 845 Mobile IP MN-HA Key Reply extension to the Registration Reply 846 message. This mobility agent (actually, the mobile node's home 847 agent) can format the Reply message and extensions correctly for 848 eventual delivery to the mobile node, by way of an AMA message sent 849 to the appropriate foreign agent in the visited domain. That foreign 850 agent will use the information in the MIP-Reg-Reply AVP to create a 851 Mobile IP Registration Reply message, containing the MN-HA Key Reply 852 extension, and transmit it to the mobile node. 854 For this purpose, AAAH encodes the Mobile-Home registration key into 855 a MN-HA-Key AVP, using its security association with the mobile node. 856 If the home agent is in the home domain, AAAH puts the MN-HA-Key AVP 857 into the HAR message. Otherwise, the AAAH puts the MN-HA-Key AVP 858 into the AMR message which will be sent back to AAAF. When AAAF 859 creates the HAR message for the home agent in the visited domain, and 860 decodes the registration key in the HA-MN-Key AVP from the AVP 861 received from AAAH, AAAF then recodes the registration key into a new 862 HA-MN-Key AVP which is to be included as part of the HAR message. In 863 either case, the home agent creates a Registration Reply with the 864 MN-HA Key Reply extension, and formats the reply data into a MIP- 865 Reg-Rep-AVP for delivery in a HAA message to the AAA server. After 866 the HAA message is parsed by the AAA server, the AMA message 867 containing the MIP-Reg-Rep AVP will eventually be received by the 868 attendant (i.e., the foreign agent). The foreign agent can then use 869 that AVP to recreate a Registration Reply message, containing the 870 MN-HA Key Reply extension, for delivery to the mobile node. 872 In summary, the AAAH generates the Mobile-Home registration key and 873 encodes it into a HA-MN-Key AVP and a MN-HA-Key AVP. These AVPs are 874 delivered to a home agent by including them in a HAR message sent 875 from either AAAH or AAAF. The home agent decodes the key for its own 876 use. The home agent also copies the encoded registration key from 877 the MN-HA-Key AVP into a MN-HA Key Reply extension appended to the 878 Mobile IP Registration Reply message. This Registration Reply 879 message MUST also include the Mobile-Home authentication extension, 880 created using the newly allocated Mobile-Home registration key. The 881 home agent then encodes the Registration Reply message and extensions 882 into a MIP-Reg-Reply AVP included as part of the HAA message to be 883 sent back to the AAA server. 885 5.2 Distributing the Mobile-Foreign Registration Key 887 The Mobile-Foreign registration key is also generated by AAAH (upon 888 request), so that it can be encoded into a MN-FA-Key AVP and copied 889 by the home agent into a "Registration Key Reply from Home Agent" 890 extension [17] to the Mobile IP Registration Reply message. Since 891 the foreign agent is in the same administrative domain as AAAF, the 892 sequence of events for handling the FA-MN-Key AVP is similar to the 893 way the HA-MN-Key AVP is handled when the home agent is allocated in 894 the visited domain. Most of the other considerations for 895 distributing the Mobile-Foreign registration key are also similar. 897 When the home agent is in the home domain, AAAH includes the MN-FA- 898 Key AVP in the HAR message. Otherwise, AAAH includes the MN-FA-Key 899 AVP in the AMR message to be sent back to the AAAF. In the latter 900 case, AAAF sends the HAR message to the (newly allocated) home agent. 902 In either case, the home agent decodes the key, and recodes it into 903 the key reply extension to the Mobile IP registration message. Then 904 the home agent (as before) copies the Registration Reply message into 905 the MIP-Reg-Reply AVP and places the result (possibly also containing 906 the MN-HA Key Reply extension as in section 1.4.1) into the HAA 907 message to be sent back to the AAA server. The home agent MUST also 908 append a Foreign-Home authentication extension to the Registration 909 Reply message, using the newly allocated Foreign-Home registration 910 key. 912 When the home agent is in the home domain, AAAH receives the HAA, and 913 then includes the MIP-Reg-Reply AVP in the AMA message to be sent to 914 AAAF. Otherwise, AAAF receives the HAA, and inserts it into an AMA 915 message to be sent to the foreign agent. 917 AAAH also has to make the Mobile-Foreign registration key available 918 to AAAF. It does this by encoding the key into a FA-MN-Key AVP, 919 using its security association with AAAF, and placing the results in 920 the AMA. Then the AAAF decodes the registration key, and recodes it 921 into a newly formulated FA-MN-Key AVP which is to be sent to the 922 foreign agent in the AMA message containing the MIP-Reg-Reply AVP 923 from the home agent. 925 5.3 Distributing the Foreign-Home Registration Key 927 If the home agent is in the home domain, then AAAH has to generate 928 the Foreign-Home registration key. Otherwise, it is generated by 929 AAAF. 931 In the former case, AAAH encodes the registration key into a HA-FA- 932 Key AVP and includes that AVP as part of the HAR message sent to the 933 home agent, and waits for the HAA message to be returned. 935 Whether or not AAAH sends the HAR message, it also further encodes 936 the same registration key and puts it into a FA-HA-Key AVP included 937 as part of the AMA message to be transmitted back to AAAF. 939 If the home agent is in the visited domain, the AAAH includes the 940 HA-FA-Key AVP as part of the AMR also. In this case, AAAF has to 941 decode the Foreign-Home registration key and include it as part of 942 the HAR message to be sent to the (newly allocated) home agent. 944 In either case, AAAF sends a AMA message, containing a MIP-Reg-Reply 945 AVP and the FA-HA-Key AVP, to the foreign agent. First, the foreign 946 agent recreates the necessary Registration Reply message from the AMA 947 message. Then the foreign agent recovers the Foreign-Home 948 registration key, using its security association with AAAF. The 949 foreign agent MUST then use this key to create a Mobile-Foreign 950 authentication extension to the Registration Reply message. 952 5.4 Key Distribution Example 954 Figure 5 provides an example of subsequent Mobile IP message 955 exchange, assuming that AAAH distributed registration keys for all 956 three MN-FA, FA-HA and HA-MN authentication extensions. 958 Mobile Node Foreign Agent Home Agent 959 ----------- ------------- ---------- 961 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 963 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 965 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 967 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 969 Figure 5: Mobile IP Message Exchange 971 6.0 Key Distribution Center (KDC) AVPs 973 The Mobile-IP protocol defines a set of security associations shared 974 between the Mobile Node, Foreign Agent and Home Agents. These three 975 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 976 Home), can be dynamically created by the AAAH. This requires that 977 the AAAH create Mobile-IP Registration Keys, and that these keys be 978 distributed to the three mobile entities, via the DIAMETER Protocol. 979 AAA servers supporting the DIAMETER Mobile IP Extension MUST 980 implement the KDC AVPs defined in this document. In other words, AAA 981 servers MUST be able to create three registration keys: the Mobile- 982 Home, Mobile-Foreign, and Foreign-Home keys. 984 Each of these keys is encrypted two different ways, as needed for 985 each key recipient. The mobile node and home agent registration keys 986 are sent to the Home Agent, while the foreign agent's keys are sent 987 to the foreign agent via the AAAF. This leads to six different AVPs, 988 since there are three keys, and each one has to be able to be 989 encrypted in two different ways. 991 The names of the KDC AVPs indicate the two entities sharing the 992 security association defined by the encrypted key material; the 993 intended receiver of the AVP is the first named entity. So, for 994 instance, the MN-to-HA-Key AVP contains the Mobile-Home key encrypted 995 in a way that allows it to be recovered by the mobile node. 997 If strong authentication and confidentiality of the registration keys 998 is required, it is recommended that the strong security extension [9] 999 be used. 1001 The following table describes the DIAMETER AVPs defined in the Mobile 1002 IP extension, their AVP Code values, types, possible flag values and 1003 whether the AVP MAY be encrypted. 1005 +---------------------+ 1006 | AVP Flag rules | 1007 |----+-----+----+-----|----+ 1008 AVP Section Value | | |SHLD| MUST|MAY | 1009 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 1010 -----------------------------------------|----+-----+----+-----|----+ 1011 MN-to-FA-Key 325 6.1 Complex | M | P | | V | Y | 1012 MN-to-HA-Key 331 6.1 Complex | M | P | | V | Y | 1013 FA-to-MN-Key 326 6.2 Complex | M | P | | V | Y | 1014 FA-to-HA-Key 328 6.2 Complex | M | P | | V | Y | 1015 HA-to-MN-Key 332 6.2 Complex | M | P | | V | Y | 1016 HA-to-FA-Key 329 6.2 Complex | M | P | | V | Y | 1017 FA-MN-Preferred- 324 6.3 Integer32| M | P | | V | Y | 1018 SPI | | | | | | 1019 FA-HA-Preferred- 327 6.4 Integer32| M | P | | V | Y | 1020 SPI | | | | | | 1022 6.1 Mobile Node Registration Key AVPs 1024 The registration key AVPs destined for the Mobile Node are of type 1025 complex, and are created by the AAAH. There are two Mobile Node 1026 Registration Key AVPs; the MN-FA Key and the HA-MN Key. 1028 The MN-to-FA-Key AVP (AVP Code 325) contains the data immediately 1029 following the Mobile IP extension header of the "Unsolicited MN-FA 1030 Key From AAA Subtype", as documented in [15]. 1032 The HA-to-MN-Key AVP (AVP Code 331) contains the data immediately 1033 following the Mobile IP extension header of the "Unsolicited MN-HA 1034 Key From AAA Subtype", as documented in [15]. 1036 The AAA SPI field of a Mobile IP registration key extension is set to 1037 the value the AAAH shares with the Mobile Node. The HA-MN-Key's HA 1038 SPI field [15] contains the same value as the one found in the HA- 1039 to-MN-Key AVP. The MN-FA-Key's FA SPI [15] field contains the same 1040 value as the one found in the FA-to-MN-Key AVP. The registration 1041 key's Lifetime field is set to the same value as the one found in the 1042 Session-Timeout AVP. 1044 6.2 Mobility Agent Session Key AVPs 1046 The registration keys AVPs destined for the Foreign and Home Agents 1047 are of type complex, and MUST have the AVP length field set to at 1048 least 13. The AVP has the following format: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 AVP Header 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Peer SPI | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Data ... 1058 +-+-+-+-+-+-+-+-+ 1060 AVP Code 1061 326 for FA-to-MN Key, destined for Foreign Agent 1062 328 for FA-to-HA Key, destined for Foreign Agent 1063 329 for HA-to-FA Key, destined for Home Agent 1064 332 for HA-to-MN Key, destined for Home Agent 1066 Peer SPI 1067 A 32-bit opaque value, which the target MUST use to index all 1068 the necessary information recovered from the security 1069 information after it is decoded. 1071 Data 1072 The data field contains the key used to create a Mobility 1073 Security Association between the mobility nodes. 1075 6.3 FA-MN-Preferred-SPI AVP 1077 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 1078 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 1079 contains the SPI that the Foreign Agent would prefer to have assigned 1080 by the AAAH in the FA-to-MN-Key AVP. 1082 6.4 FA-HA-Preferred-SPI AVP 1084 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 1085 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 1086 contains the SPI that the Foreign Agent would prefer to have assigned 1087 by the AAAH in the FA-to-HA-Key AVP. 1089 7.0 Interactions with Resource Management 1091 The Resource Management extension [18] provides the ability for a 1092 DIAMETER node to query a peer for session state information. The 1093 document states that service-specific extensions are responsible for 1094 specifying what AVPs are to be present in the Resource-Token [18] 1095 AVP. 1097 In addition to the AVPs listed in [18], the Resource-Token with the 1098 Extension-Id AVP set to four (4) MUST include the Mobile-Node-Address 1099 and the Home-Agent-Address AVP. 1101 8.0 Acknowledgements 1103 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1104 Pankaj Patel for their participation in the Document Reading Party. 1105 The authors would also like to thank the participants of TIA's TR45.6 1106 working group for their valuable feedback. 1108 9.0 IANA Considerations 1110 The command codes defined in Section 2.0 are values taken from the 1111 Command-Code [1] address space and extended in [9], [12] and [14]. 1112 IANA should record the values as defined in Section 2.0. 1114 The Result-Code values defined in Section 3.0 are error codes as 1115 defined in [1] and extended in [9], [12] and [14]. They correspond to 1116 error values specific to the Mobile IP extension. IANA should record 1117 the values as defined in Section 3.0. 1119 The AVPs defined in sections 4.0 and 6.0 were allocated from the AVP 1120 numbering space defined in [1], and extended in [9], [12] and [14]. 1121 IANA should record the values as defined in Sections 4.0 and 6.0. 1123 10.0 Security Considerations 1125 This specification describes the DIAMETER extension necessary to 1126 authenticate and authorize a Mobile IP Mobile Node. The 1127 authentication algorithm used is dependent upon the transforms 1128 available by the Mobile IP protocol, and [5]. This specification also 1129 defines a method by which the home DIAMETER server can create and 1130 distribute registration keys to be used to authenticate Mobile IP 1131 registration messages. The keys are distributed in an encrypted 1132 format through the DIAMETER protocol, and SHOULD be encrypted using 1133 the methods defined in [9]. 1135 11.0 References 1137 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 1138 Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, 1139 September 2000. 1141 [2] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- 1142 diameter-framework-08.txt, IETF work in progress, June 2000. 1144 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1145 Authorization, and Accounting Requirements", draft-ietf- 1146 mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000. 1148 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1150 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1151 sions", draft-ietf-mobileip-challenge-13.txt, IETF work in pro- 1152 gress, June 2000. 1154 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1155 January 1999. 1157 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1158 RFC 2477, January 1999. 1160 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1161 Extension", RFC 2794, March 2000. 1163 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1164 Extensions", draft-calhoun-diameter-strong-crypto-05.txt, IETF 1165 work in progress, September 2000. 1167 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1168 2406, November 1998. 1170 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1171 Levels", BCP 14, RFC 2119, March 1997. 1173 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 1174 Extension", draft-calhoun-diameter-accounting-08.txt, IETF work 1175 in progress, September 2000. 1177 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1178 for Message Authentication. RFC 2104, February 1997. 1180 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 1181 Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in 1182 progress, September 2000. 1184 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1185 draft-calhoun-mobileip-aaa-key-01.txt, IETF work in progress, 1186 January 2000. 1188 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1189 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1190 2000. 1192 [17] C. Perkins, D. Johnson, N. Asokan, "Registration Keys for Route 1193 Optimization", draft-ietf-mobileip-regkey-03.txt, IETF work in 1194 progress, July 2000. 1196 [18] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1197 calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep- 1198 tember 2000. 1200 12.0 Authors' Addresses 1202 Questions about this memo can be directed to: 1204 Pat R. Calhoun 1205 Network and Security Research Center, Sun Labs 1206 Sun Microsystems, Inc. 1207 15 Network Circle 1208 Menlo Park, California, 94025 1209 USA 1211 Phone: +1 650-786-7733 1212 Fax: +1 650-786-6445 1213 E-mail: pcalhoun@eng.sun.com 1214 Charles E. Perkins 1215 Nokia Research Center 1216 313 Fairchild Drive 1217 Mountain View, California 94043 1218 USA 1220 Phone: +1 650-625-2986 1221 Fax: +1 650-625-2502 1222 E-Mail: charliep@iprg.nokia.com 1224 13.0 Full Copyright Statement 1226 Copyright (C) The Internet Society (1999). All Rights Reserved. 1228 This document and translations of it may be copied and furnished to 1229 others, and derivative works that comment on or otherwise explain it 1230 or assist in its implementation may be prepared, copied, published 1231 and distributed, in whole or in part, without restriction of any 1232 kind, provided that the above copyright notice and this paragraph are 1233 included on all such copies and derivative works. However, this docu- 1234 ment itself may not be modified in any way, such as by removing the 1235 copyright notice or references to the Internet Society or other 1236 Internet organizations, except as needed for the purpose of develop- 1237 ing Internet standards in which case the procedures for copyrights 1238 defined in the Internet Standards process must be followed, or as 1239 required to translate it into languages other than English. The lim- 1240 ited permissions granted above are perpetual and will not be revoked 1241 by the Internet Society or its successors or assigns. This document 1242 and the information contained herein is provided on an "AS IS" basis 1243 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1244 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1245 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1246 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1247 FITNESS FOR A PARTICULAR PURPOSE.